Two weeks ago, when Anthropic released Claude Opus 5, it threw out a counterintuitive data point: more than 80% of Claude Code’s system prompt was deleted, and internal coding evaluations showed no meaningful decline.
That sounds like a minor product-optimization note. It is not. Boris Cherny, the creator of Claude Code, told the full story in a recent Y Combinator interview, and tracking data from Claude Code team member Thariq Shihipar plus third-party engineers confirms what it exposes: a fundamental inversion of how AI products should be built — relevant to anyone building on agents, whether they run Claude, GPT, or open models.
What Was in the Deleted 80%?
The cuts were surgical. When the team reviewed Claude Code’s internal usage records, they found the same request carrying conflicting requirements — the system prompt said “don’t add comments,” a Skill said “document appropriately,” and the user asked mid-task to “explain the complex logic.” Claude could tell what the user wanted, but first it had to arbitrate contradictory instructions, burning tokens and time.
The deletions followed six directions:
-
Let the model judge. Old prompts hard-coded behavior: no comments by default, no multi-line docstrings, don’t create planning docs unprompted. The new version keeps one line: match the style of the surrounding code. Fewer requirements produced better judgment.
-
Design interfaces, don’t provide examples. Stuffing tool-call examples into prompts used to be doctrine — until Anthropic noticed models treating examples as the whole answer space. Write fewer examples, design better interfaces: the Todo tool just declares its states as pending / in_progress / completed, and Claude infers the usage.
-
Load on demand. Lengthy review, verification, and tool instructions used to live permanently in the system prompt, so a one-word copy edit still dragged the whole context along. Now they ship as Skills, and tool definitions load on demand through ToolSearch.
-
Say each thing once. Older models forgot, so the same rule appeared in the prompt, the tool description, and the examples. Newer models understand long context well enough that repetition creates conflicts instead of reinforcement — each rule gets exactly one home.
-
Let the model remember automatically. Project notes and user preferences used to pile into CLAUDE.md. Automatic memory handles that now; CLAUDE.md keeps only a repo introduction and genuinely counterintuitive gotchas.
-
Give plain specifications. New models don’t need humans to pre-digest requirements into “AI-friendly” form. HTML prototypes, test cases, existing code, and grading rubrics all work as references directly.
In one sentence: what Anthropic deleted was not context — it was judgment that humans had pre-performed on behalf of older, weaker models.
The Twist: Opus 5’s Prompt Is 72% Longer Than Opus 4.8’s
Here comes the counterpoint. Qoder engineer Chen Cheng scraped the requests Claude Code actually sends: Opus 4.7’s system prompt ran about 15,225 characters, 4.8 cut it to 4,467 — and Opus 5 grew back to 7,694, 72% more than 4.8.
Not a contradiction. The reason is more interesting than one would be. Old models’ bottleneck was “can it finish the task,” so rules supported capability. Upgraded capability surfaced new problems, and the added 70% manages exactly two:
Delivering work — Opus 5 is so autonomous that “fix this error” might come back with refactored neighbors, added tests, and updated docs. Sounds great, until the user only wanted the bug fix. The new rules: don’t silently expand the task scope because you spotted a better plan; when something is blocked, finish what’s doable, then state plainly what’s missing.
Corrections — Opus 5 likes narrating its own corrections (“I misspoke earlier, actually…”). In long tasks, most corrections change nothing about the outcome while inflating output. The new rule: explain only mistakes that genuinely affect code, conclusions, or decisions; silently fix the trivial ones; stop grading your own work in public.
One section stops Claude from doing too much; the other stops it from saying too much. That is the real signal: the nature of the problem changes as capability rises. Rules you carefully designed for one capability level become not just redundant but harmful at the next.
Ablation: the Most Undervalued Method in Agent Development
The most valuable idea in Cherny’s interview has a name: ablation. The procedure is trivially simple — whenever a new model ships, delete the entire system prompt, add lines back one at a time, and observe what each actually does.
Don’t guess what the model needs. Run it, watch where it fails, and only then add the instruction for that failure. In Cherny’s words:
Don’t start by guessing which instructions the model needs — your guess will often be wrong. What actually works is to just start using the model, watch which tasks it excels at and where it fails, and only when it keeps failing in the same place consider adding the relevant instruction back.
He even offers a runnable experiment:
# Run Claude Code with all system prompts removed
CLAUDE_CODE_SIMPLE=1 claude“Interestingly, the model is actually slightly smarter without those prompts.” That runs opposite to how most teams build agents: model makes one mistake, team adds one rule, and a few months later the system prompt has swollen to tens of thousands of characters. Anthropic’s practice is the inverse — every model generation, reset everything to zero, then rebuild on demand. And Cherny extends it beyond agent products: even if you merely use Claude Code, every six months delete your CLAUDE.md, your Skills, your hooks, and see what changes. A six-month ablation cadence — less a tip than a paradigm switch in methodology.
Product Surplus and Fettering
Two more concepts from the interview deserve their own headings.
Product surplus: capability current models already have that no product has released yet. Claude Code is the textbook case — Sonnet 3.5 could already generate complete functions, even whole files, in one shot, but products only offered single-line completion and read-only code viewing. Claude Code removed the excess scaffolding, gave the model the simplest possible harness, and a world-class coding agent appeared.
Fettering: the opposite failure — products that don’t just fail to release a model’s capability but actively shackle it. You think you’re “designing a product”; you’re fitting the model for chains. Cherny’s test: hand the model tasks slightly beyond what you believe it can do. Describe the work at a higher level — what you want accomplished, the constraints, what counts as done — and let go.
One quote deserves rereading by anyone building agent products:
The way to understand a model is closer to understanding a living thing — an organic system. Each generation behaves differently; it even has something like a different personality. You have to spend time getting to know it, then adjust the harness to fit.
Not architecture design. Husbandry.
The Bitter Lesson, Replayed in a System Prompt
In 2019, reinforcement-learning pioneer Richard Sutton published “The Bitter Lesson.” Its core claim, proven across seventy years of AI history: humans cannot resist pouring their own experience into the machine — chess openings, phoneme structures, hand-designed vision features. The rules work immediately and feel like craftsmanship. Then compute scales, the rules collapse, and methods that exploit search and learning win. The lesson is bitter because what gets discarded is never the lazy work — it’s the work researchers were proudest of and invested in most.
Claude Code’s deleted prompts are the lesson in miniature. Those prompts made Claude Code the agent it was — and as the model evolved, they started dragging the product down, because every rule was a concession to a defect that no longer exists. The model fixed the defect; the rule became the burden. Every agent product faces this: today’s core competence can be tomorrow’s technical debt.
The resolution is not to stop writing rules — it is to treat every rule as a temporary experimental artifact, written with the expectation of deletion. Your system prompt, your tool definitions, your Skills: their lifecycle may be exactly one model generation long.
Four Actions for Agent Builders
1. Put ablation on a schedule
Every new model release — call it every 3–6 months — run a full ablation on your system prompt. Delete everything, add back line by line, record each line’s effect. Same for tools, Skills, and hooks.
2. Single ownership, zero repetition
Each rule lives in exactly one place. If a rule must be repeated in three places to work, the problem isn’t the model — it’s you taming an obsolete one. Clean those out during ablation.
3. Separate legacy baggage from current problems
Most “prevent the model from doing X” rules were written against model versions that no longer exist. For each rule, ask: which version was this written for, and does that version still run anywhere?
4. Look past prompt engineering
Cherny’s closing point, made repeatedly: what matters is not “the right prompt” but assign the model challenging tasks, give it a way to verify results, observe where it fails, and fix only that failure point. The one trick that beats all of this — the one everyone is looking for — does not exist.
The real takeaway is not a product update. It’s a mirror. Model capability compounds exponentially, and every clever design you built for the last version may be redundant by the next. What survives model turnover is not a brilliantly engineered system prompt — it’s an engineering habit of zeroing out and rebuilding.
Delete the rules you worked so hard to write. That is the bitter lesson, and it is also the only solution.
