Understand what Anthropic deleted
Boris Cherny created Claude Code at Anthropic. During a talk at Y Combinator — recorded one day after the Opus 5 launch — he shared something that sounds strange to people who carefully manage their own configuration: the harness of Claude Code is never ready. And with Opus 5, the team removed more than 80% of the system prompt.
🆕 New here? Three words before you continue
- Harness: the “harness” around the model—the program that decides which tools it has, how it calls them, and what it reads before responding. Claude Code is a harness; its configuration is the harness that you wrote.
- System prompt: the fixed text the product sends to the model before of your question, on every run. Your
CLAUDE.mdis your personal system prompt. - Ablation: search term—you remove a way to measure its impact. This is the method that gives this course its name.
The reason is simple and uncomfortable: every model is different. An instruction written for the model from three months ago may have no effect at all on the next one. That’s why, with every release, the team changes four things.
Rewrite the system prompt
This isn’t fine-tuning: it’s a major rewrite with every model release.
They change the toolset
What the model can do changes: tools are added, tools are removed.
Rewrite each tool’s prompt
Every tool has its own little instruction text—and it gets old just the same.
They discontinue tools and remove parts of the harness
The entire codebase goes. Nobody treats the harness as an asset — they treat it as scaffolding.
💡 The question that opens the course
If whoever builds the product rewrites everything with each model, so why would your configuration — written over months, stacked up line by line, never reviewed — still be valid? It's not that it's wrong. It's that it was written for a model that no longer exists.
See why an instruction is a dated fix
Boris was explicit about what was cut: much of the old prompt existed only to correct behaviors the model should know how to perform on its own—but didn’t. “Always read the file before editing.” “Don’t stop halfway through the task.” “Check that the test passed.” Each of these lines was written because, one day, a model failed at that. Opus 5 does it on its own. So those lines became dead weight.
What to look at: the line doesn’t change in any of the three panels—the text is exactly the same as on day 1. What changes is the world around it. Notice the labels at the bottom: useful → inert → pure cost. No event in your editor marks this transition; it happens externally, when a model launches, without telling anyone. That’s why dead weight is found only when you deliberately look for it.
The change that prompted the cut wasn’t cosmetic. It’s worth looking at the numbers because they explain why instructions like “don’t give up, keep going” no longer made sense.
📊 What changed in Opus 5, according to the talk
- 30% on Arc AGI 3. O Arc AGI is an abstract reasoning test, designed to be hard to memorize. The best previous results ranged from single digits to around 10%.
- Runs for days, weeks, or months. Combined with automatic mode, the model can sustain a long task without stopping halfway through.
- You no longer need scaffolding to continue. Scaffolding is scaffolding: those little nudges like "continue," "don't stop," "now do the next step." The model understands on its own that the task needs to be completed.
✓ An instruction that still fixes something
- ✓"The production database is
db-prod-2; never run a migration on it.” - ✓"Deploys in this project are only via git push — the cloud dashboard is off-limits."
- ✓"The source of truth for prices is
/data/precos.json, not the README."
✗ Fix the model no longer needs
- ✗"Read the entire file before editing."
- ✗"Don't make up function names; check that they exist."
- ✗"Continue until you finish; don't stop halfway."
Learn what survived the cut
Cutting 80% isn’t the same as cutting everything. What remained in Claude Code after all the removals falls into almost entirely four categories: security, permissions, static analysis and a set of code from interface. Look at the list again and look for the pattern. It’s all the things the model there’s no way to infer it on your own.
What to look at: the proportion between the two bands at the top—the huge, hatched one is what was removed; the small, lit-up one is what remained. And especially the four blocks below: none of them teaches the model to reason. They all say facts about the world that it can’t figure out by deduction: what is prohibited, who authorizes it, which tool to use to check, and how the output should appear to the person. Use these four as a filter when you find yourself asking, "can I cut this?"
🎯 What you never cut on reflex
Translating Anthropic’s criterion to your config, here’s the list of what stays even in an aggressive audit— because no model, no matter how capable, can guess this:
- •Project identity — what it is, who it's for, and what constraints apply.
- •Paths and sources of truth — where the correct data lives when there are two candidates.
- •Branding — name, tone, color, what you never write.
- •Security and compliance — what must not be touched, who authorizes it, what must not leave the environment.
- •Interface contracts — formats consumed by another person or system.
- •Integrations — which service, which account, which key, which endpoint.
- •Internal conventions — your team’s agreements that aren’t documented anywhere in the code.
💡 The one-question test
For any line, ask: “Would a competent professional, with no context about my world, figure this out on their own by looking at the repository?” If the answer is yes, the line is a candidate for removal. If it’s no, it’s context—and context stays. The entire course is a disciplined way to ask that question without fooling yourself.
Calculate the cost of a zombie line
The most common objection is: “Sure, it’s obsolete, but it doesn’t get in the way—leave it there.” It does get in the way. A zombie line charges you in four different currencies at once, and you don’t see three of them on your statement. First: a vocabulary clarification. Context is everything the model reads before responding—your config, open files, and conversation history. It's finite and contested.
✗ What the zombie line demands
- ✗Context burned on EVERY run — even in the ~90% of tasks that have nothing to do with the rule.
- ✗Reduced autonomy — the rule closes off better paths the model would have chosen.
- ✗Inconsistent behavior — when a rule conflicts with another, the model chooses one and you don't know which.
- ✗Institutional fear — nobody deletes it because nobody remembers what it was protecting anymore.
✓ What you gain by cutting
- ✓Free context for what matters in that specific task.
- ✓Best permitted route — the model handles it its own way, which is sometimes better than yours.
- ✓Predictable behavior — fewer rules, less chance of silent contradiction.
- ✓Auditable config — you can say why each remaining line survived.
Notice the detail that makes the cost compound rather than grow linearly: the rule is read in 100% of runs, but it applies to only a small fraction of them. A deploy instruction gets reread when you ask to rename a variable, when you ask for a log summary, when you ask for a test. It never goes quiet—it just becomes invisible.
💡 The rough calculation that’s enough
One CLAUDE.md of 300 lines gets included in full with every request you make.
If 200 of those lines apply only to rare situations, you’re paying a 200-line tax on every
“rename this function” request. The painful cost isn’t money—it’s attention: what matters for that task
competes for space with what doesn’t.
⚠️ Warning: the rule nobody dares to delete
This is the final stage of sediment buildup. The line has been there so long it's become superstition: "I think this prevents that weird bug from ages ago." No one knows whether the bug still exists, no one knows whether the line fixes it, and no one wants to be responsible for finding out. Every rule you can’t explain has already failed the test. Don't delete on impulse—mark it for testing. That's exactly what the method in Module 1.2 is for.
Recognize the 6 symptoms of sediment
Sediment is what settles at the bottom over time, without anyone deciding to put it there. Configuration accumulates sediment the same way. You won’t audit anything yet — that’s Track 2. Here, the goal is simply to train your eye: six visible forms of the problem and what each one usually amounts to underneath.
| Visible symptom | What it usually is |
|---|---|
CLAUDE.md of 300 lines with dated exceptions |
Corrections written for models that are no longer in use. Each “except when...” marks a failure that may no longer exist. |
The same rule in the CLAUDE.md and in 3 skills |
Redundancy. It looks like safety (“reinforcing it can’t hurt”), but copies diverge over time and redundancy turns into conflict. |
| 400-line skill teaching “how to think” | Generic reasoning the model already does. A skill should carry procedure from your world, not a way of thinking. |
| Rigid 12-step process | Micromanagement. It worked with older models; today it blocks a better path the model could have found. |
| Two conflicting rules | Conflict. The model picks one—and you don’t know which one or when. That’s why “sometimes it gets it right, sometimes it doesn’t.” |
| Says nothing how to check that turned out right | The costliest gap of all. It’s not excess, it’s absence: without verification criteria, the model can’t know whether it finished well. |
🎯 The sixth symptom is different from the others
The first five are too much. The sixth is too little — and it’s what costs the most. Boris called verification the most important thing people get wrong: a short prompt with a real way for the model to check its own work beats a giant prompt with none. Remember this: ablation auditing isn’t just about cutting. In many configs, the audit’s result is cut 40% and add one verification line where there wasn't one.
Key concepts
Accumulated without a decision
Turns into a conflict over time
Recipe instead of criteria
The costliest gap
Find 3 legacy instructions in your config
Now let’s move beyond theory. The exercise in this module is a inventory, not a cleanup: you won’t delete anything today. You’ll just face how much you’re carrying and pick three suspicious lines. Start by measuring—most people are surprised by the number.
🧪 Inventory of the config itself
Objective: know how many lines you load in every run and locate passages that look like dated exceptions. Copy and run this in your terminal. Nothing here modifies files — it’s all read-only.
# 1) Quantas linhas você carrega em TODA execução? wc -l ~/.claude/CLAUDE.md # 2) E no projeto em que você está agora? wc -l ./CLAUDE.md 2>/dev/null || echo "sem CLAUDE.md de projeto" # 3) Quantas skills existem, e qual o peso de cada uma? ls ~/.claude/skills/ wc -l ~/.claude/skills/*/SKILL.md | sort -n | tail -20 # 4) Onde estão as exceções datadas (o cheiro mais forte de legado)? grep -n -iE "20(2[0-9])|antes|antigamente|corrigido em|mudou em|nao esqueca|sempre lembre|nunca esqueca" ~/.claude/CLAUDE.md # 5) Onde está o microgerenciamento (listas numeradas longas)? grep -n -E "^[[:space:]]*[0-9]+\." ~/.claude/CLAUDE.md | head -30 # 6) Qual regra aparece no CLAUDE.md E nas skills (redundância)? grep -rn -iE "sempre|nunca|obrigatorio|obrigatório" ~/.claude/CLAUDE.md ~/.claude/skills/ | wc -l
How to verify that it worked: you should finish with
three numbers in hand — lines of CLAUDE.md global, number of skills, and number of
"always/never" occurrences — and with at least one numbered line returned by command 4. If command 4 returns nothing,
run it on your skills too: sediment likes to hide there.
If you use another approach: replace
~/.claude/ by <a pasta de config que você usa>.
What matters isn’t the path—it’s seeing the number.
With the list on screen, choose three suspicious excerpts and fill in the table below (in a file, in a notebook, whatever works). The column that hurts is the third one: if you can’t date the line, even approximately, that’s information—it means it survived without ever being reevaluated.
| Passage (file:line) | What it tries to prevent | When it was created | Still needed? |
|---|---|---|---|
CLAUDE.md:42 |
"Read the file before editing" — prevented blind edits | The era when the model edited without reading | Probably not — test |
| … | … | … | … |
| … | … | … | … |
| … | … | … | … |
✅ Exit criterion for this module
You can point to three concrete lines of your configuration and say, for each one: what it tries to prevent e what period it’s from. That’s all. No lines deleted, no decisions made — the decision comes after the test, in module 1.2.
Quick check (doesn't block anything): Anthropic cut more than 80% of the system prompt in Opus 5. What was the criterion for what stayed?
📌 Module Summary
Next Module:
1.2 — The ablation method: delete everything, use it in real work, and restore an instruction only after seeing the same failure repeat.