Techlist.io - Korean Tech Blog Curator

kakao3 min readCurated summary

Is a Non-Developer Who Does Vibe Coding a Developer? (3)

AI coding agents have helped a non-developer move from creating small local HTML tools to building shared dashboards, integrations, automations, and repeatable workflows. The major change was not writing more code, but learning to define data, permissions, inputs, outputs, exceptions, and validation criteria. The author concludes that AI is making more kinds of work executable and structured, expanding questions about “development” beyond professional developers. ## From Local HTML to Shared Tools - Early tools were standalone HTML files used locally in a browser. - Sharing them introduced deployment, URLs, version updates, and maintenance concerns. - Once users needed persistent data and changing states, the problem expanded from UI design to: - Data storage - Access and edit permissions - Change history and rollback - Backups and operational responsibility - Google Sheets became a practical lightweight database because it already provided: - Collaboration and familiar interfaces - Permission management - Revision history - The author progressed from manually pasting Apps Script code to using `clasp` and Apps Script APIs for deployment and execution. - The key shift was learning to evaluate where data should live and which tools already work safely within an organization. ## Security as a Daily Habit - Connecting work tools through webhooks introduced the need to protect tokens and webhook URLs. - The author began using `.env` files and `.gitignore` to prevent secrets from entering source code or Git repositories. - Requests to AI agents increasingly included security requirements: - Read secrets from environment variables - Avoid printing sensitive values in logs - Use placeholders instead of real credentials - Small automations connected to external systems naturally required thinking about secret management, execution environments, and access control. ## Turning Manual Tasks into Workflows - Tasks such as copying files, organizing folders, converting documents, editing videos, and extracting audio or summaries were delegated to AI agents. - Delegating these tasks required explicit definitions of: - Input files - Output names and formats - Whether existing files may be overwritten - Failure conditions - Verification requirements - Informal, intuitive actions became structured work specifications. - The author found that understanding completion criteria and input/output formats was often more important than memorizing individual commands. ## Skills and Feedback Loops - Weekly meeting-note preparation revealed recurring editing patterns and implicit business rules. - These rules were encoded into Codex and Claude skills covering: - Note structure - Action-item extraction - PMO-related signals - Situations where the AI should ask questions instead of making assumptions - Skills functioned as stored decision criteria, not merely collections of prompts. - Comparing AI-generated drafts with the author’s final revisions enabled continuous refinement. - Deleting local data for security reasons accidentally removed useful conversation context, temporarily reducing skill quality and demonstrating the importance of preserving relevant operational knowledge. ## Using Outputs as New Inputs - Google Analytics reporting became more frequent and detailed through MCP-based API access and reusable reporting skills. - MCP provided the data connection, while skills preserved the recurring monthly report structure. - The valuable work remained interpreting changes between periods and deciding whether a change was meaningful. - Combining AI-generated metrics with the author’s contextual knowledge helped surface signals requiring further investigation in near real time. The author recommends focusing less on how much code AI can generate and more on how work can be clearly structured for AI execution. As agents become more capable, everyone—not only developers—will increasingly define inputs, outputs, permissions, security controls, repetition, and validation as part of everyday work.

Read original(opens in new tab)
cloudflare2 min readCurated summary

Growing the Cloudflare AI team with talent from Ensemble AI

Cloudflare is bringing key members of Ensemble AI onto its team to improve AI infrastructure and inference efficiency. Ensemble’s work on model compression, structured neural architectures, and parameter-efficient fine-tuning complements Cloudflare’s Workers AI platform. The combined effort aims to make powerful AI models faster, cheaper, and easier to deploy globally. ## Incorporating Ensemble AI’s Expertise - Ensemble AI has focused on reducing the memory, compute, and deployment costs of large language and multimodal models. - Its NdLinear technology replaces standard transformer linear layers while preserving multidimensional structure such as attention heads, channels, and spatial dimensions. - NdLinear-LoRA reduces the number of trainable parameters needed to fine-tune large models. - These techniques complement quantization and vector quantization to improve model efficiency without significantly sacrificing quality. ## Improving AI Inference Economics - Cloudflare Workers AI provides serverless GPU-powered inference across Cloudflare’s global network. - Lower model size, memory usage, and compute requirements can improve throughput, GPU utilization, and overall inference costs. - These improvements are increasingly important for agents, multimodal applications, personalization, fine-tuning, retrieval, and reinforcement learning. - The Ensemble team will contribute to Cloudflare’s existing work, including the Infire inference engine, Unweight tensor compression, and systems for running very large language models. ## Supporting Next-Generation Workloads - Developers increasingly need AI infrastructure that is reliable, affordable, globally distributed, and close to end users—not merely access to models. - Cloudflare’s network, serverless platform, and Workers AI provide a foundation for deploying AI with less operational complexity. - Combining Cloudflare’s infrastructure with Ensemble’s efficient model architectures should enable lower-cost, higher-performance AI deployments at scale. Cloudflare’s stated goal is to make advanced AI workloads more accessible by improving the economics and efficiency of inference across its platform.

Read original(opens in new tab)
aws4 min readCurated summary

AWS Weekly Roundup: AWS FinOps Agent in preview, Gemma 4 on Bedrock, Kiro Pro Max, and more (June 15, 2026) | Amazon Web Services

AWS’s June 15, 2026 roundup highlights rapid adoption of AI-native development, a preview of the AWS FinOps Agent, and major infrastructure and model releases. AWS reports significant productivity gains from agent-assisted engineering, while new services target cost optimization, observability, security, and developer workflows. The overall direction is toward more autonomous, context-aware tools integrated throughout the AWS ecosystem. ## AI-Native Development at AWS - Amazon engineering teams are restructuring development around AI agents. - A six-engineer team rebuilt the Amazon Bedrock inference engine in 76 days, compared with an original estimate of 30 developers over 12–18 months. - Structured Amazon Stores pilots achieved a median 4.5× improvement in normalized deployment velocity, with some teams exceeding 10×. - Recommended practices for “frontier teams” include: - Building steering files, coding standards, and structured repositories to provide agent context. - Expecting an initial productivity slowdown while workflows change. - Maintaining a backlog of well-scoped tasks that agents can execute in parallel. - Writing structured specifications before generating code. - Moving testing earlier so agents can detect and correct issues. - AWS cautions that commit velocity is only one measure; future work will address release management, operations, security, and end-of-life upgrades. ## AWS FinOps Agent Preview - AWS FinOps Agent helps finance and engineering teams: - Answer AWS cost questions and generate reports. - Identify rightsizing, idle-resource, and Savings Plans opportunities. - Investigate cost anomalies automatically. - Schedule recurring FinOps workflows. - Recommendations come from AWS Cost Optimization Hub and AWS Compute Optimizer. - The agent can open Jira tickets and post anomaly-investigation findings to Slack. ## New EC2 M9g and M9gd Instances - M9g and M9gd instances use AWS Graviton5 processors and the sixth-generation Nitro System. - They provide: - Up to 25% better compute performance than Graviton4. - Up to 35% faster web applications and ML inference. - Up to 30% faster database performance. - Up to 15% more network bandwidth and 20% more EBS bandwidth than M8g. - Graviton5 adds PCIe Gen6, DDR5-8800 memory, and a 5× larger L3 cache. - The Nitro Isolation Engine uses formal verification to provide mathematically proven VM isolation. - M9gd adds up to 11.4 TB of local NVMe SSD storage and 30% higher IOPS than M8gd. - Instance Bandwidth Configuration can shift bandwidth between EBS and VPC networking by up to 25%. ## Bedrock Model Updates - Anthropic Claude Fable 5 launched on Bedrock with: - Extended asynchronous task execution. - Advanced vision for diagrams, charts, and PDFs. - Proactive self-verification. - Access required Data Retention API opt-in and 30-day retention for inputs and outputs. - Anthropic later asked AWS to revoke access to Claude Fable 5 and Claude Mythos 5 in response to a U.S. government export-control directive. - Google DeepMind’s Gemma 4 models are available in three versions: - Gemma 4 31B for reasoning and coding, with a 256K-token context window. - Gemma 4 26B-A4B, a mixture-of-experts model for cost- and latency-sensitive use. - Gemma 4 E2B for low-latency interactive applications. - All variants support function calling, structured output, reasoning, streaming, multimodal inputs, and more than 35 languages. ## OpenSearch MCP Apps for Agentic Observability - OpenSearch MCP Apps bring logs, traces, metrics, and alerts into compatible agentic environments such as Claude Desktop and VS Code. - Agents can investigate incidents across OpenSearch and Amazon Managed Service for Prometheus. - Each tool call produces both: - A text summary for the agent. - An interactive visualization displayed in the conversation. - Available tools cover log, metric, and trace analysis; service performance; topology; agent health; cluster health; dynamic visualizations; and instrumentation scoring. ## Additional AWS Updates - AWS CLI v1 is entering maintenance mode: - Dependencies such as `botocore` and `s3transfer` will be vendored into the CLI. - Future releases will focus on critical bugs and security fixes. - AWS recommends migrating to CLI v2. - AWS Workload Credentials Provider provides short-term credentials for applications running outside AWS, including on-premises and third-party environments, without requiring long-term access keys. - Kiro Pro Max adds higher usage limits, access to newer frontier models, and additional agentic development capabilities for professional teams. AWS’s latest releases suggest that teams should prepare for AI agents to handle not only code generation, but also cost management, observability, testing, and operational workflows. Migrating to AWS CLI v2, evaluating Bedrock’s newest models, and establishing strong repository context and specifications are practical next steps.

Read original(opens in new tab)
naver1 min readCurated summary

Building a Playwright E2E Test Harness for AI Agents

The provided content is not a substantive tech blog post. It consists of a NAVER D2 navigation menu and a copyright notice, with no technical argument, explanations, or conclusions. ## NAVER D2 Sections - Links to: - Hello World - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY ## Copyright - Copyright © NAVER Corp. All Rights Reserved. No technical details or recommendations can be summarized from the provided text.

Read original(opens in new tab)
grammarly2 min readCurated summary

Say It, Then Send It with Speech to Text

Writing on a phone remains difficult because typing is slow and native dictation produces messy transcripts. Grammarly Keyboard’s speech-to-text feature aims to solve this by converting natural speech into polished, send-ready text directly within any iOS app. It removes filler words, verbal corrections, and grammar errors while preserving the speaker’s tone and intent. ## Polished Dictation Anywhere - Speech-to-text is built into the Grammarly Keyboard. - Users tap the microphone, speak naturally, and receive cleaned-up text in the active app. - The feature supports multiple languages, accents, and speaking styles. - Users can switch between dictation and typing or further edit text with Grammarly’s keyboard. - Grammarly’s AI assistant is also available within the same keyboard. ## Designed for Mobile Writing - The feature targets frequent mobile writers, including professionals, students, and people capturing ideas while away from a desk. - Noise reduction helps improve recording quality. - Recording starts only when the user taps the microphone. - An on-keyboard indicator and iOS’s orange status light show when the microphone is active. - Audio is deleted after transcription and is not stored, linked to the user’s account, or used for model training. ## How to Get Started - Download Grammarly for iOS from the App Store. - Add Grammarly under **Settings → General → Keyboard → Keyboards → Add New Keyboard**. - Enable full access so the keyboard can operate across apps. - Open any text field, tap the Grammarly microphone, and begin speaking. Grammarly’s speech-to-text is presented as a practical alternative to raw phone dictation, especially for users who want fast, polished mobile messages without manual cleanup.

Read original(opens in new tab)
github3 min readCurated summary

How we made GitHub Copilot CLI more selective about delegation

GitHub improved Copilot CLI by making subagent delegation more selective rather than treating delegation as inherently beneficial. The new orchestration policy keeps narrow tasks with the main agent, delegates broad or independent work, and encourages parallel execution instead of waiting. After full production rollout, it reduced tool failures by 23% and improved high-percentile wait times without reducing quality. ## The Cost of Unnecessary Delegation - Subagents help with complex investigations, large repositories, and parallel work, but every handoff adds tool calls, coordination, and latency. - Copilot sometimes delegated simple, well-scoped tasks that the main agent could complete directly. - Common problems included: - Repeated or overlapping repository searches. - Subagents re-discovering context already available to the main agent. - Sequential delegation that left the main agent idle. - Stale paths, incorrect relative paths, and workspace mismatches. - The result was slower execution and more tool failures for tasks that should have required only a few steps. ## How the Problem Was Identified - GitHub used LLMs to analyze complete agent trajectories rather than manually reviewing sessions. - The analysis found that delegation was frequently used for narrow, obvious, or fully described tasks. - This led to a clear target: - Keep focused discovery-and-edit work with the main agent. - Reserve subagents for broad exploration, cross-cutting tasks, or genuinely independent work. ## A More Selective Orchestration Policy - Copilot now starts with the narrowest effective workflow: - Find and read the relevant file. - Make the targeted change. - Verify the result. - Delegation becomes appropriate when additional context, uncertainty, or parallel execution creates real value. - Subagents are treated as a parallelism mechanism, not a reason for the main agent to pause. - Handoffs should clearly specify: - The user’s request. - What the main agent already knows. - Which work the subagent owns. - What result the subagent should return. ## Evaluation and Production Results - GitHub tested the change with generated regression cases and existing benchmarks before rollout. - Staff and public A/B tests measured reliability, responsiveness, subagent workload, and quality. - Production results showed: - 23% fewer tool failures per session. - 27% fewer search-tool failures. - 18% fewer edit-tool failures. - 5% lower P95 wait time. - 3% lower P75 wait time. - No quality regression. - The improvements came mainly from avoiding unnecessary subagent paths and reducing orchestration overhead, not from making individual model calls faster. Copilot CLI users can access the improvement by running `/update` and upgrading to version 1.0.42 or later. The broader recommendation is to delegate selectively: use the main agent for focused tasks and subagents only when independent context or parallel work provides meaningful leverage.

Read original(opens in new tab)
dropbox3 min readCurated summary

How Dropbox uses MCP and Dash to close the design-to-code security gap

Dropbox found a significant gap between security design reviews and implementation. Only 12% of implementing pull requests linked back to their original threat models, and the median delay between review and code submission was about five weeks. To close this gap, Dropbox built a system using Dash, Model Context Protocol (MCP), and foundational models to automatically retrieve relevant security requirements and compare them with code during review. ## The Design-to-Code Gap - Threat models document risks, attack scenarios, and agreed-upon mitigations during security review. - These documents often remain in wikis or documentation systems, while implementation happens later through pull requests. - At Dropbox: - Only 12% of implementing PRs linked to their original design review. - Among 79 verified pairs, 54% of PRs were opened more than a month after the review. - The median delay was approximately five weeks, with some delays exceeding 11 months. - Only 29% of PRs were opened within two weeks of the security review. - About 15% of design reviews were filed retroactively, suggesting that some security-sensitive work was not identified early enough. ## Why Existing Tools Fall Short - Static analysis can detect whether certain security patterns or controls exist. - It generally cannot determine whether those controls satisfy the specific requirements agreed upon during design review. - Manual linking between PRs and threat models depends on engineers remembering additional workflow steps. - Reminder bots may improve compliance temporarily, but adherence tends to decline. - The core problem is not a lack of security documentation; it is the difficulty of making that existing context available during implementation. ## Dash and MCP as a Context Bridge - Dash already indexes Dropbox content and connected applications, including threat models and engineering documentation. - Dropbox used Dash’s MCP server to let an AI security agent search and read this content. - MCP provides a common interface for bringing multiple context sources into one agent session. - When a PR is opened, the agent retrieves relevant threat models and supporting documents. - A foundational model then compares the documented requirements with the proposed code. - For example, it can identify whether code implementing an endpoint enforces authentication required by the corresponding threat model. - Unlike traditional static analysis, this approach evaluates code against documented security intent, not just known code patterns. ## Integrating Security into Code Review - Dropbox surfaced the system directly within the existing code-review workflow rather than creating a separate security process. - This allows developers and reviewers to receive relevant security context where implementation decisions are already evaluated. - The same mechanism can potentially identify missing reviews when code appears security-sensitive but has no corresponding threat model. Dropbox’s approach shows how retrieval and AI reasoning can reconnect design decisions with implementation. Organizations can apply the same pattern beyond security—for example, to compliance requirements, privacy reviews, accessibility standards, or other design-to-code checks.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Security Insights needed a 10x throughput increase to scan all customers more frequently and detect risks sooner. The existing system was overwhelmed by Kafka backlogs, slow processing, database inefficiencies, and API timeouts. Cloudflare improved capacity by introducing parallel and lane-based processing, optimizing bulk database writes, and addressing regional latency between its API and database. ## Scaling Kafka Processing - Scans are scheduled and published to Apache Kafka. - Go-based checker services consume these messages, inspect accounts, zones, and DNS records, and send findings to an internal API. - Kafka’s partition ordering limits each consumer group to one active consumer per partition. - Slow messages could block all subsequent messages in the same partition. - Adding partitions was avoided because it would increase resource usage for shared Kafka brokers. ## Introducing Parallel Processing - Checkers were changed to consume messages in batches. - Each message in a batch is processed concurrently in its own goroutine. - This increased throughput without requiring additional Kafka partitions. - The trade-offs were higher memory usage and potentially more work to repeat after a process crash. ## Separating Slow and Fast Work - Some scans took seconds or milliseconds, while unusually large accounts or zones could take minutes or hours. - These slow messages caused head-of-line blocking for faster work. - Consumer groups and checkers were split into: - A fast lane for predictable, short-running scans - A slow lane for messages expected to require substantially more time - Fast-lane consumers skipped slow messages, allowing normal scans to continue without delay. ## Optimizing Postgres Writes - The API originally executed one insert/upsert transaction per insight. - A request containing up to 500,000 insights could therefore generate hundreds of thousands of database round trips. - Bulk insertion with `COPY` into a temporary table was tested but caused bloat in Postgres system tables. - The final hybrid approach used: - `UNNEST` for smaller batches - `COPY` for batches above a configured threshold - This delivered millisecond-level performance for small writes and completion within seconds for very large writes. ## Diagnosing API Timeouts - Client-side timeouts increased as scan volume grew. - Checkers sometimes spent 20–90% of their processing time waiting on a single API call. - Throughput initially rose but then deteriorated under heavy load. - The root cause was network latency: - Postgres was hosted in Portland, Oregon. - The API ran active-active in Portland and Amsterdam. - Requests routed to Amsterdam incurred roughly 50 milliseconds of network round-trip latency. - Amsterdam database queries held client connection-pool connections much longer—nearly three seconds on average versus about 10 milliseconds in Portland. - The connection pool became exhausted, causing requests to wait for available connections and creating uneven Kafka lag across partitions. Cloudflare’s results came from improving the full processing pipeline rather than relying on a single infrastructure change. Parallelize message handling, isolate slow workloads, batch database writes, and place latency-sensitive services close to their databases to achieve large throughput gains and more frequent security scanning.

Read original(opens in new tab)
google3 min readCurated summary

A low-carbon computing platform from your retired phones

Retired smartphones can become low-carbon cloud infrastructure by reusing their still-capable motherboards instead of manufacturing new servers. Researchers at UC San Diego, with Google’s support, are developing clusters of stripped-down Pixel phones managed by Kubernetes. Their planned 2,000-phone datacenter aims to provide affordable computing for education and research while reducing hardware-related emissions. ## The Carbon Case for Reusing Smartphones - Computing emissions come from: - **Operational carbon**, produced by electricity consumed during use. - **Embodied carbon**, produced during hardware manufacturing and raw-material extraction. - Reusing phones primarily addresses embodied carbon by extending the life of components that remain functional. - Since people typically replace phones every four years, many retired devices still contain capable processors, accelerators, memory, and storage. ## Smartphone Performance and Limitations - Modern smartphone performance cores can match or exceed the per-core performance of some data-center servers. - Smartphones have significant limitations compared with servers: - Fewer, heterogeneous processor cores. - Only 8–12 GB of memory. - Less capacity for large, multithreaded workloads. - The platform therefore targets workloads that fit on a phone or can be distributed across multiple devices. ## Converting Phones into Datacenter Hardware - Unmodified phones are unsuitable for datacenters because they include unnecessary and potentially hazardous components such as: - Displays and cameras. - Batteries not designed for sustained datacenter operation. - Consumer-oriented chassis and peripherals. - Researchers remove everything except the motherboard, which accounts for roughly 50% of a phone’s embodied carbon. - Android’s mobile userspace is replaced with a general-purpose Linux distribution. - This removes mobile-specific restrictions such as Android’s “low memory killer” and enables broader server-style programmability. - Kubernetes manages containerized applications across clusters of approximately 25–50 phones, equivalent to roughly one conventional server. ## Applications for Education and Research - Many university workloads—including Jupyter notebooks, grading systems, and research applications—require modest resources that a single smartphone can provide. - Early tests showed that a 20-phone cluster could handle peak grading demand for a class of more than 75 students while achieving latency below a typical AWS backend. - The planned 2,000-phone cluster could support around 100 comparable classes simultaneously. - The deployment would provide approximately 50 server-equivalents at substantially lower cost. ## Testing Computing at Scale - The project will evaluate whether consumer smartphone hardware can operate reliably under sustained datacenter workloads. - It will also serve as a large-scale testbed for distributed smartphone computing. - The system is expected to launch at UC San Diego in fall 2026. Repurposing retired phones offers a practical way to reduce demand for newly manufactured computing hardware, especially for lightweight academic and cloud workloads. The approach is most promising when applications can tolerate distributed resources and the reliability challenges of consumer-grade components.

Read original(opens in new tab)
google3 min readCurated summary

Research into how AI can help users understand skin conditions

Google Research examined how AI tools can help non-experts understand skin conditions and decide what to do next. In a large study, AI substantially improved people’s ability to identify possible conditions, but it did not reliably improve the accuracy of recommended next steps. The research therefore argues that dermatology AI should be designed around human decision-making, safety, and clear guidance—not diagnosis alone. ## Why Dermatology AI Needs Human-Centered Research - More than half of adults use the Internet for health information, and about one-third use AI. - People often lack the medical vocabulary needed to search effectively—for example, searching for “red dots on legs” instead of “palpable purpura.” - Google Research has developed dermatology AI models, validated their generalization, and released datasets such as SCIN. - Earlier research found that online tools can improve condition recognition without necessarily helping people choose appropriate next steps. - The researchers emphasize studying how people interpret and act on AI-generated information. ## Large-Scale Evaluation of an AI Information Tool - A JAMA Dermatology study involved 2,345 participants reviewing de-identified skin-condition cases with images and structured medical histories. - Participants were assigned to one of three groups: - **Standard-search control:** Used familiar text-based search tools. - **AI group:** Used a prototype showing 3–7 AI-predicted conditions, textbook images, and information about symptoms and treatments. - **“Wizard of Oz” control:** Used the same interface, but with dermatologist-provided differential diagnoses presented as if generated by AI. - The AI interface increased participants’ willingness to name a condition: - More than 62% attempted a diagnosis with AI. - Only 41% did so using standard search. - Accuracy also improved: - AI users correctly identified a matching condition about 23% of the time. - Standard-search users achieved 8%. - The “perfect-prediction” interface reached 36%, showing that even accurate candidate lists did not make users nearly perfect. - AI users reported greater confidence, satisfaction, and satisfaction with the time spent searching. ## Identifying a Condition Does Not Guarantee Safe Action - The prototype intentionally avoided prescribing actions or making individualized diagnoses. - Treatment information was dermatologist-written and based on the condition name, rather than the severity or details of the specific case. - Choosing the right next step—such as home care, routine care, or urgent evaluation—remained difficult. - Next-step accuracy improved only slightly in the “Wizard of Oz” group, from 60% in the standard-search control to 63.5%. - The standard AI group showed no statistically significant improvement. - AI users were slightly more likely than control participants to recommend a less urgent action than dermatologists would: 30% versus 27%. - These findings show that identifying possible conditions is insufficient without stronger safety-oriented guidance. ## Studying Real Users and Diverse Communities - The researchers also conducted a qualitative study, published at ACM CHI, to examine how people use AI for their own active skin concerns. - The project partnered with Stanford’s Healthcare AI Applied Research Team and the Santa Clara Family Health Plan. - The community included many Medi-Cal users who rely on a healthcare safety net. - Researchers aimed to gather richer feedback than survey-based studies provide by observing real-world use. - Because participants spoke four primary languages, the application was translated into those languages, with multilingual volunteers or staff available to support communication. AI can make dermatology information easier to find and improve recognition of possible conditions, but it should not be treated as a substitute for professional judgment. Future tools should focus equally on urgency assessment, personalized context, uncertainty, and clear recommendations for when to seek medical care.

Read original(opens in new tab)
github1 min readCurated summary

Making secret scanning more trustworthy: Reducing false positives at scale

Mariko is a Principal Applied Scientist at Microsoft who leads the development of agentic AI workflows for cybersecurity operations. Her work centers on using large language models and agentic systems to bring frontier AI research into practical products and operational environments. ## Professional Role - Principal Applied Scientist at Microsoft. - Leads agentic AI workflow development for cybersecurity operations. ## Research and Technical Focus - LLM-powered systems. - Agentic workflows. - Applying frontier AI research to real-world products and operations. Overall, Mariko’s work connects advanced AI research with practical cybersecurity and enterprise applications.

Read original(opens in new tab)
stripe2 min readCurated summary

Stripe Projects adds new agent integrations, more providers, and custom developer controls

Agent traffic now exceeds human internet traffic, driven largely by agents independently building software and integrating APIs. Stripe reports that agents account for nearly 40% of its documentation traffic and 70% of API-resource requests through the Stripe CLI. Stripe Projects is expanding to help agents handle the infrastructure, credentials, services, and operational controls surrounding software development. ## Agent Integrations - Stripe Projects is available as a skill in Hermes, an open-source AI agent from Nous Research. - Hermes can retain context across sessions, allowing it to collaborate on complex projects over days or weeks. - Factory Droids and Warp have integrated the Projects CLI into their coding workflows. ## Expanded Provider Support - Projects now supports 49 providers, adding 16 new integrations. - New providers include: - Metronome for usage-based billing - Wix for storefronts - ClickHouse for LLM observability - Agents can provision applications, billing, storefront, monitoring, and other services without manually navigating provider dashboards. ## Controls for Safe Agent Provisioning Stripe is adding guardrails similar to those used for agent-driven purchases: - **Unified cost visibility:** Developers can view current and historical spending across providers for each project. - **Per-provider spending limits:** Teams can set different caps for services such as AI models, hosting, and databases. - **Named environments:** Isolated credentials can be created for development, staging, production, or custom environments. Agents default to development, reducing the risk of affecting production. - **Platform delegation:** Platforms can provision services for users using scoped credentials and white-labeling, keeping developers inside the platform’s environment. ## Future Direction Stripe plans to extend Projects across the full lifecycle of agent-built software, including operations and security. Planned additions include stronger security primitives for autonomous agents and a data layer that lets providers meter and bill for software created by agents. Stripe’s broader recommendation is to use Projects as an agent-accessible way to provision infrastructure—for example, asking an agent to add a Prisma database.

Read original(opens in new tab)
slack3 min readCurated summary

Agentic Testing: Where Agents Fit in the E2E Testing Stack

Agentic E2E testing validates whether users can achieve goals rather than enforcing one fixed sequence of UI actions. Slack’s experiment with more than 200 runs found that agents can reliably explore workflows, especially through Playwright MCP, but they are slower and more expensive than deterministic tests. The conclusion is that agents should complement—not replace—traditional E2E tests. ## Goal-Based Testing vs. Fixed Journeys - Traditional tests follow predefined steps: click, type, navigate, and assert. - Agent-driven tests receive a goal and adapt their actions to reach it. - Agents may use different paths to achieve the same result, such as: - Selecting a search suggestion or pressing Enter - Reusing existing navigation state or reopening a view - Adding or skipping intermediate actions - This flexibility improves exploration but introduces tradeoffs in reliability, runtime, and cost. ## Experiment Design Slack evaluated three execution models across more than 200 runs: - **Agent + Playwright MCP** - Uses predefined browser actions and persistent DOM snapshots and logs. - **Agent + Playwright CLI** - Runs Playwright commands through the shell and reassesses the UI after each step. - **Generated Playwright tests** - Produces deterministic test code from natural language, then iteratively refines it. The experiments used Claude Sonnet 4.5 for MCP and CLI workflows and Claude Opus 4.6 for generated tests. All tests ran in non-production Slack workspaces using test data. Two workflows were tested 20 times per configuration: - **Thread Reply:** A simple 15–20-step flow involving channel creation, messaging, thread replies, and verification. - **Search Discovery:** A 25–30-step flow involving search, result navigation, channels, threads, and state verification. Inputs were provided either as detailed natural-language instructions or structured YAML describing actions and expected outcomes. ## Results: Reliability, Cost, and Runtime | Approach | Thread Reply failures | Search Discovery failures | Average runtime | |---|---:|---:|---:| | Agent with Playwright MCP | 0% | Approximately 12% | 5–8 minutes | | Agent with Playwright CLI | Approximately 12% | Approximately 20% | 9–11 minutes | | Generated Playwright tests | Approximately 8% | Approximately 48% | About 3 minutes | - Playwright MCP was the most reliable agentic approach, particularly for simple workflows. - Playwright CLI failed more often due to authentication, navigation timing, and session instability. - Generated tests were fast and reasonably successful on simple flows but degraded sharply as workflows became more complex. - Generated tests often completed 70–80% of a complex workflow before failing on a final interaction or assertion. ## Why Complexity Exposes Differences - MCP maintains a live, stable view of the application through persistent context. - CLI-based agents reconstruct state from updated snapshots, allowing small timing or interpretation inconsistencies to accumulate. - Generated tests can suffer from: - Variable UI state - Imprecise element targeting - Mismatches between generated code and existing page-object abstractions - The results suggest agent-native execution models handle increasingly complex exploratory flows better than generated deterministic tests, despite taking longer. Agentic testing is best used as an exploratory layer for validating user goals and discovering unexpected paths. Deterministic Playwright tests remain preferable for fast, repeatable regression checks, while Playwright MCP appears to be the strongest option when flexible, goal-oriented E2E coverage is needed.

Read original(opens in new tab)
naver1 min readCurated summary

MLXP: Adopting Kubernetes LLM Serving Optimization Techniques

The provided text is a navigation and copyright fragment from the NAVER D2 website, not a substantive technology blog post. It lists links to D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, and D2 STARTUP FACTORY, along with a “Hello world” entry. No technical argument, explanation, or conclusion is included. ## Site Navigation - NAVER D2 - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY ## Other Content - “Hello world” appears as the only apparent post or message. - The page includes a copyright notice: “Copyright © NAVER Corp. All Rights Reserved.” There is not enough substantive content to provide a technical summary or recommendation.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8 | GitLab Docs

GitLab released patch versions 19.0.2, 18.11.5, and 18.10.8 on June 10, 2026, addressing important security and bug fixes. Self-managed installations should upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The fixes affect both CE and EE and cover account takeover, cross-site scripting, denial of service, authorization bypasses, and server-side request forgery. ## Release Scope and Upgrade Guidance - Affected self-managed installations should upgrade to the latest patch release for their supported GitLab version. - The releases apply to GitLab Community Edition and Enterprise Edition. - GitLab publishes: - Scheduled patch releases twice monthly, on the second and fourth Wednesdays. - Ad-hoc critical patches for high-severity vulnerabilities. - Security issues are generally made public on GitLab’s issue tracker 30 days after the release containing their fix. - GitLab.com has already deployed the patches, and GitLab Dedicated customers do not need to take action. ## High-Severity Enterprise Edition Vulnerabilities - **CVE-2026-6552 — Group SAML Identity API** - CVSS 8.7. - An authenticated group Owner could potentially take over another member’s GitLab account through improper authorization. - Affects GitLab EE versions before 18.10.8, 18.11.5, and 19.0.2. - **CVE-2026-10087 — Analytics Dashboard XSS** - CVSS 8.7. - An authenticated developer could execute arbitrary client-side code on behalf of another user due to inadequate input sanitization. - Affects EE versions before the patched releases. - **CVE-2026-8589 — HTML Injection in Group Settings** - CVSS 7.3. - Improper sanitization could allow unauthorized email addresses to be added to a targeted user’s account. - Requires significant privileges and user interaction. ## Denial-of-Service Vulnerabilities - **CVE-2026-7250 — Grape API JSON Parsing** - CVSS 7.5. - An unauthenticated attacker could cause denial of service through malformed API request input. - Affects CE and EE versions dating back to 12.10. - **CVE-2026-1500 — Group Placeholder Reassignments API** - CVSS 6.5. - An authenticated user could trigger uncontrolled resource consumption with a specially crafted file upload. - Affects CE and EE versions beginning with 17.10. - **CVE-2026-10733 — CI/CD Catalog HTML Injection** - CVSS 4.3. - Improper sanitization could allow an authenticated user to disrupt the CI/CD Catalog page. ## Authorization and Data-Access Issues - **CVE-2026-6269 — Merge Requests API** - CVSS 5.4. - Developers could modify hidden merge requests because of incorrect authorization enforcement. - **CVE-2026-6277 — Security Inventory** - CVSS 4.3. - Security Managers could modify project security configuration even when the related feature was disabled. - **CVE-2026-6976 — Merge Request Diff** - CVSS 3.7. - Developers could hide changes from merge request diffs through improperly handled file names. ## Server-Side Request Forgery - **CVE-2026-9204 — Gitaly Repository Import** - CVSS 5.3. - An authenticated user could potentially read arbitrary files from the Gitaly server or access internal network resources during repository import. - The issue resulted from insufficient validation of secondary URLs. ## Recommendation Administrators of self-managed GitLab instances should upgrade to 19.0.2, 18.11.5, or 18.10.8 as soon as possible, regardless of whether they use Omnibus, source installations, or Helm charts.

Read original(opens in new tab)