Coding models are improving faster than product teams can settle on the right user experience.
2
Claude Code stays close to the terminal because Anthropic does not yet know what the best interface for coding agents should be.
3
Coding agents work better when they can inspect context, follow a plan, and check their output against tests or another visible target.
Summary
Boris Cherny describes coding as a sequence of rising abstractions, from punch cards and assembly to modern languages, editors, autocomplete, and natural-language programming. He argues that model capability is improving exponentially, while product design is struggling to keep up. Claude Code therefore starts with a simple terminal interface and gives the model access to existing tools, repositories, terminals, GitHub, and custom integrations. Cherny says this low-level approach is deliberate because the team does not yet know the right UX for agentic coding. He shares practical workflows: use Claude Code for codebase questions, have it explore and plan before editing, apply test-driven development, give it a way to inspect its output, and store project instructions in CLAUDE.md. He also describes running several agents in parallel through terminal sessions, worktrees, or GitHub Actions.
Coding interfaces have changed through successive jumps in abstraction
Cherny traces programming from physical switchboards and punch cards to assembly, COBOL, typed languages, C++, JavaScript, Java, Python, and today's similar-looking mainstream languages. The user experience changed alongside the languages. Text editors replaced physical card workflows, IDEs added richer interaction, and Smalltalk-80 introduced a graphical programming environment with live reload. Visual Basic brought graphical editing to a wider audience, while Eclipse made static-analysis typeahead common. Copilot added single-line and multi-line completion. Devin then made natural-language instructions into code a mainstream product idea.
The model is improving faster than coding products can settle
Cherny's central claim is that the model is moving exponentially and getting better at coding very quickly, while products are struggling to keep up. He says the team is still building what amounts to the bare minimum because there are many possible products for models this capable. He frames Claude Code as deliberately unopinionated. Anthropic does not know what the right product should look like, so the team wants engineers to experience the model directly and discover useful workflows rather than forcing everyone into a fixed interface.
Claude Code starts with a terminal and keeps access to existing workflows
Claude Code gives users low-level access to the model through a terminal without adding much interface scaffolding. It works in iTerm2, WSL, SSH, tmux sessions, VS Code terminals, and Cursor terminals. In an IDE, it can present larger diffs and ingest diagnostics, but Cherny says the integration is less polished than products such as Cursor or Windsurf by design. Claude Code can also run on GitHub through an installed GitHub app, using the user's compute while keeping data there. The SDK lets teams build their own interface.
A coding agent can become useful by learning the tools an engineer already has
Cherny describes Claude Code as a Unix-style utility that can accept piped input and produce piped output. He uses it for incident triage by sending GCP logs into Claude Code and processing the result with jq. He says engineers can teach the agent to use command-line tools by giving it a tool such as cla run-help and putting what it learns into CLAUDE.md. Bash tools and MCP tools can be exposed directly. This avoids building a separate IDE extension for every tool, while MCP remains available for grouped tools and features such as streaming.
Exploration and planning should happen before code changes
Cherny recommends asking Claude Code to explore the codebase and make a plan before it writes code, then asking for approval. Extended thinking works better after the agent has pulled relevant material into context with tools. He says thinking before the model has useful context can waste tokens. Claude Code's plan mode packages this workflow: pressing Shift-Tab switches modes, and the agent produces a plan without carrying out the requested change. It then waits for approval. Cherny presents this as a practical way to control an agent without hiding its work behind a complex interface.
Tests and visible feedback give the agent a target for iteration
Cherny says test-driven development works better with coding agents because the model, rather than the engineer, can write the tests and implement against them. His suggested sequence is to describe and write the tests first, make clear that they should not pass yet, commit them, then write the code and commit again. The same principle applies to integration tests, screenshots from an iOS simulator or Puppeteer, and other ways to inspect output. He describes teaching a model to use a 3D printer and a camera so it could see the result. The first attempt may be acceptable, but later iterations improve when the agent can inspect its work.
Project instructions and memory give the agent more context
Cherny recommends putting a CLAUDE.md file in the repository root, with additional files in subfolders when their context should be loaded on demand. Markdown files in command folders can become reusable slash commands. Engineers can type a pound sign to ask Claude Code to remember something and choose which memory file should receive it. Cherny is open about this feature being an early attempt to work out the UX of memory for coding agents. He calls the first version rough, while saying that it is already usable enough to support further iteration and feedback.
Parallel agents can work independently across terminals or GitHub Actions
When asked how to handle many agents running at once, Cherny says power users often open several Claude Code sessions in parallel. They may use different terminal tabs, separate checkouts, or multiple worktrees of the same codebase. GitHub Actions makes it easier to spawn many jobs. In most cases, the agents do not need to coordinate directly. When coordination is needed, Cherny suggests having them write information to a Markdown file. This keeps communication simple and avoids requiring a separate coordination system for every parallel coding workflow.
"The model is moving really fast. It's on exponential. It's getting better at coding very, very quickly, and the product is kind of struggling to keep up."00:47
Who should watch
You are deciding whether a terminal-first coding agent fits your team's existing tools and repositories.
You want practical ways to make a coding agent inspect context, plan changes, and verify its output before you trust the result.
You are running several coding agents at once and need simple patterns for parallel work and handoffs.
