Take the Cast Off
Anthropic deleted more than 80% of Claude Code's system prompt and lost nothing they could measure. I ran the same test on my own instructions. I now know the answer for one file out of ninety-three.
Every Sunday I pick one paper or release that's worth your time, break it apart, and tell you why it matters. No hype. No summaries of summaries. Just the idea, explained.
In late July, Anthropic deleted more than 80% of the system prompt that runs Claude Code.
That prompt is the standing instruction set the tool carries into every session, built up over a year of watching the model get things wrong. Four-fifths of it came out. Their coding evaluations showed no measurable loss.
The engineer who wrote it up said those constraints "were once needed to avoid worst-case scenarios," and that they could now "delete many of them and let the model use surrounding context and judgment instead." A rule about code comments that had grown into three dense clauses came back as fifteen words: write code that reads like the surrounding code, match its comment density, naming, and idiom.
They were not tidying up. They had worked out they were holding their own model back, through the system prompt and through the instruction files and skills they had written around it.
Everyone downstream has been writing those files too.
The cast
You put a cast on a broken limb. It is the right call. The joint is immobilized, the bone knits, and while the bone is broken nothing else does that job.
Leave it on past healing and the muscle underneath wastes. The limb that comes out is thinner than the one beside it. The cast never stopped doing what it does. What changed is that the thing it was protecting no longer needed protecting, so all that is left is the constraint.
Every instruction you have written for an AI system is a cast. You wrote it because the model got something wrong, and you were right. The model underneath has been replaced two or three times since, and nothing in your setup tells you which bones have healed.
The instruction did not stop working when the model improved. It became the thing holding it back.
None of that makes scaffolding bad. It makes it indistinguishable. Some of what you wrote is capability the model still lacks, and some is a monument to a weakness it grew out of, and on the page the two look identical: both helped on the day you wrote them, both read like good instructions, and only one of them still earns its place. Reading the file will not tell you which one you are holding.
What the vendor is telling you to do
Boris Cherny built Claude Code and now runs product for it at Anthropic. At Y Combinator, asked what ordinary users should do, he gave the shortest possible answer:
"for people that aren't building agentic products but you're using Claude Code, every six months delete your Claude.md. Delete your skills."
He is not guessing. Anthropic keeps an internal switch that strips every prompt out of the tool, and they flip it on purpose to check whether the prompt is helping:
"we actually use this as a sort of ablation to figure out: is the prompt useful? And what's interesting is that the model is actually a little bit more intelligent without these prompts."
Then, a few sentences later, he says the opposite:
"when you use Claude Code as a product, you do actually want some of these prompts because it helps you use the product."
Both of those are true, and reading them together is what makes the trade visible. The instructions make the model slightly less capable and the product considerably more predictable. Predictable is usually what you wanted. So the choice was never scaffolding against no scaffolding. You are spending capability to buy consistency, and almost nobody knows the exchange rate they are getting.
His rebuild rule is the practical half. Delete the file. Work normally. Add an instruction back only after you have watched the model make the same mistake twice. Guessing in advance is how the file got big in the first place, and every line you guess wrong at gets read on every request for as long as it sits there.
So I tested mine
I have 93 of these files. In May I had 41, after a deliberate cull with a written report justifying every cut. It grew back inside three months. It always grows back, because adding one is somebody's job and deleting one is nobody's.
Not one of them had ever been measured. I had usage counts and instincts.
The test itself is dull. Take one file. Run the same real tasks three ways: the assistant with no instructions at all, the assistant with my current file, the assistant with a rewritten candidate. Then have a separate AI read two answers side by side, blind to which came from where, and pick the better one against a written standard.
Before any of its verdicts counted, I handed the judge a rigged pair. One answer was good. The other was fluent, well formatted, and built on two invented citations. It had to catch them, and it named both. A judge that cannot fail will certify whatever you point it at, so the scoring does not start until it has proved it can flunk something.
I picked the file I use most: the one that tells the assistant how to read and review an academic paper. Three matchups, twenty blind comparisons.
The rewritten version won all five of its comparisons against no instructions. Against my current file it won eight of ten.
Then the matchup I had not expected to care about. My current file against nothing at all: three wins, two losses.
Five comparisons is thin and I am not going to dress it up as more. But three to two is not the score of a file I would have defended, and I would have defended that one hard. Most of what I thought it was adding, the model already had.
The instruction set I use most beat deleting it by three to two.
What had actually rotted
I kept the file. What was wrong with it was specific, and it was not the failure I would have guessed at.
Academic papers usually exist twice, as a free preprint and as the published version of record, and the numbers in them differ. My old instructions produced a review that took three figures from the preprint, reported them as the journal's, and then signed off by certifying that every number in the document traced to the published article. Wrong on exactly the sentence a reader repeats out loud in a meeting, and confident about it.
The rewrite makes every claim record which document it came from, and bans blanket confidence statements outright. It went in this week, after I read the diff.
The file had not gone useless. It had decayed in one specific place, and nothing I was tracking would have surfaced it. Usage was high. Overlap with other files was zero. It read well.
The dashboard will not tell you
The obvious question is whether you can skip the testing and read this off your metrics instead. You cannot. Every cheap signal I have used to judge these files has already misled me, and each failure is written down with a date.
I removed a browser tool after a scan showed it unused. The scan window turned out to be 0.2 days. Measured properly afterwards: 3,030 calls across 159 sessions, 19 of them on the morning I removed it. Restored the same day.
Four of my instruction files show zero use while the capability behind them runs constantly. One shows zero uses against 770 calls to the same underlying tool by a different route. The instruction was never the path anything took. A zero can mean nobody wants this, or it can mean something else already won, and on a dashboard those are the same number.
In July one component measured 22,837 tokens of overhead. In August the same component measured 863. Nothing about it had changed. A setting governing when things load was misconfigured, so every earlier measurement had been reading the setting rather than the component. A separate cut I projected would save 5,665 tokens measured 111.
A per-component cost is a property of your configuration, not of the component.
Cutting is not free either
In April, Anthropic added one instruction to Claude Code's system prompt telling it to keep responses brief. One of their evaluations showed a 3% drop, on both Opus 4.6 and 4.7. Added on the sixteenth, reverted on the twentieth. A single sentence of standing guidance, and the damage ran the opposite way to anyone's intuition, because the instruction that hurt was an instruction to be concise.
There is also no threshold to aim for. The work measuring how models degrade as instruction counts rise finds steady decay across 500 instructions, in three different shapes depending on the model, and names no cliff in any of them. Prune by whether a thing still earns its place, never by a budget.
Which three you measure this quarter
A finer-grained experiment exists and I could not afford it: instead of testing a whole file against nothing, cut it into layers and measure what each layer adds on its own. Showing that a layer helps takes six comparisons. Showing that one does nothing takes twenty three, because proving no difference is a much stronger claim, and four layers at that rate runs about four times what one night already cost.
So measuring everything was never the plan. One file took about sixty agents and most of a week's compute. The plan is picking which three you measure this quarter, and three properties decide it. Usage is not one of them.
The first is reliance. Not how often a file fires, but how far you would trust its output without checking. A file whose answers land in a slide nobody re-derives deserves more scrutiny than one that fires forty times a day into work you read line by line anyway.
The second is age measured in model generations, not months. An instruction written for a model two releases back was written against failure modes that may no longer exist. Mine was young on the calendar and two generations old.
The third is whether the file makes factual claims that can rot without showing a symptom. Mine did. A style instruction that goes stale produces prose you dislike, and you notice inside a paragraph. A factual instruction that goes stale produces confident wrong numbers in a register that reads exactly like the correct ones, and nothing in the output tells you which one you are looking at.
The job nobody owns
Underneath the technical problem is an organizational one, and it decides whether any of this happens more than once. It also explains how my own count went from 41 back to 93 in three months without anyone deciding that it should.
Adding an instruction is somebody's job. It happens the moment something breaks, it takes ten minutes, and the person who does it is visibly fixing a bug. Deleting one is nobody's job. It means proving a negative, it produces no improvement anyone can see on the day, and the person who does it is one incident away from being the person who removed the guardrail. The incentives are not close, and they point the same way in every organization I have watched, including my own.
The teams that get this right are not the ones with the best tooling. They are the ones who have made four unglamorous things normal.
Every instruction carries the failure it was written for, and the date. One line. An instruction with no recorded reason can only be reviewed by the person who wrote it, and in eighteen months that person has changed teams or forgotten. Write down what broke and you have handed the next reviewer a test they can run: does it still break.
Removal has a named owner and explicit cover. Somebody's job description includes taking things out, and leadership has said out loud, before anything goes wrong, that a removal which turns out badly is a normal cost of the review rather than a mistake with a name attached. Without that, the review meeting happens and nothing leaves the room.
The review runs on model releases, not on quarters. Every release re-dates every instruction written before it. Tie the review to the calendar and you will audit a stable setup in a quiet month and miss the one that moved under you in a loud one.
The output of a review is a number, not an opinion. Two versions, real tasks, and a reader who does not know which is which. It does not take sixty agents. It takes one person blind to the answer, which is the step that gets skipped, because the author of a file is the worst available judge of it and is usually the only person in the room.
Adding an instruction is somebody's job. Deleting one is nobody's job. That asymmetry, not the model, is why your setup grows.
Ninety-two
The three-to-two is not the number that bothers me.
I own 93 instruction files. I measured one of them, on one night, and it cost about sixty AI agents and most of the compute I would normally spend in a week. The other 92 are exactly as unexamined as they were on Monday, and several of them are older than two model generations.
That ratio is going to get worse. Models ship faster than anyone's scaffolding gets reviewed, every release re-dates every instruction written before it, and there is no alert for any of it, because nothing degrades visibly and the file keeps loading and the work keeps coming out fine while the gap between what your instructions do and what they were written to do widens on a schedule you do not control.
So pick your most-relied-on instruction, the one you would defend hardest, and run a week without it. Have someone who does not know which is which read the output both ways.
You will get one of three answers, and two of them are cheap. Either something better exists, or the model outgrew it, or what you have is fine and you can stop wondering. I went in expecting the first. I got it, and I also found out my old file was barely beating the fourth option nobody plans for, which is having written nothing at all.
Sources
The new rules of context engineering for Claude 5 generation models: Thariq Shihipar, Anthropic, 24 July 2026. The 80% deletion, the "no measurable loss" claim, and the then/now table of practices Anthropic now calls myths.
Boris Cherny: Building Claude Code: Y Combinator Startup School. The delete-every-six-months advice, the ablation switch, and the admission that the model is "a little bit more intelligent without these prompts."
Anthropic's April 23 postmortem: the brevity instruction that cost 3% on one evaluation, added 16 April and reverted 20 April.
How Many Instructions Can LLMs Follow at Once?: Jaroslawicz et al. The IFScale benchmark, 500 instructions across 20 models, and the finding that there is no threshold to prune toward.
Sunday Deep Dive is a weekly series on Run Data Run. Every Sunday I pick one paper, release, or technique worth understanding, break it apart, and tell you what it means for your work. Free every Sunday, no paywall. If it was useful, the easiest way to support it is to subscribe and forward it to one person on your team who'd want it. If it wasn't, tell me why. I'll make it better.