Is your CLAUDE.md actually helping Claude — or is it fighting it?
Most engineers assume more instructions mean better output. That every rule you painstakingly added to your project configuration for earlier Claude models still applies with Opus 5. After all, explicit instructions are explicit instructions — why would they hurt?
Because the model underneath has changed, and your prompt file hasn’t.
What Anthropic Actually Cut
According to their own blog post, Anthropic removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 — and their coding evaluations did not move. Not a marginal loss. Not a trade-off. No measurable change in performance whatsoever.
Let that sit for a moment. The company that builds the model decided that the vast majority of instructions it had written for its own coding agent were redundant. Not wrong — unnecessary. The model had internalized the behaviour those instructions were compensating for.
If Anthropic can remove four-fifths of their own carefully tuned system prompt without evaluation loss, the same logic applies to the rules sitting in your repository’s CLAUDE.md. Some of them are doing real work. Others are artefacts from a model that needed more hand-holding.
Why Your Old Rules Backfire on Opus 5
Think about why you added verification instructions to your CLAUDE.md in the first place. Rules like “always run the test suite before committing,” “confirm the build passes,” “double-check edge cases” — you wrote them because an earlier model wouldn’t self-verify without being told. Quality assurance was a gap you had to patch with explicit prompting.
Anthropic’s Claude Opus 5 migration guide addresses this directly: the model verifies its own work without being told to, and carried-over verification instructions should be removed. When you instruct a model that already self-verifies to verify again, you aren’t layering on additional safety. You’re creating redundant processing that consumes context window, burns tokens, and potentially introduces conflicting directives that pull focus from the primary task.
Instructions written for a weaker model are followed literally by Claude Code. The model doesn’t triage your CLAUDE.md and silently discard the ones it considers redundant. It processes every instruction you give it — including the ones that now fight its built-in behaviour.
The Damage Is Invisible
This is the part that makes it dangerous. Your CLAUDE.md won’t throw an error. Claude won’t refuse to work or flag a warning. The model will dutifully follow every instruction — including the stale ones — and produce functional code. You’ll get slightly slower responses, slightly higher token consumption, and slightly less attention allocated to the instructions that actually matter. But you’ll never notice, because there’s no A/B test running against your prompt configuration.
Unlike a syntax error or a failing test, prompt bloat produces no signal. The degradation is silent: more tokens spent on meta-instruction, less context budget available for the actual code problem. Over time, as models improve faster than your configuration files are updated, this gap only widens.
The Fix: Separate Facts from Compensation
The corrective action is straightforward but requires discipline. Open your CLAUDE.md and sort every instruction into one of two categories:
- Permanent repository facts — statements that are true regardless of model version. “We use TypeScript strict mode.” “Our API follows REST conventions.” “Deployment targets AWS Lambda.” These belong in your configuration because they encode project context the model cannot infer from code alone.
- Model-behaviour compensation — instructions that patch a weakness in an earlier model. “Always verify your output.” “Check for off-by-one errors.” “Ensure all imports are correct.” These were necessary once. According to Anthropic’s migration guide, for Opus 5 they should be removed.
If your team runs multiple Claude models, move the compensation rules into a model-specific override file rather than keeping them in your shared CLAUDE.md. The goal is a clean separation: permanent context on one side, behavioural nudges on the other — with the latter reviewed and trimmed every time you upgrade models.
This kind of audit is exactly the sort of engineering discipline that separates teams that ship reliably with AI from teams that accumulate invisible technical debt in their prompt files. At Code N Rob, we think of prompt configuration the same way we think about any other infrastructure: it needs maintenance, versioning, and periodic review.
Start with your CLAUDE.md today. Open it, read every line, and ask one question: is this still true about the model I’m actually using? If you’re not sure, remove it and run your evals. You might be surprised by how much lighter — and faster — your agent becomes.
