The rules you wrote to stop a weaker model from misbehaving are now instructions a stronger one will actually follow.
On 24 July 2026, Anthropic published a post by Thariq Shihipar, a member of its technical staff, with a line in it that should have stopped every AI-assisted engineering team cold:
“We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.”
Read that as a confession, because that is what it is. The team that builds the most-used coding agent on the market looked at the instructions it had accumulated for that agent, deleted four fifths of them, ran the evals, and found nothing had gotten worse.
Now go and look at your repo root. That CLAUDE.md — or AGENTS.md, or .cursorrules, or whatever your house calls it — has been growing for a year. Every time the model did something annoying, somebody appended a line. Nobody has ever removed one. It is unversioned against the model it targets, unreviewed since whichever Tuesday it was last edited in anger, and it is load-bearing on every single turn you have run since Opus 5 shipped.
Anthropic just published the delta. It is worth understanding what is actually in it, because the popular reading of this news — “prompts should be shorter now” — is the least interesting part.
The instruction that stopped being free
Start with the most concrete change, because it is the one written into the official migration checklist:
“Claude Opus 5 verifies its own work without being told to, so remove explicit verification or self-check instructions carried over from prompts tuned for earlier models; leaving them in causes over-verification.”
The Opus 5 prompting guide says the same thing about self-correction, and names the exact phrases:
“Avoid instructing re-checks it already performs (‘double-check your answer,’ ‘re-verify before responding’); like verification instructions, these compound with the model’s own behavior and add cost without improving results.”
Note the mechanism, because it is the whole story in miniature. On a weaker model, a redundant instruction was close to free — it got half-ignored, cost you a few tokens, and occasionally helped. On a model with strong instruction-following, the same line fires. It compounds with behaviour the model already performs. You are paying twice for one verification pass and calling it insurance.
That is not a prompt getting stale. That is a prompt inverting.
The line nobody is quoting, and the one that actually matters
Here is where it gets genuinely uncomfortable. Buried in the capability notes of the Opus 5 prompting guide, in the section on code review:
“If your review prompt says ‘only report high-severity issues’ or ‘be conservative,’ the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.”
Sit with why you wrote “be conservative” in the first place. You wrote it because an earlier model hallucinated findings. It flagged non-bugs, invented CVEs, drowned your review channel in noise, and “be conservative” was the muzzle that made the output usable. It was never a statement about what you wanted. It was a correction applied to a specific failure mode of a specific model.
That failure mode is gone. The muzzle is not. Anthropic’s own description of Opus 5 is that “it finds real bugs at a high rate per pass, and its additional findings are mostly real issues rather than false positives.” So the instruction no longer suppresses false positives, because there are far fewer to suppress. It suppresses true ones.
This is the actual technical debt, and it is invisible in a way that ordinary debt is not. A stale dependency throws a warning. A stale behavioural hedge throws nothing at all. It just quietly returns you a shorter list of bugs, and a shorter list of bugs looks exactly like a cleaner codebase.
Rules became judgment
Anthropic frames its rewrite as six shifts. The first is the one with teeth, and they published the before and after.
The old Claude Code system prompt said:
“Default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.”
The new one says:
“Write code that reads like the surrounding code: match its comment density, naming, and idiom.”
Look at what changed. The old rule is a constraint that is sometimes wrong — plenty of codebases legitimately want a real docstring — and the team knew it was sometimes wrong when they wrote it. They accepted a known-bad rule because the alternative was a model that could not be trusted to make the call. The new line does not encode an answer at all. It encodes the goal, and delegates the judgment.
That is the pattern to steal, and it generalises past Anthropic’s product. Go through your instruction file and mark every line that is a constraint you knew was wrong at the edges when you wrote it. Each of those is a candidate for replacement by a statement of intent.
The remaining five shifts, condensed:
- Examples → interface design. Worked examples now constrain exploration rather than guiding it. Put the affordance in the tool’s parameters instead.
- Everything upfront → progressive disclosure. Detailed guidance moves into skills that load only when relevant, rather than sitting in the base context on every turn.
- Repetition → simple tool descriptions. Instructions duplicated across the system prompt and the tool docs get consolidated into the tool definition, once.
- Manual memory → auto-memory. Claude now saves relevant memories itself, rather than requiring you to hand-maintain entries in
CLAUDE.md. - Simple specs → rich references. Markdown plans give way to test suites, rubrics, and executable artefacts the model can actually verify against.
The fourth and fifth quietly reduce the file’s job description. Progressive disclosure says most of what is in your CLAUDE.md should not be in your CLAUDE.md — it should be a skill that loads when the task calls for it. Auto-memory says a chunk of the rest should not be hand-written at all. Anthropic’s own remaining guidance for the file is to keep it lightweight: state what the repository is for, and spend your token budget on genuine gotchas rather than facts the model will discover from the directory tree in one ls.
How to actually audit yours
Do not open the file and start deleting. Two reasons: you will not be able to attribute a quality regression to any single removal, and much of what looks like debt is not.
The word “verification” in your file is a good example of the trap. Most instances of it are not self-check instructions at all — they are domain vocabulary (JWT verification, HMAC signature verification, email verification flows) or gates on real external tooling that must still run. Deleting on a keyword match will break things that were working.
A workable order of operations:
- Separate the two kinds of content. Repository facts — what this service does, which database, the deploy path, the genuine landmine in module X — are permanent. Model-behaviour compensation — “be concise”, “don’t over-engineer”, “always double-check” — expires roughly every model release. Split them into different files, or at minimum different sections, with different review cadences. This is the single highest-value structural change, because it makes the perishable half visible.
- Delete the self-check instructions first. These have explicit vendor guidance behind them and the lowest risk.
- Convert hedges into filters. Anywhere you told the model to under-report, invert it: let it report everything, and filter in a second pass where you can see what you are throwing away.
- Relocate rather than delete. Anthropic moved verification and code review into skills that load on demand. The same move works in your repo: a two-hundred-line section that matters only during database migrations belongs in a migrations skill, not in the base context of every conversation about CSS.
- Add the instruction you are missing. Opus 5 writes longer than its predecessors, and the migration guide is explicit that turning effort down does not fix it: “Default visible responses and written deliverables run longer on Claude Opus 5 than on earlier Opus models, and lowering effort reduces thinking volume without reliably shortening the visible response. Prompt explicitly for conciseness or a target length instead.” Most instruction files written before Opus 5 say nothing about length at all. That absence is debt too.
- Batch and watch. Remove in small groups, keep working, and pay attention to whether output quality moves. Wholesale deletion gives you no signal.
Claude Code also now ships a /doctor command intended to help rightsize skills and CLAUDE.md files. Run it before you do any of this by hand.
Why to believe the vendor here
One thing worth naming: this advice runs against Anthropic’s own revenue. Every instruction they tell you to delete is tokens they no longer bill you for. Over-verification is billable. Redundant self-checks are billable. A company optimising purely for consumption would have stayed quiet and let your bloated prompt file keep firing.
They published the delta instead, along with the eval result that justifies it. That does not make every line of it correct for your codebase, and you should still verify against your own evals rather than mine or theirs. But it does mean the incentive is pointing the unusual way, and that is rare enough to be worth weighting.
Your instruction file is the last artefact in the repo that nobody reviews. It is also the one that runs on every turn.
Sources
- Thariq Shihipar, “The new rules of context engineering for Claude 5 generation models”, Claude blog, 24 July 2026 — the primary source for the 80% figure and the six shifts.
- Anthropic, Migration guide — verification-removal and verbosity guidance.
- Anthropic, Prompting Claude Opus 5 — literal instruction-following, hedges in review prompts, self-correction.
- paddo.dev, “Your CLAUDE.md Is Now Technical Debt”, 25 July 2026 — the commentary that prompted this piece.

