Claude Code & the evolution of agentic coding

What should a programming tool look like when the model inside it improves faster than the product around it? Boris Cherny, Anthropic technical staff and creator of Claude Code, opens with that problem. Claude is becoming more capable at coding, but the team is still discovering which interfaces make that capability useful. Claude Code therefore starts with a deliberately small, unopinionated product: enough structure to do real work, without assuming that the right interaction has already been found.

At the time of the talk, Cherny points users to the Claude Code installation page or npm. He also announces that Claude Pro support arrived the previous day, alongside existing Max support. These are the entry points into the product as presented in the recording; the larger question is what happens after installation.

Programming once meant manipulating physical objects. Cherny traces a broad progression from switchboards to punch cards, then makes that history tangible through his family: his grandfather programmed in the Soviet Union and brought stacks of cards home from work. Cherny’s mother would draw on them with crayons. The program was something a child could pick up and mark.

His historical sketch then moves through assembly, COBOL, typed languages, and C++, followed by the proliferation of language families associated with Haskell, JavaScript, Java, and Python. Each step raises the level at which a programmer describes work. By the time he reaches TypeScript, Rust, Swift, and Go, Cherny feels that many everyday abstractions have begun to converge. That is a characterization of the experience of using these languages, not a claim that their semantics or capabilities are interchangeable.

The language and the interface for manipulating it evolve separately. Punch-card programming used a machine resembling a typewriter; later, text editors and integrated development environments changed how people interacted with software. Cherny’s distinction is that language abstractions appear to be leveling out while model capabilities—and the possible interfaces around them—are accelerating. The IBM 029 keypunch supplies the physical reference point: a substantial piece of equipment for turning keystrokes into holes in cards.

Next comes ed, Ken Thompson’s early Unix line editor at Bell Labs. It was not the first text editor: Dennis Ritchie’s history of QED describes predecessors and identifies Thompson’s contribution. What matters here is how closely ed fits its hardware. Built for teletypes that printed on paper, it had no screen cursor or scrollback to navigate. Its sparse command interaction was a practical response to a machine that could print output but could not redraw a screen.

Moving past the innovations of Vim and Emacs, Cherny highlights Smalltalk-80 as a major graphical step. Its environment combined object-oriented programming with live interaction: changes could appear in a running system. His comparison with the effort sometimes required to configure React live reload makes a useful point—an older environment can still offer an interaction that newer stacks struggle to reproduce smoothly. He then presents Visual Basic as a major route by which graphical programming reached mainstream developers.

Eclipse adds another distinct mechanism: static-analysis completion. It indexes symbols, determines which are relevant, and ranks suggestions. That is different from generating code with a model. Its extension ecosystem also expands the environment beyond its built-in capabilities. Copilot then advances from single-line to multiline suggestions; Devin represents the next abstraction in Cherny’s account, where a natural-language request can initiate programming work without the user first writing the code.

As the interface changes, verification must change alongside it. Cherny moves from manual debugging and physical inspection of outputs to techniques that explore behavior probabilistically, including fuzzing, vulnerability testing, and Netflix-style chaos testing. Generating more code does not remove the need to determine whether it behaves correctly.

Claude Code’s response is to start with the terminal and expose the model as directly as possible while remaining productive. It imposes relatively little interface scaffolding because Anthropic wants people to experience the model’s capabilities—and because the team does not yet know the best UX. Generality is the design choice: let the model use existing tools and fit into existing workflows instead of requiring every workflow to fit a new product structure.

Cherny connects this choice to Rich Sutton’s The Bitter Lesson, which he keeps displayed beside his workspace. Sutton’s argument concerns general methods, especially search and learning, that benefit from increasing computation. Cherny extends that intuition to product design: a general interface may benefit from model improvements more readily than elaborate special-purpose scaffolding. His expectation of exponential model and interface progress is his own framing, rather than a law established by the essay.

The practical result is one product with several surfaces. Run claude in iTerm2, WSL, an SSH connection, a tmux session, or the terminal inside VS Code or Cursor. Inside an IDE, Claude Code adds a small amount of integration: diffs appear in the editor instead of only inline in the terminal, and diagnostics enter the model’s context. Cherny acknowledges that this is less polished than Cursor or Windsurf, both of which he says he uses. The integration supplies useful editor feedback while preserving direct access to the model.

The Claude Code Action moves that same capability into GitHub. The setup flow presented is short: open Claude Code, run /install-github-app, and select a repository. Cherny describes this as using the user’s existing compute and stack, with setup taking a few minutes. His accompanying statement that data stays on that compute needs a narrower interpretation: the action executes on a GitHub runner, but calls the selected model provider for inference. Runner execution does not mean that all processing is local or that no data leaves the runner.

The most flexible surface is what the talk calls the SDK: invoke claude -p programmatically and build the surrounding integration yourself. This removes the need to adopt the interactive terminal UI, IDE integration, or GitHub interface. Cherny’s concrete example is incident triage: pipe GCP logs into Claude, then process the result with jq. The model becomes one stage in a Unix pipeline, accepting input from one tool and returning output for another.

For a local export of GCP logs, that composition can be expressed in shell as:

claude -p 'Analyze these GCP logs for incident triage. Return only a JSON object with summary, likely_causes, and next_checks.' \
  < gcp-logs.json \
  | jq .

Here the prompt requests JSON and jq parses the returned text; malformed JSON will fail at that boundary. The example retains the talk’s CLI-based integration rather than substituting a later SDK package. Cherny regards this use of models as Unix utilities as largely unexplored: the simple interface lets developers discover useful compositions without waiting for a dedicated product feature.

The easiest starting workflow is codebase Q&A. A new user can ask how a system works before asking the agent to change it. At Anthropic, Cherny says engineers learn Claude Code on their first day. Cherny estimates that internal onboarding fell from two or three weeks to perhaps two days after introducing Claude Code. This is an internal estimate, not a controlled productivity benchmark. The immediate benefit is that newcomers can investigate the repository without routing every question through a colleague.

The same retrieval capability helps with work already completed. Before the weekly Monday stand-up, Cherny asks what he shipped during the preceding week. Claude examines his Git commits and produces a work-history summary, so he does not have to maintain that account separately.

Tool integration also becomes a different kind of task. Traditional editors often require plugins written for their extension systems. An agent can instead learn to use an existing command-line tool:

1. Make the CLI available through its shell tools.
2. Ask Claude to run the CLI’s --help command.
3. Have it record the useful usage instructions in CLAUDE.md.

The tool remains an ordinary CLI; the persistent instructions tell the agent how to operate it. Cherny also points to MCP tools for grouped capabilities and richer integrations, including streaming. A bespoke editor extension is not necessary for every tool the agent needs.

These tools do more than write code, so an effective workflow need not start with implementation. Cherny first asks Claude to explore, make a plan, and bring that plan back for review before editing. The ordering matters for extended thinking too: use tools to gather relevant code and other evidence, then reason over that context. In his experience, thinking before the agent has gathered useful information can spend tokens without producing much value.

His second workflow is test-driven development. He finds it easier to sustain when the model performs the mechanical steps:

1. Describe the required tests clearly and state that the implementation does not exist yet.
2. Ask Claude to write the tests without running them at this initial stage, then commit them.
3. Ask it to write the implementation, then commit the code.

The instruction not to run the tests yet is part of Cherny’s specific sequence: otherwise the agent may immediately try to run them and respond to the expected failures. Separating the test definition from implementation gives the subsequent work an explicit target.

An observable target makes iteration possible. Unit and integration tests are one form of feedback; screenshots from an iOS simulator or Puppeteer are another. In each case, the agent needs a way to inspect what its actions produced. Cherny extends the idea beyond software with a 3D-printer example: Claude could operate the printer and inspect its output through a camera. He reports that later attempts improved on the first. The mechanism is the feedback loop—produce an output, observe it, and revise—not a claim that a particular number of attempts guarantees success.

Plan mode turns the explore-and-review workflow into a product affordance. Announcing its launch during the talk, Cherny demonstrates switching modes with Shift+Tab: Claude prepares a plan and waits for approval instead of carrying out the requested work. His instruction then was to restart Claude to receive the update. In the current interface, the shortcut cycles through modes; press it until Plan mode appears. The durable distinction is between a proposed action and an approved action.

Persistent context supplies the other half of the workflow. A repository-root CLAUDE.md carries project instructions; files in subfolders are pulled in on demand, and home-folder instructions can supply broader preferences. The talk also demonstrates reusable workflows as ordinary Markdown files in .claude/commands, which become available through the slash menu. These mechanisms separate information the agent should retain from instructions the user wants to invoke repeatedly.

For adding information to memory, the demonstrated version uses #: ask Claude to remember something, then choose the destination memory when prompted. Cherny closes the prepared talk by describing this memory interface as rough but functional. The team has a first version that works and wants feedback about where the interaction succeeds or fails. Persistent instructions introduce a new design problem for coding tools: users need to understand not just what the agent knows now, but where that knowledge will be stored for future work.

The closing question moves from an individual agent to several concurrent delegations: how should someone work when ten sessions are active, each running for roughly ten minutes? Those numbers describe the question’s scenario, not a measured capacity or speed. Cherny recognizes the pattern among power users: multiple terminal tabs, with sessions operating in separate codebase checkouts or Git worktrees.

GitHub Actions offers another way to launch parallel work. Cherny says that most of these use cases do not require coordination between the agents. When they do, his proposed mechanism is simple: ask them to write to a Markdown file. Separate workspaces let sessions proceed independently; a shared written artifact gives them a place to communicate when their tasks actually depend on one another.