techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

toss4 min readCurated summary

The Monorepo Hope Edition: One Year to Bring a Despairing Repo Back to Hope

Toss argues that a monorepo alone does not guarantee a consistent or efficient frontend development experience. The real problem was dependency-version fragmentation across services, which made installations slow, platform changes risky, and upgrades difficult. Toss addressed this by introducing shared dependency “catalogs,” standardizing core libraries while preserving controlled, gradual upgrades. ## Toss’s Frontend Development Environment - More than 100 frontend engineers maintain products inside and outside the Toss app. - Despite the large number of products, services use nearly identical versions of React 19, Next.js 15, TypeScript, bundlers, and linters. - A shared monorepo makes it easier to: - Maintain a consistent development environment. - Share code across services. - Propagate platform-wide changes. - Give users access to features such as React Concurrent Mode and Server Components. ## Problems with an Unmanaged Monorepo - Services used widely different dependency versions, including outdated React and supporting libraries. - This created fragmented developer experiences: - Some services had fast development servers and modern APIs. - Older services were slower and harder to develop. - Dependency installation could take more than a minute even with caching. - Platform teams struggled to test shared libraries across many React and library versions. - Service developers avoided upgrades because compatibility risks and migration costs were high. - Older services consequently became locked into outdated dependencies. ## Why Toss Rejected a Polyrepo Strategy - Splitting the monorepo into separate repositories could reduce the size of each individual project and improve installation times. - However, polyrepos would not solve the main issues: - Development environments would remain fragmented. - Shared-code development and updates would become more expensive. - Differences between services could become even more pronounced. - Toss concluded that improving dependency management within the monorepo was preferable to abandoning it. ## Simplifying the Dependency Tree - The central issue was that services selected different versions of the same core libraries. - Toss identified roughly 10–20 commonly used libraries, including: - React - Component libraries such as TDS - Jotai - TypeScript - ESLint - Standardizing these dependencies could: - Reduce installation time. - Provide a consistent developer experience. - Make platform-library testing more predictable. - Enable automated migration scripts and compatibility layers. - Lower the cost of adopting breaking changes. - In practice, developers usually chose libraries rather than requiring specific versions, making centralized versions practical. ## Dependency Catalogs - Toss defined recommended versions as a shared **Catalog** using pnpm or Yarn workspace configuration. - Services reference catalog-managed dependencies with the `catalog:` protocol instead of specifying independent versions. - Named catalogs can support different release channels, such as: - `stable` - `beta` - Toss initially included essential dependencies such as React, Next.js, TypeScript, TDS, and the Toss App SDK. - Catalog packages had to be tested in representative service environments before release. - New services automatically referenced the latest catalog. - CI detected cases where developers accidentally bypassed catalog versions. - Existing services were migrated collaboratively with their code owners. - Catalog changes were released as new versions and rolled out gradually rather than modifying a shared version in place. - Upgrade scripts and AI Skills reduced the effort required to migrate services. ## Results After Full Adoption - Dependency duplication fell substantially: - `.pnp.cjs` shrank from 96 MB to 15 MB, an approximately 84% reduction. - Development-server startup improved from 26.7 to 20.3 seconds, about 23% faster. - Full dependency installation decreased from 528.4 to 249.9 seconds, about 52% faster. - Developers gained greater confidence that catalog packages had already been tested in real services. - Centralized version control reduced incompatible transitive dependencies, such as one package requiring version 1 while a service used version 2. - Better dependency visibility made large architectural improvements safer, including work involving RSC, TypeScript 7, Rspack, and end-to-end testing. - Services could adopt improved platform packages more consistently and with less upgrade friction. The practical recommendation is to retain the monorepo, but enforce a curated set of shared dependency versions through catalogs, CI checks, staged releases, and automated migration tooling. This combines the sharing benefits of a monorepo with a more predictable and maintainable development environment.

Read original(opens in new tab)
ReactTypeScriptMonorepoDependency Management+3
cloudflare3 min readCurated summary

Unveiling good and bad behaviors on the Agentic Internet

The Internet contains a mix of human, automated, and hybrid traffic, so classifying visitors simply as “good humans” or “bad bots” no longer works. Cloudflare argues that website owners should evaluate continuous behavior and build trust over time, rather than rely only on isolated risk checks. Its strategy combines transparent bot classification through BotBase with behavioral detection through Precursor. ## Risk and Trust Are Different - **Risk** measures how likely a request or action is to be harmful, often based on a momentary event. - **Trust** develops over time through reputation and observed behavior. - A suspicious action should not automatically lead to rejection if the actor has an established, trustworthy identity. - Cloudflare’s goal is to create incentives for safer behavior, from blocking malicious activity to enabling beneficial automated participation. ## Verified Bots and Transparency - Cloudflare defines verified bots and agents through two requirements: - They honestly declare who they are. - They do not abuse the trust they receive. - Transparency helps site owners decide which behaviors and data uses to permit. - BotBase is designed as a directory of all known bots and agents, not just approved ones. - Actors that violate expectations can lose their verified status and become harder to trust across Cloudflare’s network. ## Continuous Detection with Precursor - Precursor is a client-side system that continuously analyzes behavior throughout a session. - Its JavaScript is injected at the CDN, so customers do not need to manually place or rerun detection code. - Unlike CAPTCHAs and other one-time challenges, Precursor evaluates behavior in context over multiple pages. - Continuous analysis makes it more expensive for bot developers to imitate human behavior across an entire session. ## What Cloudflare Has Observed - In a 24-hour snapshot, Precursor processed **206 million evaluation events across 73,438 zones**. - Suspicious behavior frequently begins in the middle of a session, meaning point-in-time checks can miss it. - A single session may shift between human and automated behavior, such as when a user hands part of a shopping journey to an agent. - Site owners therefore need classifications based on use case, purpose, and data usage rather than a simple human-versus-bot decision. ## Understanding Human Cursor Behavior - **Precursor Trace** is an interactive demonstration of part of Precursor’s detection process. - It examines cursor acceleration, corrections, rhythm, and movement texture. - The demo illustrates how behavioral signals can distinguish natural interaction from automated movement. ## Adaptive Intelligence - Cloudflare indicates that its bot detection engines will soon provide more adaptive outcomes for requests identified as automated. - The excerpt ends before detailing how this upcoming capability will work. Website owners should treat automation as a spectrum: verify transparent actors, monitor behavior continuously, and make decisions based on trust, intent, and use case rather than isolated signals.

Read original(opens in new tab)
AI AgentsCloudflareJavaScriptCdn+3
cloudflare2 min readCurated summary

Announcing Cloudflare Ambassadors, Community Engineers, and another $1M in open-source funding

Cloudflare is launching an expanded community program to support people who help others build on and improve the Internet. The program has two tracks: Cloudflare Ambassadors, who grow local and online developer communities, and Cloudflare Community Engineers, who contribute to open-source projects. It also includes new funding, recognition, and improvements to Cloudflare’s growing Discord community. ## Cloudflare Ambassadors - Ambassadors bring Cloudflare into their own communities through: - Local events, meetups, hackathons, and workshops - Student groups and campus activities - Tutorials, online content, and peer support - Selected Ambassadors receive: - Event credits and marketing support - Technical resources - Greater visibility in Cloudflare’s online communities, including Discord - Ambassadors can serve for up to two years. - Applications are open through September 6, with selections announced by October 5. - Cloudflare highlights the program’s goal of helping developers—especially students overcome resource limitations and turn ideas into working products. ## Cloudflare Community Engineers - This track supports developers who maintain or contribute to open-source software that benefits the broader Internet. - Cloudflare is adding $1 million in funding over two years for grants to eligible contributors. - The initiative builds on previous investments, including: - Sponsorship of TanStack - A $1 million fund supporting the Vite community through VoidZero - Community Engineer appointments have no fixed maximum term, recognizing that open-source maintenance and major contributions do not fit neatly into annual cycles. - Initial focus areas include projects related to Cloudflare’s ecosystem, such as Astro, Agents SDK, EmDash, Hono, and Vinext. - Grants will become available through a later application process. ## Improving the Cloudflare Discord Community - Cloudflare’s Discord has grown to nearly 100,000 members since its launch in 2020. - A new Discord committee, including Ambassadors and Cloudflare staff, will focus on: - Improving discussions and community content - Connecting developers with Cloudflare experts - Organizing conversations and sessions with internal teams - Automated tools are being introduced to reduce spam, malicious links, and routine moderation work. - Cloudflare plans to open-source these Discord protection tools so other communities can use them. - The committee is intended to focus on meaningful community opportunities rather than administrative tasks. Cloudflare’s overall recommendation is to get involved through the new community program at **cloudflare.com/community**, whether by organizing developer communities or contributing to open-source projects.

Read original(opens in new tab)
DiscordCloudflareOpen SourceCloudflare Workers+4
cloudflare3 min readCurated summary

Unifying Workers AI and AI Gateway into a single AI control plane

AI Gateway and Workers AI are converging into a unified control plane for accessing models across Cloudflare and external providers. A single Workers binding or REST API can now provide inference, observability, logging, security, and billing without requiring users to choose a product upfront. Cloudflare’s longer-term goal is model-first routing, where applications request capabilities or models while the gateway handles provider selection, failover, and load balancing. ## Unified Bindings and API - The Workers AI binding and AI Gateway now share the same entrypoint. - Requests can use the built-in `default` gateway or a named gateway for separate applications and customized policies. - The unified REST API routes requests through `/ai/` endpoints, using the `cf-aig-gateway-id` header. - This removes the need to decide between Workers AI and AI Gateway before building an application. ## Automatic Observability for Workers AI - Passing `default` as the gateway ID automatically creates an AI Gateway on the first authenticated request. - Requests receive built-in: - Full request and response logging - Token tracking by model - Cost attribution - Latency and error metrics - Developers can begin with the default gateway and later switch to a named gateway for features such as custom caching or application-specific traffic separation. - The AI Gateway dashboard provides detailed visibility into prompts, responses, latency, token usage, and failures. ## Unified Billing with AI Gateway Credits - AI Gateway credits can now pay for Workers AI usage in addition to providers such as OpenAI and Anthropic. - Users can maintain one prepaid credit balance across supported providers. - Workers AI users who use unified billing receive elevated rate limits, subject to current Cloudflare policies and documentation. ## Model-First Routing - Cloudflare plans to route requests based on the desired model rather than requiring users to select a specific provider. - The gateway could handle: - Provider selection - Failover - Load balancing - Capacity management - For example, a request for a model such as Kimi K2.7 Code could be served by Workers AI, the model’s original provider, or another vetted provider hosting the same weights. - Applications could remain available if one provider is overloaded or unavailable. - Users will still be able to restrict traffic to a single provider when necessary. - Routing is intended to preserve requirements such as Zero Data Retention and maintain model quality. Cloudflare recommends using the unified binding or REST API with the default gateway to gain observability and centralized billing immediately. As model-first routing develops, applications can rely less on provider-specific infrastructure and gain greater resilience through automatic provider management.

Read original(opens in new tab)
ObservabilityRest ApiAi GatewayLoad Balancing+3
cloudflare3 min readCurated summary

Introducing Radar Researcher: An AI tool for exploring Internet data in plain language

Cloudflare Radar Researcher is an AI-powered assistant that lets users explore Radar’s Internet data through natural-language questions. It replaces manual API queries, filters, and chart hunting with interactive visualizations, explanations, follow-up questions, and auditable analysis. The beta tool is designed for both casual users and technical researchers, while grounding responses in real data from Radar’s API. ## Why Cloudflare Built Radar Researcher - Cloudflare Radar publishes global Internet data covering: - DNS queries from the 1.1.1.1 resolver - HTTP traffic across Cloudflare’s network - Internet quality measurements from Cloudflare Speed Test - Network outages and other datasets - Radar serves a wide audience, from journalists and curious users to network operators and academics. - AI lowers the barrier to using complex datasets by allowing users to ask questions without knowing a dataset’s structure, terminology, or API. - The tool is especially useful for people working under time pressure, such as journalists investigating current Internet disruptions. ## Natural-Language Data Exploration - Radar Researcher is available from every Radar page in a docked panel. - Users can: - Ask questions in plain language. - Receive short answers or more detailed reports. - View real, interactive Radar charts alongside explanations. - Continue with suggested follow-up questions. - Use text, voice input, or Radar’s search bar. - Conversations are saved in searchable history, can be pinned, and can be shared through links that expire after 30 days. - Users can inspect how the assistant interpreted their question, which datasets it queried, and how it derived its answer. ## Explaining Existing Charts - An “Explain with AI” action lets users start a conversation from any Radar visualization. - The assistant receives: - A screenshot of the chart for visual context. - The exact underlying data from Radar’s API. - The current location, date range, and applied filters. - This combination lets the model explain the exact chart being viewed while preserving numerical accuracy and context. ## Example: Internet Quality in Portugal - A user can ask about home Internet quality in Portugal without manually selecting API parameters or searching Radar pages. - Researcher queries the Internet quality API and presents the results through familiar interactive charts. - Users can ask follow-up questions, such as comparing Portugal with Spain or another neighboring country. - The assistant can also suggest related investigations, including common Internet outages. ## Example: Investigating an Internet Shutdown - Researcher can support more open-ended investigations for engineers, researchers, journalists, and network operators. - For Iran’s 2026 government-directed shutdowns, it: - Retrieved recorded outage events. - Collected corresponding HTTP traffic data. - Explained the timeline in natural language. - The analysis described traffic falling from approximately 0.58 on January 7 to nearly zero by January 9, partially recovering around January 17, and approaching normal levels by January 27. - It displayed the findings as an annotated traffic chart and a table of outages, including another shutdown beginning February 28. - Suggested follow-ups included comparing Iran’s traffic with neighboring countries. ## Cloudflare’s Technical Implementation - The application runs entirely on Cloudflare’s developer platform. - A Cloudflare Worker uses the Cloudflare Agents SDK. - Each conversation is stored in a stateful Durable Object with its own SQLite database. - Chat history, titles, and streaming responses persist even if users leave the page during generation. - Workers AI runs open models, including Kimi K2.7. - An ordered fallback chain across three model families helps maintain availability if one model provider reaches capacity. - Requests are routed through AI Gateway. Radar Researcher makes Cloudflare’s extensive public datasets easier to use without sacrificing precision or transparency. It is particularly valuable when users need fast, context-specific analysis backed by interactive charts and verifiable source data.

Read original(opens in new tab)
Large Language ModelsCloudflare WorkersDurable ObjectsSqlite+3
line4 min readCurated summary

What Is the Next Step in Personal AI Use? Conditions for Introducing an AIDD Organization Explored Through an AIDD Workshop at LY Corporation

LY Corporation argues that AI-driven development (AIDD) must evolve beyond individual experimentation into a repeatable organizational practice. AIDD integrates AI across requirements, design, implementation, and review, with AI producing drafts while people provide context, make decisions, and maintain accountability. Its workshop showed that successful adoption depends less on distributing tools than on preparing shared context, workflows, responsibilities, and decision-making structures. ## Defining AIDD - AIDD uses AI as a collaborator throughout the development lifecycle, from requirements clarification through code review. - It is neither fully delegating development to AI nor using AI as an isolated productivity assistant. - The intended workflow is: - AI creates an initial draft. - People provide intent, constraints, and judgment. - Results are reviewed and carried into subsequent development stages. - The central challenge is designing how people and AI work together across the entire process. ## Why LY Corporation Held the Workshop - Individual use of AI coding agents has become common for: - Code completion - Research - Testing - Documentation - Organizational adoption often stalls because: - Individual usage is not connected to team workflows. - Review standards for AI output are unclear. - Teams are unsure how to apply AI to existing products. - Successful experiments remain personal know-how. - “Convenience” does not translate into investment or adoption decisions. - The workshop aimed to move teams from personal AI usage toward organization-wide “AI Ready” conditions. - It involved 21 teams and 112 participants, including LINE Plus, who brought real work topics for evaluation. ## Why Participation Was Team-Based - AI creates value through workflow design, not just prompt-writing skill. - Teams must decide: - What information AI receives - Where human review occurs - Which output becomes the official deliverable - How feedback enters the existing process - Engineers alone cannot resolve these questions. Product, planning, design, leadership, and decision-makers contribute essential perspectives. - Team participation exposed hidden disagreements about consensus, ownership, review responsibilities, and decision boundaries. ## Workshop Structure - The two-day program combined learning with practical validation using real team projects. - Day one focused on: - Defining problems - Organizing requirements and context - Clarifying assumptions and priorities - Day two focused on autonomous experimentation and producing workflows applicable to actual work. - Orchestration Guild members, Developer Relations, and Technical Directors provided mentoring and helped make the learning reproducible across the company. - Informal conversations during breaks and meals also helped reveal issues and next steps that formal meetings often miss. ## Four Major Lessons ### The Greatest Value Often Comes Before Implementation - Teams initially focused on how quickly AI could write code. - In practice, the more important benefits came earlier in the process: - Breaking vague requirements into concrete issues - Defining requirements in clear language - Aligning team understanding - Identifying which decisions must come first - Turning decisions into manageable work units - AI can accelerate progress, but people must establish the problem definition and make critical judgments. ### Context, Not Tools, Is the Main Bottleneck - AI output quality depends heavily on the quality of its context. - Important context includes: - Specifications - Terminology - Constraints - Design intent - Relationships to existing code - Operational rules - Without this information, AI may generate plausible but impractical results, increasing review effort. - Organizing context must therefore be treated as core infrastructure for AI adoption, not optional preparation. ### Team Participation Reveals Organizational Issues - Individual experiments rarely expose the full set of coordination problems. - Working on a shared topic helps teams determine: - Where AI should be used - Who reviews its output - Which artifacts are authoritative - How AI-assisted work fits into existing processes - Collaboration across business, planning, design, engineering, and leadership makes implicit knowledge and conflicting assumptions visible. ### Decision-Maker Involvement Improves Follow-Through - Teams with leaders or decision-makers were more likely to turn workshop outcomes into concrete actions. - Organizational adoption requires decisions about: - Which areas to start with - Where to invest time - What to standardize - How deeply AI should be embedded into operations - Leadership participation prevents the workshop from ending as an interesting experiment and helps connect it to implementation. ## Conditions for Successful Adoption - Start with manageable topics, such as: - Requirements or issue clarification - Work requiring stakeholder alignment - Projects with accessible existing information - Small efforts where one complete cycle can be tested - Create lightweight entry points, such as applying AI to one feature, one requirements document, or one review checklist. - Make context preparation an official responsibility: - Document specifications, terminology, constraints, design intent, and decision rationale. - Allocate team and organizational time for this work rather than relying on individual goodwill. - Treat context organization as a long-term engineering asset that improves development even beyond AI use. The practical recommendation is to adopt AIDD incrementally through real team projects, while simultaneously improving shared context, review processes, role definitions, and leadership involvement. The goal is not merely to use more powerful tools, but to redesign the development system so AI-assisted work can be repeated and sustained across the organization.

Read original(opens in new tab)
Software DevelopmentCode ReviewSoftware DesignContext Engineering+4
aws3 min readCurated summary

Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore | Amazon Web Services

Amazon Bedrock AgentCore Runtime Instances provides persistent, managed compute for production AI agents that need more than short-lived invocations. It supports multi-day workflows, shared state, GPU acceleration, multi-agent collaboration, and direct OS access while AWS manages the underlying EC2 infrastructure. Runtime Instances complements AgentCore’s lightweight microVMs, enabling teams to combine fast-scaling orchestration with persistent worker environments. ## Why Persistent Compute Matters - Production agents often run for hours or days and must preserve state across workflow steps. - Complex systems may require: - Collaboration between multiple agents - Shared files and context - GPU acceleration - Direct operating-system access - Continuous execution across multiple days - Previously, teams had to provision EC2 instances, configure networking, manage sessions and scaling, and build monitoring themselves. ## What Runtime Instances Provides - AWS-managed EC2 infrastructure for hosting multiple agents in one runtime. - Shared sessions that persist for up to 14 days. - Separate dependencies and artifacts for each deployed agent. - GPU-capable infrastructure for compute-intensive workloads. - Session stop and restart capabilities to reduce idle costs. - Support for zip packages and container images. - Compatibility with frameworks such as CrewAI, LangGraph, LlamaIndex, and Strands. - Integration with existing AgentCore APIs, identity controls, and observability. - Persistent knowledge storage through Amazon EBS and AgentCore Memory. ## Combining MicroVMs and Runtime Instances - Runtime microVMs remain useful for lightweight orchestrator agents that need rapid scaling. - Runtime Instances are better suited to persistent, resource-intensive workers. - An orchestrator can: - Route tasks to specialized agents - Make API calls - Aggregate results - Instance-based workers can handle tasks such as code compilation, security scanning, or GUI automation while retaining local state. ## Shared-Filesystem Agent Example The demonstration uses two Strands Agents applications: - A code writer: - Generates Python code from a natural-language task. - Saves the result as `code.py` in a session-specific shared directory. - A code reviewer: - Reads the writer’s file from the same filesystem. - Reviews it for bugs, style issues, and suggestions. - Both applications use: - An `@app.entrypoint` decorator - A selected Bedrock model - The session ID to identify shared storage - Because both agents share the host filesystem, they exchange artifacts without API calls or explicit data transfer. ## Deployment Workflow ### Create a Capacity Provider - Select the operating system, allowed EC2 instance types, VPC, subnets, and security groups. - The example uses: - Linux 64-bit ARM - `c7g.2xlarge` - 8 vCPUs and 16 GiB of memory - A default `gp3` volume - AgentCore creates or assigns the required infrastructure role and instance profile. - Once active, most capacity provider settings cannot be changed, so configuration should be verified beforehand. ### Create a Runtime and Deploy an Agent - Create a runtime using the **Instances** compute type. - Associate it with the capacity provider. - Upload the agent package to Amazon S3. - Specify the language runtime, such as Python 3.13, and the entry-point file containing `@app.entrypoint`. - Deployment can be performed through the AWS Management Console, AgentCore CLI, AWS CLI, or infrastructure as code. Runtime Instances are a strong fit for agents with long-running, stateful, collaborative, or compute-heavy workloads. Use them alongside microVMs when a system needs both elastic orchestration and persistent worker infrastructure, while relying on EBS or AgentCore Memory for state that must outlive individual sessions.

Read original(opens in new tab)
PythonMulti Agent SystemsAmazon Bedrock AgentcoreAws Ec2+2
github3 min readCurated summary

A guide to slash commands in the GitHub Copilot app

Slash commands in the GitHub Copilot app provide quick, context-aware shortcuts for planning work, challenging decisions, automating implementation, and reviewing ideas. Unlike CLI commands, which manage terminal-oriented concerns such as directories and working paths, app commands focus on multi-session workflows and agent behavior. The post presents slash commands as a way to work faster while staying focused in the Copilot app. ## What Slash Commands Are - Type `/` in the chat composer to open an autocomplete menu of commands available in the current context. - The app manages project context visually, so commands such as `/add-dir` and `/cwd`—common in the CLI—are unnecessary. - Some commands, including `/clear` and `/model`, work in both the CLI and the app. - App-specific commands emphasize session navigation, project management, and controlling Copilot’s working mode. ## Planning Work with `/plan` `/plan` helps users think through a task before implementation and switches the session into Plan mode. - Break down new features by identifying files, components, dependencies, and implementation steps. - Prepare large refactors with an incremental migration strategy and risk assessment. - Investigate bugs by exploring possible causes and creating a diagnostic and repair plan. - Example: `/plan I need to add two-factor authentication to our application. Help me break down the work involved, identify what files need to change, and outline an implementation approach.` ## Challenging Ideas with `/spar` `/spar` acts as a critical reviewer, questioning assumptions and highlighting risks, tradeoffs, and edge cases. - Pressure-test architecture decisions such as using Redis for caching. - Compare alternatives like REST versus GraphQL or synchronous versus asynchronous processing. - Review database and infrastructure migration plans for rollout risks. - Evaluate proposed performance optimizations for hidden costs or unintended effects. ## Implementing with `/autopilot` `/autopilot` turns a high-level goal into an implementation workflow and switches the session into Autopilot mode. - Ask Copilot to implement features, update files, and modify tests. - Use it for multi-step maintenance work, including dependency upgrades, refactoring, and documentation updates. - Example tasks include adding CSV report exports or upgrading a React project while addressing breaking changes and running the test suite. ## Reviewing Ideas with `/rubber-duck` `/rubber-duck` provides an independent perspective for thinking through problems and debugging. The article introduces it as a more useful alternative to explaining an issue to a pet, but the supplied text ends before describing its full capabilities or examples. Use `/plan` to clarify the work, `/spar` to test the approach, and `/autopilot` to carry out the implementation. These commands complement the app’s visual workflow by making common Copilot interactions immediately accessible from the chat composer.

Read original(opens in new tab)
Github CopilotSlash CommandsCopilot CliAi Coding Assistant+2
github1 min readCurated summary

How we took malware advisories beyond npm

Ankit is a Senior Engineering Manager at GitHub and leads the Dependabot team within the Supply Chain Security organization. His work involves protecting more than 30 million repositories across over 34 package ecosystems, giving him extensive exposure to software supply-chain risks and attacks. ## Role and Responsibilities - Leads the Dependabot team at GitHub. - Works within GitHub’s Supply Chain Security organization. - Oversees systems monitoring 30M+ repositories. - Supports more than 34 package ecosystems. ## Security Perspective - The scale of Dependabot’s coverage exposes Ankit to a wide range of supply-chain threats. - This responsibility has made him particularly vigilant about software supply-chain attacks.

Read original(opens in new tab)
GithubSupply Chain SecurityDependabotPackage Ecosystems
kakao4 min readCurated summary

Experience Building and Operating a Personalized Airflow Testing Environment

Kakao’s data engineering team built AirZone to make Airflow DAG testing faster, easier, and safer across an ecosystem containing thousands of DAGs and multiple Hadoop clusters. Existing approaches required local setup, repeated Git synchronization, file copying, VPN access, or risky testing on production Airflow. AirZone instead creates an isolated, production-like Airflow environment for each pull request, managed through GitHub comments and Kubernetes automation. ## Limitations of Existing Testing Methods - **Local Airflow** - Requires configuring Airflow, Hadoop authentication, connections, and Docker locally. - Has a high initial setup cost and may differ from production. - **Development Airflow** - Requires committing and pushing every code change. - Git submodule updates and DAG parsing introduce long feedback delays. - **Test Airflow with SSH** - Allows files to be copied directly into a container. - Still requires copying files after every edit. - Access to production Hadoop requires connecting to a production VPN. - **Testing on production Airflow** - Heavy test DAGs consume shared scheduler, worker, and node resources. - A resource-intensive test can delay or interrupt unrelated projects. - Per-user isolation is therefore essential. ## AirZone Requirements - Provide an Airflow environment without requiring users to understand Kubernetes or Helm. - Allow code editing through a browser using Jupyter Notebook. - Execute DAGs against Hadoop and authentication mechanisms similar to production. - Create an independent environment for each pull request. - Prevent one user’s tests from affecting other workflows. ## PR-Based, Isolated Architecture - GitHub pull request comments serve as the user interface. - Users can create or delete an environment directly from a PR. - The resulting environment link is posted back to the PR. - Each PR receives a dedicated Kubernetes namespace based on the repository and PR number. - Airflow web server, scheduler, PostgreSQL, Jupyter, DAG volumes, and logs are isolated. - Multiple PRs can be tested simultaneously. - Cleanup is straightforward because the namespace defines the environment boundary. - A dedicated AirZone Helm chart packages the complete test environment. - Production-only components such as PGBouncer and external database connections are omitted where unnecessary. - Airflow, PostgreSQL, DAG storage, Jupyter, authentication, TLS, and logging are deployed together. ## Separating Requests from Deployment - `airzone-api` only validates requests: - Confirms that the PR exists and is open. - Checks branch information. - Prevents duplicate namespaces. - Kubernetes Jobs perform the long-running work: - Install the Helm release. - Run health checks. - Handle creation and deletion independently from the API process. - Job names include the operation and namespace, such as: - `create-airzone-{namespace}` - `delete-airzone-{namespace}` - Failed Jobs can be removed and recreated for retries. - Independent Job logs and status make deployment failures easier to diagnose. - A daily CronJob removes environments that remain after their PRs are closed. ## Building the Airflow Environment Each Helm deployment includes the components needed for a realistic test environment: - **Git integration:** Synchronizes the PR’s head repository and branch. - **DAG PVC:** Lets the scheduler and Jupyter use the same working directory. - **Airflow configuration:** Uses KubernetesExecutor and test-specific DAG scanning, logging, and Hadoop settings. - **Authentication:** Injects user and shared principals, keytabs, Jupyter tokens, and TLS certificates. - **Infrastructure placement:** Selects suitable node groups and a storage class in the same region. - **Centralized logging:** Connects Airflow logs to Elasticsearch and Kibana. - **Hadoop execution:** Existing infrastructure runs Hadoop tasks in dedicated pods using custom Hadoop images, Kerberos initialization, Spark, and Hive. ## Notifications and Security - KakaoWork sends: - An initial notification when a request is received. - A completion notification after deployment. - Operational error alerts. - Sensitive information, including Jupyter and Kubernetes namespace tokens, is not posted in public PR comments. - Tokens are delivered through KakaoWork instead, keeping authentication data separate from the broader PR audience. AirZone’s main recommendation is to make testing a disposable, reproducible environment tied to the pull request itself. By combining per-PR Kubernetes namespaces, Helm-based deployment, asynchronous Jobs, production-like Hadoop access, and automatic cleanup, teams can test DAGs quickly without burdening shared Airflow or production resources.

Read original(opens in new tab)
KubernetesPostgreSQLApache SparkHelm+3
cloudflare4 min readCurated summary

Building an open Agentic Internet: readable, discoverable, callable, and payable

Agents are becoming a new kind of web visitor: they fetch information, use tools, and make purchases on behalf of people, without rendering pages like traditional browsers. The post argues that the web must evolve into an “Agentic Internet” that is readable, discoverable, callable, and payable. Cloudflare advocates open standards and interoperable infrastructure so agents and website owners can cooperate rather than rely on closed platforms. ## Why the Web Must Adapt - Well-behaved bots are generating billions of requests for unchanged pages, wasting bandwidth, compute, and money. - Agents differ from conventional scrapers: - They act on behalf of paying humans or businesses. - Blocking them can mean blocking potential customers. - Treating them like ordinary scrapers prevents publishers from understanding legitimate demand. - Existing web infrastructure, analytics, and business models were designed for human visitors and pageviews, not programmatic interactions with specific outcomes. - The future could be controlled by a few platforms, or remain open through publicly implementable standards. ## Open Infrastructure for Agents - Cloudflare proposes an open ecosystem based on standards including: - **x402** for payments - **MCP** for agent tools and interactions - **Web Bot Auth** for cryptographic agent identity - **PACT** for privacy-preserving trust signals - Website owners can choose their own identity providers, payment processors, and agent partners. - Cloudflare positions itself as one participant in the infrastructure rather than a mandatory intermediary. ## Identity and Trust - **Web Bot Auth** allows agents to cryptographically identify themselves to websites instead of relying on spoofable `User-Agent` headers. - **Private Access Control Tokens (PACT)** let trusted sites anonymously vouch for agents. - These mechanisms can reduce friction for legitimate agents while giving publishers more control over access. ## Readable: Content Designed for Agents - **Markdown for Agents** provides content in a format that requires fewer tokens and less bandwidth than full human-oriented HTML. - Rendering CSS, images, advertisements, and other interface elements is wasteful when an agent only needs the underlying information. - Cloudflare’s **Kitesurf** browser is designed for agents, running on Workers per request and omitting unnecessary human-browser features. ## Discoverable: Helping Agents Find Resources - Agents need interfaces designed for machine-oriented discovery rather than conventional keyword search. - **AI Search** allows public websites to become searchable by agents. - **Agent Engine Optimization (AEO)** measures how visible a brand is across relevant AI models and agents. - Poor visibility to the agents customers use could effectively make a business invisible to those customers. ## Callable: Exposing Actions Directly - Human-oriented websites force agents to parse HTML, identify controls, and simulate clicks. - **WebMCP** lets websites expose explicit tools through the browser, including structured schemas and executable actions. - This removes the need for DOM guessing and makes interactions more reliable. - Tools run within the page, allowing them to reuse the user’s session and existing state. - **Code Mode** lets agents invoke tools by writing code, which can be faster and more precise than natural-language tool calls. - Direct endpoint usage also gives content owners clearer insight into which content and actions agents actually use. ## Payable: Building a Sustainable Economic Model - Advertising depends on pageviews, rendered ads, and human attention—none of which necessarily occur during agent interactions. - Seat-based pricing is also poorly suited to software agents acting for users. - Micropayments could allow publishers to charge for individual fetches or articles: - Recipe sites might charge fractions of a cent per request. - Newspapers could license articles at read time without requiring a separate subscription. - Agents could use wallets and budgets configured by their users. - Payment standards such as **x402** are presented as a foundation for direct transactions between agents and merchants. ## Practical Conclusion The Agentic Internet will succeed if agents can reliably identify themselves, read content efficiently, discover useful resources, invoke structured actions, and pay directly. Open standards and interoperable systems are preferable to a future where a small number of platforms control discovery, identity, and commerce.

Read original(opens in new tab)
Cloudflare WorkersWebmcpX402Agentic Internet+2
cloudflare3 min readCurated summary

Cloudflare AI Search: give your agents a search engine for your data

Cloudflare AI Search now automates the components previously needed to build a search system, including crawling, ingestion, embeddings, vector storage, and retrieval. The update adds sitemap-free website discovery, public and custom-domain endpoints, MCP support, and integrations such as EmDash. Cloudflare is also previewing predictable pricing by including embedding and reranking costs when using select default Workers AI models. ## Easier Data Indexing - AI Search can index structured and unstructured data, including files and websites. - Website sources currently must be owned or verified through a Cloudflare zone. - The new **Discover** parsing mode crawls sites without requiring a sitemap by following links, powered by Browser Run’s `/crawl`. - A single AI Search instance can ingest, embed, and retrieve content from a website or collection of sites. ## Unified Search Across Multiple Sources - Multiple AI Search instances can be grouped into a namespace and queried together. - Users can enable public URLs to receive: - `/search` for search requests - `/mcp` for Model Context Protocol integrations - These endpoints can search across multiple websites or instances without requiring authentication. - A Worker can also bind to a namespace and perform a single multi-instance search, with results tagged and cited by source. ## Custom Domains and Access Control - Public endpoints can use custom domains such as `search.example.com/mcp`. - Cloudflare Access can be placed in front of these domains to make search private. - This supports both easily shareable public search and authenticated search for authorized users or agents. ## Pricing Model - Cloudflare is previewing a predictable, scalable pricing model for AI Search. - Embedding and reranking are included at no additional cost when using select default models from the Workers AI catalog. - Customers therefore do not need to estimate token usage for those operations. ## Cloudflare Dev Stack MCP Cloudflare uses AI Search to power its Dev Stack MCP server, which provides coding agents with current, cited documentation. - Separate instances index Cloudflare Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, and OpenNext. - These sources can be combined because Cloudflare owns the underlying website data. - A Worker-based MCP server searches all relevant instances in one call. - Search results include citations and identify the originating instance. - Users can alternatively enable public namespace endpoints without writing or deploying a Worker. - The MCP server can be added to an agent with a configuration such as: ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` ## Additional Integrations - Cloudflare’s Blog, Developer Docs, and Cloudflare.com use AI Search internally. - The open-source EmDash CMS has an AI Search plugin that adds semantic search to site content. - AI Search is also used in Cloudflare’s own MCP and documentation experiences. For an existing application or MCP server, the Worker binding offers the most flexibility. For a quick, shareable search service, public `/search` and `/mcp` endpoints provide a simpler deployment path, with custom domains and Cloudflare Access available for branding and security.

Read original(opens in new tab)
Model Context ProtocolCloudflare WorkersEmbeddingsCloudflare Access+4
cloudflare4 min readCurated summary

From ranking to recommended: get your site ready to thrive in the age of AI agents

AI assistants are becoming a major channel through which customers discover, compare, and purchase from businesses. As agents replace traditional search journeys, discoverability increasingly depends on whether a site is easy for machines to access, understand, trust, and recommend. Cloudflare’s Agent Readiness and Answer Engine Optimization (AEO) tools measure both technical accessibility and visibility in AI-generated recommendations. ## The Rise of the Agentic Audience - Fewer than half of HTML page requests reportedly come from humans, with the remainder including crawlers, bots, and increasingly capable agents. - Customers may ask AI assistants for: - Solutions to specific problems - Recommendations tailored to their needs - Comparisons between products or services - Actions performed on their behalf - Traditional metrics such as clicks and page views do not show whether AI systems can use a site or recommend it. - Agent-focused discoverability requires being found, read, and confidently cited by answer engines, shopping assistants, and research tools. ## Diagnostics: Measuring Agent Readiness Cloudflare’s Diagnostics feature evaluates a site from an agent’s perspective rather than simply loading its homepage. - It checks whether agents: - Are permitted to access the site - Can discover its content - Can retrieve clean, machine-readable content - Can identify callable interfaces and authentication methods - Diagnostic checks examine: - `robots.txt` - XML sitemaps - Response headers - Markdown content - Published metadata - APIs and agent-facing tools - Results are grouped into readiness levels from “Not Ready” to fully agent-native. - Each check returns: - Pass, fail, or neutral status - An explanation of its significance - Evidence showing the exact request and response ### Diagnostic Improvement Areas - **Quick wins:** Crawler-readable `robots.txt`, XML sitemaps, AI-crawler rules, and clean Markdown. - **Technical groundwork:** Content Signals, API catalogs, link headers, and agent login instructions. - **Advanced integration:** OAuth discovery, MCP, A2A agent cards, skills indexes, Web Bot Auth, and WebMCP. - **Commerce:** Emerging standards such as x402, ACP, UCP, and AP2. These are currently informational and do not affect the readiness score. - Recommended fixes either link directly to Cloudflare settings or generate a coding prompt that can be given to an agent. ## AEO: Measuring AI Recommendations Agent Readiness shows whether agents can access a site; AEO measures whether assistants actually recommend it. - Cloudflare infers a site’s industry and category, then tests likely customer prompts against assistants such as Claude and GPT. - Prompts cover recommendations, product comparisons, and general category advice without naming the customer’s brand. - AEO reports several visibility metrics: - **Citation Rate:** How often the site is cited as a source. - **Prominence:** How early and substantially the site appears in an answer. - **Mention Rate:** How often the brand is named, even without a source citation. - **Share of Voice:** The site’s share of citations compared with competitors. - Comparing mention and citation rates distinguishes brand awareness from authoritative attribution. ## Category Benchmarks and Industry Fit Cloudflare builds a benchmark for each industry and category before scoring individual sites. - AI assistants are queried with representative prompts to identify: - Which sites are cited - Where citations appear - How prominently each brand is represented - The benchmark is reused across accounts in the same category rather than regenerated for every scan. - This approach provides: - Instant result loading - Lower AI-compute costs - An **Industry Fit** score showing whether the site appears alongside its real competitors ## Multimodel Evaluation Because AI responses vary, Cloudflare queries assistants multiple times across different models using AI Gateway. - The system analyzes the actual answer text and cited sources customers would see. - Workers AI evaluates citation and mention patterns on Cloudflare’s infrastructure. - Exact text analysis is used alongside model-based judgment, rather than asking a model to grade its own response. - The process converts many variable responses into consistent, actionable metrics without requiring site owners to build their own evaluation framework. ## Operator Activity Cloudflare also reports real crawl and referral activity from AI operators. - Activity is shown by operator, including OpenAI and Google. - Site owners can see: - Which operators read their content - Which operators send visitors back - Errors encountered during crawling, such as `403` blocks and `404` links The broader goal is to connect controlled AEO benchmarks with real-world agent traffic, helping businesses understand both how AI systems perceive them and whether those systems can successfully access and use their sites. Businesses should treat agents as a core audience: first make the site technically accessible and machine-readable, then measure whether AI assistants cite and recommend it. Acting early may provide an advantage because most websites are not yet optimized for agent discovery.

Read original(opens in new tab)
Model Context ProtocolCloudflareOauthAi Gateway+4
cloudflare3 min readCurated summary

The next generation of MCP

MCP’s latest specification makes the protocol fully stateless, removing the session management and persistent connections that complicated remote deployments. Requests now carry the information they need, enabling MCP servers to run on simpler request-scoped infrastructure such as serverless Workers. The update also redesigns elicitation, improves HTTP observability, and strengthens authorization practices. ## MCP Becomes Stateless - Earlier MCP implementations required an `initialize`/`initialized` handshake and an `Mcp-Session-Id` for subsequent requests. - Stateful sessions created operational challenges: - Sticky-session routing - Open-stream management - Session migration during deployments - Reconnection problems when instances disappeared - The new protocol removes: - The mandatory handshake - `Mcp-Session-Id` - Protocol sessions from the core request path - Each request includes its protocol version, client identity, and capabilities. - `server/discover` is available for optional server inspection. - MCP servers can now execute a request and return its result without storing protocol state. - Cloudflare’s `McpAgent` is no longer required for MCP itself; developers can use `createMcpHandler` and deploy on Workers. - Durable Objects remain useful when the application—not MCP—requires state, persistence, or real-time coordination. ## Elicitation Uses Multi Round-Trip Requests - Elicitation allows servers to request additional information or approval, such as confirming a deployment or refund. - Previously, `elicitation/create` depended on an open stream, adding timeout, scaling, and infrastructure complexity. - The new Multi Round-Trip Request model works as follows: - The server returns an `input_required` result. - The client gathers the user’s response. - The client retries the operation with the requested input. - This is a breaking change from the previous approach but removes the need to preserve a transport session. ## HTTP Infrastructure Can Inspect MCP Requests - Streamable HTTP requests now include `Mcp-Method` and `Mcp-Name` headers. - Gateways, rate limiters, and web application firewalls can identify operations such as `tools/call` without parsing JSON-RPC bodies. - Operators can apply method-specific policies and collect tool-level metrics using standard HTTP infrastructure. - Results from `tools/list`, `prompts/list`, `resources/list`, and `resources/read` can include: - `ttlMs` hints - `cacheScope` hints - Deterministically ordered tool catalogs help clients reuse results and maintain stable prompt caches. ## Authorization Continues to Evolve - The specification prioritizes authorization approaches in this order: - Pre-registered clients when an established relationship exists - Client ID Metadata Documents (CIMD) for dynamic registration - Dynamic Client Registration (DCR) as a fallback - DCR is deprecated for new implementations, although the provided text ends before describing the full authorization changes. The new MCP specification significantly reduces deployment complexity by making the protocol request-oriented rather than session-oriented. Developers should migrate from `McpAgent` to `createMcpHandler` where application state is unnecessary, adopt MRTR for elicitation, and update HTTP and authorization integrations to use the new headers and registration guidance.

Read original(opens in new tab)
Model Context ProtocolCloudflare WorkersDurable ObjectsJson Rpc+2
cloudflare3 min readCurated summary

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers

Cloudflare argues that AI agents need a browser optimized for machine tasks rather than human browsing. Chromium provides far more functionality than agents require while consuming too much memory and compute, limiting accessibility and scalability. The company therefore built Kitesurf, a lightweight browser running entirely on Workers and designed for agentic workloads. ## Why Cloudflare Built a New Browser - Cloudflare had repeatedly considered building a browser but previously found the technical investment difficult to justify. - Recent advances in its Developer Platform changed the equation: - Mature WebAssembly support in Workers - Dynamic workers - SQLite-based Durable Objects - Worker-to-worker RPC and service bindings - Improved Node.js compatibility and higher platform limits - Growing demand for AI browser automation exposed Chromium’s limitations: - High CPU and memory consumption - Expensive dedicated browser instances - Poor scalability for large numbers of agents ## Designing for Agents Instead of Humans - Agents prioritize: - Low token counts - Large context windows - Scalability and performance - Low operating costs - Structured, machine-readable content - They do not need many human-oriented features, such as: - Tabs, themes, extensions, and device synchronization - Pixel-perfect rendering - Smooth 60-frame-per-second scrolling - AI browser security requires a different threat model, with prompt injection and tool safety treated as central concerns. - Kitesurf became the result: a browser available in beta through Cloudflare’s Browser Run product. ## From Prototype to Product - The project began with inspiration from Obscura, a lightweight Rust headless engine for AI automation. - Cloudflare used an AI agent to attempt a port to Workers. - The first prototype was weak, but a detailed plan and explicit success criteria allowed the agent to iterate effectively. - The promising proof of concept led the team to develop Kitesurf further. ## Testing as a Foundation - Cloudflare relied heavily on automated testing to accelerate development without sacrificing quality. - Web Platform Tests (WPT) provided standards-based criteria for implementing browser features. - Engineers curated feature assignments and sequencing so AI agents could work toward measurable goals. - Because WPT does not fully capture real-world website behavior, Cloudflare added: - Multistep Puppeteer integration tests - Comparisons against Chromium - Visual regression checks at every interaction step - This combination tested both standards conformance and practical rendering behavior. ## Rust and WebAssembly - Kitesurf uses Rust wherever possible and compiles directly to WebAssembly with `wasm-bindgen`. - This avoids the bulk and performance costs associated with Emscripten’s emulation layers and mocked dependencies. - The approach allows browser components to run closer to native performance inside Workers. ## Resilience Through Exception Handling - Since browsers must process unreliable and potentially hostile web content, failures must not terminate entire sessions. - Kitesurf follows a strict rule: - Errors degrade to a blank frame or missing element - Faults are caught at component boundaries - Safe empty defaults are used - Diagnostic information is logged - This makes individual rendering failures survivable rather than allowing malformed input to crash the browser. ## Isolation and Statelessness - Every page load is treated as untrusted input. - Sessions begin fresh, and components receive only the resources they require. - Workers provide isolation boundaries, but Kitesurf also enforces isolation within the application itself to prevent data leakage between pages. - Components are kept stateless wherever possible: - Failed components can simply be recreated - Work can be scaled horizontally and run in parallel - Burst-based workloads avoid the cost of maintaining idle instances - Recovery can consist of restarting a component and replaying a request Kitesurf’s central recommendation is to build browsers around the needs of their users—in this case, AI agents. By sacrificing human-focused features and emphasizing efficiency, structured output, isolation, resilience, and scale, Cloudflare aims to make browser automation practical for a much broader range of agentic applications.

Read original(opens in new tab)
AI AgentsCloudflare WorkersRustWebassembly+4