Code Mode: Let the Code do the Talking

A couple of tools and a short agent run are manageable. Add Google services, Jira, and a wiki, and hundreds of tool definitions start crowding the model’s context. Completing a task also becomes a sequence of exchanges: request an operation, return its result, ask the model what to do next. Composition gets awkward, and each round trip adds delay.

Sunil Pai’s alternative is to ask the model for JavaScript that runs against an exposed environment. Instead of expressing every step through another JSON tool call, the model writes a program. A typed API gives it a structure to work against; syntax checking and type checking offer feedback; and programming languages already have extensive representation in model training data.

Move the composition into code. A single execution can loop through results, retain intermediate state, sequence dependent operations, and parallelize independent ones. The underlying API requests still happen, but the model need not intervene between every pair of requests. These are ordinary programming capabilities applied to agent execution.

Cloudflare’s API makes the scaling problem concrete. Pai credits colleague Matt Carey with applying Code Mode to a surface he estimates at roughly 2,600 endpoints. Pai estimates that exposing each endpoint as an individual tool would require about 1.2 million tokens in the first call. The problem arrives before the agent has done any useful work: describing everything it could do overwhelms the interface.

Carey’s implementation exposes just two tools, both accepting a string of code:

The complete OpenAPI document is available to the search program on the server; it is not inserted wholesale into the model’s context. The program selects the relevant information and returns it. The model can then write execution code using the operations it discovered. This separates discovering capabilities from using capabilities.

Pai reports reducing that tool-description footprint to roughly 1,000 tokens, approximately a 99.9% reduction. His spoken baseline varies from 1.2 to 1.5 million tokens; Carey’s published measurement compares approximately 1.17 million tokens of equivalent tool definitions with about 1,000 for the two-tool interface, using tiktoken. The comparison concerns tool-surface context overhead, not total task tokens or latency. The API remains broad; its full description no longer has to accompany every initial request.

Consider an incident request: the website is being DDoSed, and the customer wants the attacking IP addresses identified and blocked. At three in the morning, navigating a complicated dashboard is an expensive way to express an otherwise direct intention.

Pai estimates about eight conventional MCP round trips for the illustrative DDoS task, versus one composed JavaScript execution near the API. That is a comparison of orchestration: the generated program still calls the necessary API functions, but it can carry results between them without asking the model to select each next step. The eight-round-trip figure is an estimate for the example, not a measured incident-response benchmark.

The live demonstration uses a smaller request: list the account’s Workers. Pai gives the demo read-only access and approves an allow interaction. The intended sequence is straightforward:

1. Search for API endpoints matching the Workers-listing task.
2. Generate code that calls the discovered listing endpoint.
3. Return the resulting Workers to the user.

The visible run reaches endpoint discovery and generated execution code.

Then it encounters JavaScript errors and appears to attempt pagination. Pai says he tested it ten times before going onstage, but the stage run does not establish a clean end-to-end completion. He points to Workers being listed and suggests the remaining trouble might be rendering. The demonstration therefore shows discovery and execution activity, with an unresolved failure in the overall interaction. A smaller tool interface does not eliminate mistakes in generated programs or result handling.

Optimizing an MCP server is only the first application. The larger possibility is a different way for people to interact with systems: describe a task, then let generated code perform the custom combination of operations it requires.

Suppose there are 200 photos on a desktop that need categorizing and renaming. A programmer opens an editor and writes a script, perhaps sending each image to a vision model for a caption before renaming it. A nontechnical user has to ask someone for help or find an application whose built-in workflow comes close. Pai caricatures that second option as a generic photo-management subscription with an unnecessary background daemon. The underlying limitation is real: the application’s predefined interface determines which combinations are convenient.

A language model can translate a request to rename files by date and location into code that operates on the exposed system. The user gains access to a task-specific script without needing to write it. This moves the boundary between what a programmer can customize and what everyone else must accept from a product’s buttons and forms.

Kenton Varda, introduced as the creator of Cloudflare Workers, explored this boundary in a personal coding environment. He asked it to generate a drawing canvas in the style of tldraw or Excalidraw, complete with brushes and colors. On that canvas, he drew a Tic-Tac-Toe grid and an X in the top-left corner.

When Kenton asked the model to play Tic-Tac-Toe with him, it initially started generating a new Tic-Tac-Toe application. He stopped it. The existing application already exposed its state: an array of strokes, each made from points. The grid lines and X were present in that array. He redirected the model to inspect the state and play there.

The model brought the stroke data into its context, recognized the board and the X in the top-left cell, and drew a circle in the center. There was no Tic-Tac-Toe code in the application. The model interpreted a general drawing representation and used the same representation to make its move.

At the data level, the change can be as small as appending one stroke. This JavaScript expresses that operation using a teaching board with grid lines at coordinates 100 and 200, an X in the top-left cell, and a circle centered at (150, 150):

const strokes = [
  { id: "grid-v1", points: [[100, 0], [100, 300]] },
  { id: "grid-v2", points: [[200, 0], [200, 300]] },
  { id: "grid-h1", points: [[0, 100], [300, 100]] },
  { id: "grid-h2", points: [[0, 200], [300, 200]] },
  { id: "x-down", points: [[25, 25], [75, 75]] },
  { id: "x-up", points: [[25, 75], [75, 25]] }
];

const circle = Array.from({ length: 65 }, (_, i) => {
  const angle = (i / 64) * 2 * Math.PI;
  return [
    150 + 30 * Math.cos(angle),
    150 + 30 * Math.sin(angle)
  ];
});

const nextStrokes = [
  ...strokes,
  { id: "o-center", points: circle }
];

The existing strokes stay intact. nextStrokes adds the center move in the format the canvas already understands; no separate game interface is necessary.

Pai reports that Opus eventually lost the game, and that its reasoning traces suggested it had let Kenton win. That is his interpretation of the traces. The architectural observation does not depend on playing strength: the model could participate by reading and changing existing application state.

Pai describes the shift as the model having “started inhabiting the state machine.” It stopped building another application and began acting within the one that already existed. He presents this as an exploratory direction, with a Ghost in the Shell reference, rather than a settled architecture with all its implications worked out.

This helps explain the growing interest in agent harnesses. Coding agents can serve as general-purpose computing interfaces because they can generate the programs needed for a particular task. Pai points to people running Pi on Mac minis, while questioning the need for dedicated hardware merely to make API calls. The useful abstraction is the harness, wherever it runs.

A harness supplies more than code generation. It provides a safe execution space and exposes the capabilities that generated code may use. Intent becomes code; code enters a scoped runtime; the runtime connects it to selected system operations. The scope of those operations determines what the agent can actually do.

The word sandbox covers several different designs. Cloudflare’s container- and VM-based Sandbox SDK is not the environment Pai means here. His contrast is between surrounding a feature-rich environment with security controls and starting with an environment that can only execute code. Initially, it has no exposed APIs and cannot make fetch requests. Capabilities are then granted explicitly.

Cloudflare implements this approach with Dynamic Workers and V8 isolates. Pai emphasizes fast startup and cites roughly ten years of security hardening. The important property is not JavaScript by itself: the host controls which APIs are exposed and which outgoing network connections are possible.

His recommended default is no outgoing fetches, only exposed APIs. Network isolation must be configured; it is not an automatic property of an isolate. The SDK revision available before the talk documents default fetch/connect blocking in DynamicWorkerExecutor, while Dynamic Worker configuration supports globalOutbound: null. A generated program’s authority comes from the capabilities the host grants, rather than unrestricted access to the network.

The runtime also needs observability at the level of the generated code. Pai’s deliberately absurd example is investigating why an agent made a multimillion-dollar trade the previous Tuesday: the operator needs to recover the program responsible and understand what it did. Fast startup without an inspectable execution history is insufficient for consequential actions.

V8 is one implementation choice. WebAssembly or a custom JavaScript interpreter could serve the same role if they provide controlled capabilities and fast execution. The architectural requirements survive the runtime choice: a bounded execution environment, explicit authority, and enough visibility to explain its actions.

Once a program can execute against controlled capabilities, the next question is how long it can live. Pai proposes extending a one-off API operation into workflows that run for days, months, or years, with each instance carrying state through its lifetime. Those persistent instances could also support interfaces tailored to individual users. These are proposed extensions beyond the demonstrated API run.

E-commerce illustrates the opportunity. As a store serves more people, its interface tends toward something generic enough to work for everyone. Personalization often changes a small detail, such as a button color. Pai proposes generating a substantially different interface for the task at hand—although he jokes that the Opus-generated slide illustrating this idea still looks poor.

The store already has context: preferences, cart contents, orders, and clues about what might be frustrating the customer. That context can become actions in a generated interface. It need not be delivered through a blank chat box.

• Return and replacement: A customer wants to return shoes and find something similar under $100. The interface could combine those operations even if product engineers never built that exact flow.
• Delayed order: Another customer wants to know what happened to an overdue purchase. Their interface should surface the relevant order and resolution actions instead.

The proposal is to generate different programs for different users while keeping them backed by the system the product team built.

The harness need not live inside a single product. Placing it closer to the user—even on an iPhone—could let it combine capabilities from several services, task by task, inside the same safe environment. Placement changes which systems can be brought together around the user’s intent.

For UI developers, this reopens the question of what an interface should be. Pai characterizes generated code plus safe execution as an underexplored branch of software design. The possibility is not simply another way to generate screens: the program that mediates between a person and their services can itself be assembled for the occasion.

Humans remain the customers, but increasingly the immediate clients of software systems will be agents generating code. Pai’s rhetorical billion new users are these software intermediaries. Serving the human therefore includes making the system legible and usable to the agent acting for them.

That calls for a deliberate developer experience:

• Discovery: Registries and search should help an agent find the operations it needs.
• Contracts: Types and syntax feedback should make valid interactions easier to construct.
• Documentation: Markdown should make the system’s behavior accessible as text.
• Recovery: Errors should tell the agent what it can do next.

These are familiar developer concerns, now applied to clients that synthesize their own programs during a task.

Capability-based security is the principle Pai most wants builders to retain. JavaScript is incidental: Python, WebAssembly, or even a renewed interest in Lisp could support the same direction. The recurring runtime needs are events, sandboxing, explicit capabilities, embeddability, fast startup, and ephemeral execution.

Pai expects React and other UI programmers to have an advantage because they have spent so much time close to users. Understanding what a person is trying to accomplish remains valuable even when the interface and its coordinating program can be generated dynamically.

For a long time, programmers had code’s flexibility while everyone else had buttons and forms. That distinction is beginning to break. Generated code can become the means by which a person’s particular intention reaches the systems they use, instead of requiring that intention to fit an existing screen.

“Let the code do the talking” names this interaction model: code performs the work between human intent and system capabilities. Pai leaves it as an opening research direction—how to give more people the flexibility of programming while keeping execution understandable and its authority controlled.