The two instruction files I keep for Claude Code add up to 413 lines and just over 5,100 words. One lives in this repository and describes how sparkone.nl is put together. The other lives in my home directory and describes how I work. The project file has nineteen commits behind it. Every line in there was added because the model did something I did not want, or failed to do something I did. I have never removed a single one.
Boris Cherny, who built Claude Code, sat on a Y Combinator stage in late July and argued the opposite. When Opus 5 arrived, his team deleted more than eighty percent of Claude Code’s system prompt. Nothing was broken. The model simply no longer needed those instructions. His advice to the room: every six months, delete your CLAUDE.md, your skills and your hooks, and see what happens.
I have written before about telling the model less. That piece was about how much you cram into a single request. This one is about the instructions you wrote down permanently, and whether they are still true.
What ablation means here
Ablation is a research habit. You remove a component, then measure what changes. If nothing changes, the component was doing nothing.
Cherny treats it as a fixed round for every new model:
| Step | What you do | Where it goes wrong |
|---|---|---|
| 1. Delete | The whole system prompt, in one pass | You keep a quarter “just in case” and measure nothing |
| 2. Use | Run the real product on real work | You start guessing which instruction is missing |
| 3. Watch | Note where the model stumbles | One incident gets treated as a pattern |
| 4. Restore | Line by line, only on repeated failure | You paste the old prompt back because it feels faster |
Step three carries the method. A line only goes back in when the model trips over the same thing repeatedly, not once. Cherny’s reasoning is plain: the model reads that line at the start of every session, so it has to earn its place.
Claude Code ships an undocumented switch for this. Set the environment variable CLAUDE_CODE_SIMPLE=1 and every system prompt disappears, including the ones attached to tools. Anthropic uses it internally as an ablation instrument. The observation Cherny attached to it is the most interesting sentence in the interview: without those prompts the model is slightly more intelligent. The prompts are not there for intelligence. They are there so the product behaves the way a person expects a product to behave.
The numbers, and the gap underneath them
Three figures hold this story up, and they are not equally solid.
Eighty percent. That is the size of the cut in Claude Code’s system prompt for Opus 5. It is a statement by Anthropic about Anthropic, made in a stage interview. No ablation table was published alongside it, no before-and-after eval, no line count. Treat it as a direction, not as a measurement you can check.
30.2 percent on ARC-AGI-3. Opus 5 shipped on 24 July 2026 and posted that score in its High setting, measured by ARC Prize rather than by Anthropic. The previous record stood at 7.8 percent, so this is close to a fourfold jump on a benchmark built specifically to resist what models are already good at. The detail that matters as much: thirty percent also means seventy percent still fails.
Eleven days for Bun. The example Cherny reaches for on stage is the rewrite of the JavaScript runtime Bun from Zig to Rust. On stage it sounds like one prompt, one dynamic workflow, eleven days. The blog post by Jarred Sumner, who actually ran it, is more precise and considerably less magical: roughly fifty workflows running continuously, up to 64 Claude instances at once across separate worktrees, 6,502 commits, a test suite of more than 1.38 million assertions acting as a safety net, and around $165,000 in API cost. Above all, Sumner writes that he spent those eleven days reading agent output himself, catching bad patterns and steering the workflows as they ran.
That difference is not a footnote. On stage it becomes a prompt. In the account of the person who did it, it is eleven days of full-time supervision on top of a conformance suite. If you keep one version of this story, keep the second one.
Why this cuts against instinct
Cherny names the most common failure among experienced engineers: overspecifying. You describe not just the outcome but step one, two, three and four, in the order you would have done it yourself. That is exactly how you used to build software, and it is exactly what gets in a modern model’s way.
His replacement is shorter than you would like. Describe the task, describe the guardrails, describe how anyone can tell it is finished, then let it run. The skill that takes the place of prompting is verification: how does this thing check its own work. I wrote about that in verification is not your unit test, and Cherny is blunt that this is the part most people get wrong.
His own example is almost embarrassingly plain. He wanted to know how the Claude desktop app would feel if it were native, gave Claude access to a macOS runner and an empty repository, and asked it to rewrite the Electron app in Swift, run the Electron version in the virtual machine, screenshot it, compare pixel by pixel against the Swift build, and not stop until it was done. At the time of the interview that task had been running for over two weeks. There is no trick in that request. There is a measuring stick in it.
What I am actually doing
I am not emptying my instruction files in one go, and for a bilingual blog with content gates I do not think that advice holds as written. What I am doing in September:
- Splitting CLAUDE.md into two kinds of lines. Facts about this project (ports, paths, which gate blocks what) stay, because the model cannot infer them. Corrections to model behaviour, the “do not over-explain” and “no em dashes” kind, go on the chopping block.
- Removing that second category in one pass, then working for a week with a project file that carries no behavioural rules at all. Whatever the model gets structurally wrong gets written down. Whatever it gets right on its own never comes back.
- Treating skills separately. I have 48 of them in my home directory. Some are a frozen work process with scripts underneath, and those stay. Some are a long explanation of how to write, and that is precisely the kind of instruction a newer model no longer needs.
- Putting it in a routine rather than in my head. A twice-yearly reminder on 1 March and 1 September that says one thing: delete and measure. I have written about putting recurring work in loops before, and this is one I am pointing at myself.
What I am not touching is the content gates in this repository. Those are not prompt scaffolding, they are policy with tests underneath, and a smarter model is not an argument for lowering your own publishing bar.
The caveat
The advice to delete comes from the party on the other side of the table. “Remove your instructions and trust the model” is probably sound on the merits, and it also makes you more dependent on default behaviour you cannot inspect and that may shift with the next model version. What you write down is the only control you have that does not move on its own. Deleting is therefore not free, and it is no accident that the instruction you drop is replaced by trust in the model.
Responsibility lands on whoever did not build it. Bun ended up with more than a million lines of new Rust that nobody read line by line. Andrew Kelley, who created Zig, publicly called the result unreviewed slop, aiming most of his criticism at the working practice around it. His point survives regardless of how good the model is: if a hole turns up in that code three years from now, no human can explain why a given line reads the way it does. That weight moves to the maintainer, who is usually not the person who started the workflow.
Knowledge drains out that you do not get back. A CLAUDE.md is not only a prompt, it is also documentation for people. Every line was learned once, from something that went wrong. Delete it twice a year because the model already knows, and you end up with a team that holds the answer without the reason. So I never remove a line without parking the reason somewhere else, even when the model no longer reads it.
Frequently asked questions
Do I really have to delete everything at once?
No, and the method only works if you separate two kinds of lines. Facts the model cannot infer (ports, directories, which gate blocks what) have nothing to do with model intelligence and should stay. Behavioural corrections belong on the chopping block, because they were written for a model that no longer exists.
What exactly is CLAUDE_CODE_SIMPLE=1?
An undocumented environment variable that switches off every system prompt, including the ones attached to tools. Anthropic uses it internally to measure whether a prompt still contributes anything. Undocumented also means there is no promise it will exist tomorrow, so do not build a working process on top of it.
How do I know an instruction is still needed?
By taking it out and running the model on real work, not by reasoning about it. One miss proves nothing; a pattern across several sessions does. Put a line back only when you can name the exact behaviour it repairs.
Does this apply to evals and tests too?
Partly. Cherny says evals outlive the harness, though not by much: one lives for roughly one to three model generations before it saturates and gets thrown away. Tests that enforce policy, such as the publishing gates in this repository, sit outside this argument entirely. They are not about model behaviour, they are about what I do and do not publish.
Sources
- Y Combinator, video Boris Cherny: We Cut 80% of Claude Code’s Prompt, 27 July 2026 (transcript read in full)
- Anthropic, Introducing Claude Opus 5, 24 July 2026
- ARC Prize, Claude Opus 5 results on ARC-AGI, July 2026
- Jarred Sumner, Rewriting Bun in Rust, 8 July 2026
- Simon Willison, Rewriting Bun in Rust, 8 July 2026
- Andrew Kelley, My Thoughts on the Bun Rust Rewrite, July 2026
- The Register, Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’, 14 July 2026
Checked on 11 August 2026. Cherny’s statements come from the video transcript itself, not from a third-party summary. The eighty percent figure is an Anthropic claim without published backing; I found no ablation data to verify it against. The Bun numbers come from Jarred Sumner’s blog post and differ from how the story sounded on stage: one prompt there, roughly fifty workflows and eleven days of supervision in the post. I follow the post. I have not tested CLAUDE_CODE_SIMPLE=1 myself and it does not appear in the official documentation.