Boris Cherny on Opus 5, Deleting the System Prompt, and Giving Models Harder Problems
Boris Cherny, who created Claude Code at Anthropic, spoke at YC’s Startup School 2026 the day after Opus 5 shipped. His argument is that every new model makes part of the harness obsolete: the team deleted 80% of Claude Code’s system prompt for Opus 5, and he tells users of Claude Code to delete their own CLAUDE.md files and skills every six months and add back only what the model shows it still needs.
The interviewer is labelled ‘Host’ in YC’s transcript and is never named aloud; YC’s page names her as Diana Hu. The transcript carries no timestamps, so times below are YC’s chapter marks.
Key ideas
- Delete what the new model no longer needs. For Opus 5 the team deleted 80% of Claude Code’s system prompt (chapter at 3:21), because much of it corrected behaviour the older models got wrong and the new one gets right unprompted. Cherny adds that the model is ‘a little bit more intelligent without these prompts’, though a product still wants some of them.
- Rebuild by ablation, not by guesswork. Ablation, a research term, means deleting a component and restoring it piece by piece to measure what each piece contributed. Cherny applies it to prompts and tools: delete the system prompt, use the product, and restore an instruction only when the model ‘repeatedly stumble[s] on the same thing’, since the model reads every instruction on every run.
- The same advice for ordinary users. Asked whether everyone should be willing to ‘press delete’, Cherny answers: ‘for people that aren’t building agentic products but you’re using Claude Code, every six months delete your Claude.md. Delete your skills’ (chapter at 6:37). He does not mention hooks.
- Give the model harder problems than you think it can solve. Over-specified, step-by-step instructions are the common mistake; describe the task, the guardrails and the exit criteria instead. His example: a single prompt, run as a dynamic workflow for eleven days with human steering, rewrote the Bun JavaScript runtime from Zig to Rust, and that version is now in production under Claude Code.
- Evals outlive the harness, but not by much. An eval (a fixed test set used to score a model) lasts perhaps one to three model generations before it saturates and has to be replaced. The durable skill is an empirical habit: try the task, watch where the model struggles, adjust.
Content
What Opus 5 changed
The host opened with Opus 5’s score on ARC-AGI-3, which she put at 30% against a previous best in the low single digits or low teens. Cherny picked out two capabilities instead. The first is endurance: combined with Claude Code’s auto mode, he said, the model ‘can go for days, weeks, months at a time’ without extra scaffolding. The second is resistance to prompt injection — an attack in which text the model reads, such as a web page, smuggles in instructions of its own. Cherny described three layers: an aligned model, a prompt-injection classifier run on all traffic that watches for the internal activations associated with injection (built on mechanistic interpretability work — the transcript’s ‘Crystal’s’ is probably ‘Chris’s’, meaning Chris Olah [?]), and the auto mode classifier. With all three, he said, ‘we just cannot demonstrate prompt injection anymore.’ That is the vendor’s own claim about its own defences; Prompt Injection records the wider view that the attack cannot be fully solved.
The harness is always being deleted
Claude Code, Cherny said, changes with every model: the team deletes and rewrites parts of the system prompt, the tool set and the tool prompts, because ‘something that you did for one model maybe three months ago, it just might not translate at all to the next model.’ Two ways to try this yourself: set a custom system prompt with a command-line flag, or use an undocumented ‘simple mode’, set by an environment variable, that strips all system prompts including the tools’ own, which the team uses as an ablation baseline. Most of the harness code that survives, he said, deals with safety, permissions, static analysis and interface.
The host summarised the approach as ‘press delete every six months for everything’. Cherny corrected the scale — ‘we don’t delete the entire code base, but we do delete a lot’ — and then extended the advice from builders of agentic products to anyone using Claude Code, with the instruction about CLAUDE.md files and skills quoted above. See Harness Ablation.
Rebuilding: delete, use, add back
The procedure he gave has three steps. Delete. Use the product, or use Claude Code on your own code base, and watch where it fails and where it does well. Only when it fails at the same thing more than once, add an instruction back — ‘you don’t wanna do it too early.’ He contrasted this with conventional engineering, where a system is designed up front and re-architecture takes months or years. A model, he said, is closer to ‘a living creature’: each generation has a slightly different personality, and the harness has to be adjusted to it by experiment.
Product overhang and hobbling
Cherny uses two research terms for the gap between what a model can do and what products let it do. Product overhang is capability the current model already has that no product yet draws out. Hobbling is the product getting in the way. Claude Code began as an unhobbling exercise: when Sonnet 3.5 was the best coding model, tools offered autocomplete and read-only chat, and Claude Code gave the model the simplest possible harness — a terminal — so that it could write whole files and features. A lighter example from inside Anthropic: someone found that Opus 5, given the OpenCV image library, can draw portraits, animals and landscapes, which nobody trained it to do.
Thousands of agents
Asked how heavy users run thousands of agents, Cherny named two mechanisms. Dynamic workflows — invoked by asking Claude Code to ‘use a workflow’ — let the model start and orchestrate many agents in stages inside a sandbox, fanning out, verifying and fanning out again; he called it ‘an algebra for agents’ and framed it as a new way to spend test-time compute, the compute a model uses while answering rather than while training. Loops and routines run a repetitive task on a schedule, locally or in the cloud. The Claude Code team runs twenty or thirty routines a day across its own apps: deleting dead code, removing experiments already shipped to everyone, writing missing tests, deleting useless ones, and an ‘abstraction police’ that finds near-duplicate abstractions and unifies them.
Coding is (almost) solved
Cherny repeated his claim that coding is solved, with a caveat: solved ‘for the kind of coding that I do.’ Deep systems code, distributed systems and pixel-level interface verification still defeat the model. What distinguishes the best users, he said, is a willingness to forget their priors: ‘it’s not a theoretical science, it’s become an empirical science.’ For students, his own path was practical — he learned to program on a TI-83 calculator in middle school, to solve a problem he had.
A note on the transcript
YC’s transcript is imperfect. One of the host’s questions appears twice, the answer to the chapter ‘Prompt Engineering Is Changing’ is missing, and speech recognition garbles names (‘Opus V’ for Opus 5, ‘quad’ for Claude). The account above uses only what the transcript contains.
Related
- Boris Cherny — speaker
- Boris Cherny on Claude Code — his earlier, longer interview on Lenny’s Podcast (February 2026)
- Claude Code — the product
- Harness Ablation — the delete-and-restore method this talk describes
- Bitter Lesson — the older argument that scaffolding gains are wiped out by the next model
- Evals — why an eval set lasts only a few model generations
- Prompt Injection — the attack Cherny says Opus 5 resists
- Andrej Karpathy on Software 3.0, LLMs as Operating Systems, and Partial Autonomy — an earlier YC Startup School talk on building for fallible models