Stronger Models Require Smaller Agent Harnesses

Boris Cherny describes Opus 5 as changing the design assumptions behind agent products. He says it can sustain work for unusually long periods—especially with automode—without requiring extensive scaffolding such as goal-setting commands or loop instructions. More consequentially, he says, it reaches a new level of resistance to prompt injection.

Cherny frames prompt injection as a central agent-design problem: an agent that reads instructions from the internet could encounter malicious text telling it to take actions against a user’s interests, including deleting material from the user’s computer. A year earlier, he says, a model might have followed such an instruction. Anthropic has been unable to demonstrate that outcome with the combined system Cherny describes: an aligned model, a prompt-injection classifier, and an automode classifier.

He characterizes the aligned model as the result of roughly three years of alignment research. The prompt-injection classifier, run across all traffic, draws on mechanistic-interpretability work associated with Chris Olah, Cherny says. It identifies neurons that activate during prompt injection even when the model does not explicitly report the attack. The automode classifier provides the third layer.

For Cherny, that is not only a safety improvement. It changes what a harness can allow an agent to do, and therefore changes agent and product design. The same underlying shift shapes his approach to prompts and tools: constraints that once compensated for model limitations may now get in the way.

Boris Cherny treats Claude Code not as a fixed software system but as a harness that must be re-learned for every model generation. Prompts, tools, and orchestration do not necessarily accumulate into a permanent architecture. Each new model changes which parts help, which preserve old workarounds, and which now reduce performance.

That is why Claude Code removed more than 80% of its system prompt for Opus 5. Much of the prior prompt, Cherny says, was correcting behaviors that an earlier model did not perform reliably. Opus 5 now does much of that work without the instructions. Users can test the premise by overriding Claude Code’s system prompt or by setting an undocumented Claude Code simple=1 environment variable, which removes system prompts, including prompts associated with tools.

Cherny says Anthropic has found the model can be “a little bit more intelligent” without these prompts. The prompts retained in the product, he says, help people use it and help guide the product and model toward behavior users expect.

The deletion principle extends beyond prompts. Cherny says the team regularly removes tools and harness code. Much of Claude Code’s remaining implementation, he says, concerns safety, permissions, static analysis, and interface code; the team has already unshipped much of the rest.

The engineering method is ablation: remove the system prompt entirely, then restore it line by line to establish what each instruction contributes. The team applies the same test to tools and harness features.

For users of Claude Code, Cherny recommends periodically deleting accumulated CLAUDE.md files, skills, and hooks, then observing what the current model does. Rebuilding begins with use rather than speculation: run the product, identify repeated failures—perhaps a misunderstanding of an architecture or a recurring missed constraint—and add an instruction only once that pattern is clear. Otherwise, the model reads an unnecessary instruction every time it is invoked.

Evals outlive a particular harness, he says, but not by much. An evaluation may survive one, two, or three model generations before improved models saturate it and it no longer distinguishes performance. The next eval set should then come from newly observed limitations rather than an inherited suite treated as permanent.

Boris Cherny uses two related terms for the opportunity he sees in AI products: product overhang and hobbling. Product overhang is the gap between what a current model can do and the products that let it demonstrate that ability. Hobbling is what happens when a product constrains the model or fails to elicit behavior it can already produce.

His account of Claude Code’s origins is an example. At the time, Sonnet 3.5 was, in Cherny’s view, Anthropic’s first great coding model. Yet coding products were largely limited to single-line or multiline autocomplete, or read-only chat about a codebase. They did not give the model a route to write whole functions or files. Claude Code’s initial hypothesis was that a simpler harness could let the model work at that larger unit of output.

Cherny argues that the model could do more than the products of the time enabled it to do; the missing product was an environment that exposed that ability. He believes there is now much more of this overhang than startups have captured: capabilities involving tools, programming languages, problem types, and work styles that have not yet become commercially useful systems.

A practical implication is to give a model a task somewhat harder than the builder initially believes it can handle. Cherny sees excessive specificity as a common failure mode. Users prescribe every step—one, then two, then three—and try to make the model work exactly as they would. For current models, he recommends specifying the task, guardrails, and exit criteria, then allowing latitude in how the work is completed.

Cherny’s example is Bun, the JavaScript runtime used by Claude Code. Bun was written in Zig, a low-level systems language that requires manual memory management. The Bun team had used Claude to fuzz the codebase and trigger memory leaks. Then, with Bun and Node.js test suites available to check correctness, a team member gave the model a more radical task: rewrite the Bun codebase from Zig to Rust.

The work ran through a dynamic workflow, with steering rather than as a wholly unattended one-shot prompt. It took 11 days, and Cherny says the resulting Rust version is now in production for Claude Code. In his estimate, equivalent human engineering work would previously have required more than a year.

The lesson is not simply that language migrations can be automated. A difficult problem with a strong way to check the result may become tractable when a new model crosses a threshold that its predecessor did not. Cherny advises builders to keep testing the latest model against important engineering, product, and business problems, including ones older models failed to solve.

He also points to capabilities found through experimentation without an immediate commercial purpose. Internally, someone discovered that Opus 5 could draw portraits, animals, and landscapes when given OpenCV, despite not having been trained explicitly as an image-drawing system. To Cherny, that is another elicitation gap: a capability may already exist while the task framing or interface needed to bring it out has not yet been found.

Boris Cherny regards labels such as “prompt engineer” and “context engineer” as passing descriptions of the work. The more important skill, he says, is choosing a hard task and making it possible for Claude to verify its work along the way.

That verification might be a test suite, a visual comparison, static or dynamic analysis, or access to missing context through an MCP. The builder’s responsibility is not to dictate each implementation step. It is to create feedback that lets the model distinguish progress from a dead end.

Cherny illustrates the approach with an ongoing attempt to recreate Anthropic’s Electron-based Claude desktop application as a native Swift app. He connected Claude Tag, Claude running in Slack, to a macOS runner through GitHub and gave it access to an empty codebase for the Swift version. His instruction was short: rewrite the Electron application in Swift; run both versions in the Mac virtual machine; take screenshots; compare them pixel by pixel; and do not stop until the work was complete.

At the time he described it, the task had been running for more than two weeks. Claude had created an internal Slack channel and was posting screenshots of its progress every few minutes. For Cherny, the duration did not demonstrate a need for elaborate prompting machinery. It demonstrated the effect of pairing a demanding objective with a concrete verification loop.

This is why he dismisses the search for a single prompting trick. The workflow resembles managing a capable coworker: inspect the output, locate the obstacle, improve instructions where necessary, add a skill if the work requires one, or provide missing context. Long-time engineers can find that difficult, he says, because conventional systems rewarded detailed upfront specification. Trying to force an exact human-designed procedure can become a constraint on a more capable model.

Boris Cherny estimates that the desktop-app conversion may have spawned thousands or tens of thousands of agents, though he did not know the exact count. Claude Code’s dynamic workflows are designed for that type of complex, one-off work. A user can invoke one simply by asking Claude to use a workflow.

Dynamic workflows use Bun as a sandbox and virtual-machine-like environment in which Claude can start and orchestrate agents. Rather than relying on a fixed set of parallel workers, the system can send agents through a first pass, use subsequent agents to verify or summarize the result, and fan out again based on what earlier stages found. Cherny describes the functional-programming-inspired design as an “algebra for agents”: operations for sequential and parallel execution, with tools Claude can compose inside the sandbox.

He frames this as a new form of test-time computeCompute used while a model is generating and working on a task rather than during training.. Historically, Cherny says, scaling discussions focused on neural-network size, training data, and training FLOPs; more recently, test-time compute has largely meant the number of tokens generated during a task. Dynamic workflows provide a way to organize substantially more of that work.

Loops and routines address a different operating pattern. A loop is a locally running, cron-like job for Claude; a routine is its cloud-based counterpart, able to continue after a user closes a laptop. Instead of breaking a shared-context project into stages, they repeat scheduled tasks.

Cherny says Anthropic uses routines to maintain code across its CLI, iOS, Android, and desktop applications. One daily routine identifies dead code through static and dynamic analysis and opens pull requests to remove it. Another removes experiments that have reached 100% rollout. Others add test coverage, delete tests judged unnecessary, or identify nearly duplicated abstractions and unify them.

The “abstraction police” routine looks for implementations that are not identical but appear to represent the same abstraction, then consolidates them. Cherny says Anthropic runs roughly 20 to 30 routines each day. The system is not fully autonomous, he says, but it is moving toward automated application maintenance. Hundreds or sometimes thousands of agents can take on work that once required dozens or hundreds of engineers, leaving engineers more time for new product work and conversations with users.

Boris Cherny qualifies the claim that “coding is solved.” It is solved for the kind of coding he does, he says, and is getting there for more kinds of code, but not for every software domain. He names deep systems codebases, distributed systems, and exacting visual verification as areas where Claude still struggles. Even after what he calls a major Opus 5 improvement in vision and computer use, a UI discrepancy of a single pixel can remain difficult.

The broader direction, in Cherny’s account, is toward agent-written code across an expanding range of work. In that environment, strong builders distinguish themselves through empirical judgment: selecting meaningful problems, testing whether a model can solve them, supplying useful feedback mechanisms, and changing the environment based on observed failures.

That is also his answer to what computer-science students should still learn directly. Cherny learned programming practically, first using BASIC on a TI-83 calculator in middle school and later learning assembly language when he wanted to solve harder mathematical problems. Technical learning, in his telling, was attached to a concrete purpose.

Students should still learn computer science, he says, but pair it with the skills that make engineering useful: building products and startups, developing design and business judgment, doing data science, and talking to users. As agents take on more implementation work, those abilities help determine which problems matter, what a successful result looks like, and whether anyone wants the thing that gets built.