🧬 Why delete

Boris Cherny, from the Claude Code team, said in a talk at Y Combinator — one day after the launch of Opus 5 — that the team removed more than 80% of the system prompt of the product. It wasn't a rewrite or a fine-tuning adjustment: it was a cut.

If whoever wrote the harness throws out four-fifths of their own prompt when the model changes, your personal configuration — written for models that are already obsolete — has no reason to be in better shape than theirs.

Harness = everything around the model (system prompt, tools, tool prompts). The harness is never finished: it's rewritten with every model release, and trimming it is part of the work.

Most of the old prompt existed to correct the behavior of a specific model: “don’t invent files,” “read before editing,” “don’t summarize at the end.” Today’s model already does this on its own—the instruction has become a fire extinguisher pointed at a fire that’s already out.

You didn't write that line because it was a timeless best practice. You wrote it because, one day in 2024, the model got something wrong. The line is a historical record of an error — and no one revisits the record afterward.

Every instruction has a creation date and a target model. When auditing, ask about each line: “What error did this prevent, and when did that error occur?” If you can’t answer, it’s a strong candidate for removal.

The 20% that remained isn't random. It remained security, permissions, static analysis e interface — rules about the world outside the model that no training can guess.

This is the practical dividing line for the entire audit. Instructions about how to think exits; instruction about what's true in your environment stays. Without this criterion, cutting is a gamble.

Never cut on reflex: project identity, paths and sources of truth, branding, compliance, interface contracts, and internal conventions. The model is good at reasoning, not at reading your mind.

A useless line isn’t neutral. It costs three things at once: burned context in every run, reduced autonomy (the model follows a worse path than the one it would choose) and a a rule nobody dares delete because no one knows what it protects anymore.

The cost is cumulative: 40 dead lines don’t cost you 40 lines once; they cost you 40 lines multiplied by the number of runs that year — plus a little inconsistent behavior in each one.

An instruction is debt with interest. Hence the course rule: every line is guilty of complexity until proven useful — the burden of proof is on the rule, not on the person who wants to delete it.

Six signs that your config has accumulated sediment: 300-line CLAUDE.md; the same rule repeated in 3 skills; a skill that teaches the model to think; 12-step process; rules that contradict each other; e no verification saying how to check the result.

Each symptom points to a different diagnosis: size suggests legacy content, repetition suggests redundancy, a long script suggests micromanagement, and contradictions suggest no one is reviewing it. This is the 5-minute filter before the formal audit.

The sixth symptom is the most deceptive: a config full of commands and without none A verification criterion tells the model how to act, but never how to know whether it got it right. This is the only category that’s usually missing—and the one you should add.

Open your ~/.claude/CLAUDE.md (and/or a project’s) and manually mark three instructions that exist to fix an old behavior. For each one, note what it tries to prevent and which era/model it came from.

Reading about the 80% cut changes nothing; finding your own three dead lines does. This is where the student’s actual config comes into the course — it runs through all four tracks.

Exit criterion: you can point to the three lines and answer, for each one, “what does it prevent?” and “when was it added?” Don’t delete anything yet — this module is just the inventory.

Ablation is a term borrowed from research: you remove a component of the system and observe what changes in the result. If nothing gets worse, the component wasn't contributing—the removal is the measure.

It's the opposite of what we do by instinct: add instructions until it works. Adding doesn't prove anything, because the system would also work without them. Only removing separates what does something from what just takes up space.

Ablation ≠ cleanup. Cleanup means deleting what looks messy; ablation means deleting and measure. Without an observation after the cut, you’ve only deleted a file.

The advice is straightforward: every ~6 months and every major model launch, delete the CLAUDE.md, the skills, and the hooks—and see what the model does without them.

The trigger has to be calendar-based, not mood-based. No one wakes up wanting to audit their own configuration; without a scheduled date, the buildup just grows until it becomes a visible problem.

A new model release is the best window: that's exactly when the largest number of old instructions have just become obsolete all at once. Deletion has to be in git—reversible, not heroic.

The cycle has four steps, in this order: 1) delete → 2) use it in real work (not in a toy test) → 3) observe where it stumbles → 4) return an instruction only after seeing the same failure recur.

Step 2 is the one everyone skips. If you test with an artificial task, the model gets it right and you draw the wrong conclusion; sediment only shows up in the tedious, specific tasks you do every day.

You’re terrible at predicting which line the model needs—that’s why the evidence comes before the instruction, not the other way around. Record it in a journal (ablacao-diario.md): what worked, what stumbled, did it happen again?

Two tools provide the “raw model” baseline: a system prompt flag at startup and CLAUDE_CODE_SIMPLE=1— which removes all prompts, including those for the tools.

Without a baseline, you have nothing to compare against. And there’s a counterintuitive finding here: without prompts, the model gets slightly smarter — prompts often exist so the product behaves the way a person expects, not so the model thinks better.

Baseline = same task, blank config. If the version with config doesn’t outperform the baseline on real work, the config is costing you without delivering.

An eval is the test you use to measure the agent. It ages too: a useful eval lasts 1 to 3 model generations before it gets saturated—everyone goes through; it no longer distinguishes anything.

A saturated eval suite gives a comfortable sense of security and detects no regressions at all. It’s the same dead weight as CLAUDE.md, just in the testing layer.

Create evals where you saw the model to stumble; retire the ones at 100% for two generations. A good eval is one that can still fail someone.

An instruction comes back only if all four conditions are true: 1) there was a real failure in real work; 2) the same class of failure repeated; 3) one specific instruction does the job; 4) it takes the shortest form possible.

Without this gate, the config returns to its original size in two weeks. Condition 2 is the filter that saves the most lines: a one-off failure is usually normal variation, not a pattern.

Condition 4 is qualitative: prefer a criterion statement (“the build must pass before the commit”) over a 12-step procedure. Criteria preserve autonomy; procedures destroy it.