Most teams are about to use Claude Opus 5 like it is the last Claude model with a better benchmark.
That is a mistake.
Anthropic released Claude Opus 5 on July 24, 2026. But the most useful lesson from release week did not come from a benchmark chart. It came from Boris Cherny, the creator of Claude Code.
His advice was unusually direct: periodically delete the accumulated instructions around Claude Code and test what the new model can do without them.
That means your CLAUDE.md file, custom skills, hooks and rules added because an older model once made a mistake.
The point is not that context no longer matters. The point is that stale context can become a cage.
We have spent the last two years learning how to steer AI models. Claude Opus 5 is forcing us to learn when to stop.
Claude Opus 5 Is Not Just Another Model Update
Anthropic describes Claude Opus 5 as its most capable broadly available model. It is stronger at sustained work, careful iteration and verification, and Anthropic reports that it scored three times higher than the next-best model on ARC-AGI-3.
Those gains change more than what tasks the model can complete. They change how much scaffolding the model needs before it starts.
Older models often needed instructions such as:
- Always inspect these files first.
- Follow this exact sequence.
- Format every answer in this structure.
Each rule may have solved a real problem when it was written. Together, they become a historical record of failures that may no longer exist.
Cherny calls the result “hobbling.” The model may be capable of solving the problem, but the harness around it keeps pulling it back toward older behavior.
As he put it during his Y Combinator conversation about Claude Code and Opus 5, every instruction has “rent to pay.” Claude has to read it, interpret it and reconcile it with every other instruction on every turn.
The longer the file gets, the higher the rent.
Why Your CLAUDE.md Can Make Opus 5 Worse
A CLAUDE.md file is useful when it contains facts the model cannot reliably discover: the command that runs the real test suite, a non-obvious product convention, or an approval boundary for destructive actions.
It becomes harmful when it tries to predict and control every step.
The difference is simple. Good context describes the environment, the objective and the boundaries. Bad context micromanages the path.
Claude Opus 5 is better at exploring a repository, forming a plan, using tools and checking its own work. A rigid sequence written for an earlier model can prevent it from choosing a better route.
This is why the right question is no longer, “What else should we add to our CLAUDE.md?”
It is, “Which of these instructions still earns its place?”
The Delete Protocol: Ablation, Not Amnesia
We would not recommend deleting production safeguards and hoping for the best. That is not an experiment. It is an incident waiting to happen.
The better method is ablation: remove instructions in a controlled environment, measure the result, then add back only what evidence proves the model needs.
Here is the protocol we would use.
1. Preserve the non-negotiables
Identify the rules tied to security, compliance, irreversible actions and external commitments. Keep them until a test proves a safer architecture can replace them.
Do not confuse model steering with operational safety.
2. Save the current system
Create a branch or snapshot containing the existing CLAUDE.md, skills, hooks and system instructions.
3. Run Opus 5 with a clean context
Remove speculative instructions and legacy workarounds. Give Claude Opus 5 the objective, the necessary tools, the relevant boundaries and a clear definition of done.
Then watch what it does.
4. Build the verifier before expanding the prompt
Give the model a way to tell whether its work is correct:
- a test suite;
- a screenshot comparison;
- a schema validator;
- a production-like preview;
- a human approval gate for high-impact changes.
Verification gives Claude Opus 5 a feedback loop. More prose does not.
5. Log repeated failures
Do not add a rule because the model made one imperfect choice. Look for a repeated failure the model cannot detect or correct using the verifier.
One failure is an observation. A pattern is evidence.
6. Add one instruction back
Write the smallest instruction that prevents the repeated failure. Then rerun the same evaluation.
If the instruction does not improve the result, it has not earned its rent.
7. Repeat with every major model generation
Claude Fable 5, Claude Opus 5 and Claude Sonnet 5 do not share identical strengths, costs or working styles. Neither will the next generation.
Treat your context architecture as a living system. Re-test it whenever the underlying intelligence changes.
What Claude Opus 5 Prompting Looks Like Now
The old approach prescribes the route:
Read these twelve files in order. Write a seven-part plan. Modify one component at a time. Run these commands after each edit.
The stronger approach defines the outcome and the checker:
Rebuild this interface so it matches the production reference. Compare screenshots at the target breakpoints, fix every material difference and stop only when the build, interaction tests and visual comparison pass.
The second prompt is shorter, not vague. It contains four things Claude Opus 5 needs:
- the outcome;
- the reference;
- the verification loop;
- the exit condition.
That is the new center of gravity. Prompt engineering is not disappearing. It is moving upstream into task design, context architecture and verification.
The Best Prompt May Be a Better Checker
Cherny shared an extreme example during the Y Combinator event. His team asked Claude to rewrite an Electron application in native Swift. Instead of prescribing the architecture, the prompt told Claude to run both versions, compare screenshots and keep working until they matched.
Without a verifier, the model has to guess when the work is good enough. With one, it can iterate for hours or days while measuring its own progress.
The same pattern appeared in Cherny’s description of a large Bun runtime rewrite. A robust test suite acted as the referee while agents worked in parallel.
The lesson is not to launch a two-week autonomous rewrite. It is that ambitious AI work becomes practical when correctness is observable.
If a task has no test, preview, metric, reviewer or comparison target, the next step is not a longer prompt.
The next step is building the checker.
Where Claude Fable 5 and Claude Sonnet 5 Fit
“Claude 5” is becoming a useful shorthand for Anthropic’s fifth-generation model lineup, but the model names carry more specific search intent.
Claude Fable 5 is positioned for the hardest long-running work requiring extended autonomy and proactive verification.
Claude Opus 5 brings much of that capability to daily professional work. Its release triggered this fresh look at how Claude Code should be prompted.
Claude Sonnet 5 is the efficient workhorse for high-volume agentic workflows. It benefits from the same clean-context discipline.
The practical takeaway is not to build one massive instruction file for “Claude 5” and use it everywhere.
Start clean with each model. Evaluate it on the work you actually do. Preserve only the context that improves the measured result.
The Product Overhang Is Getting Wider
Anthropic uses the term “product overhang” to describe the gap between what a model can already do and what the software around it allows it to do.
That gap is now a product strategy problem.
A team can license Claude Opus 5 and still get yesterday’s results because its interface, permissions and prompts were built for yesterday’s model. The bottleneck may be a brittle workflow, not intelligence.
Closing the gap requires three things:
- enough access to do the work;
- enough structure to verify the work;
- enough restraint to avoid dictating every move.
The companies that get this balance right will turn maintenance cycles, research workflows and production processes into measurable agent loops.
Scheduled routines take the same idea further. A repository supplies context, a schedule supplies the trigger, a test suite supplies the verifier and a pull request supplies the review boundary. Mature agentic AI is not a magic sentence. It is a well-designed operating loop.
Prompt Injection Is Better. It Is Not Solved.
Claude Opus 5 arrives with stronger resistance to prompt injection. That matters when agents read external content and operate for long periods.
It does not justify giving any model unrestricted access to production.
Anthropic’s own work on containing Claude emphasizes environmental controls in addition to model behavior. Teams should still use least-privilege credentials, filesystem and network boundaries, sandboxing, approval gates and auditable logs.
Delete obsolete steering. Keep real containment.
Those are not contradictory ideas. They are the difference between trusting a model’s intelligence and ignoring operational risk.
The Bottom Line
Claude Opus 5 is not asking us to stop prompting. It is asking us to stop carrying every old prompt forward.
The new workflow is leaner:
- define a hard outcome;
- provide the real environment and tools;
- build a reliable verifier;
- observe the model without speculative steering;
- add back only the instructions that fix repeated failures.
Your CLAUDE.md should not be a museum of everything an older model once got wrong.
It should be the smallest set of facts and boundaries that helps Claude Opus 5 do better work today.
The intelligence changed. The harness has to change with it.
Claude Opus 5 FAQ
Is Claude 5 an official model?
Anthropic uses the individual names Claude Fable 5, Claude Opus 5 and Claude Sonnet 5. “Claude 5” is useful shorthand and a real search query, but the model names are more precise.
Should we delete our CLAUDE.md file?
Test a clean version in a branch or sandbox. Remove legacy workarounds first. Preserve security, compliance, destructive-action boundaries and project facts until evidence shows they are unnecessary.
What is the best way to prompt Claude Opus 5?
Define the outcome, supply the context and tools, provide a verifier and set a stopping condition. Add procedural instructions only when evaluation shows they improve results.
Are Claude Fable 5, Claude Opus 5 and Claude Sonnet 5 prompted the same way?
The principles are similar, but context and verification should fit the model and task. Evaluate each model instead of assuming one instruction stack fits the entire Claude 5 lineup.
Is prompt engineering dead?
No. It is evolving. The highest-leverage work is shifting from step-by-step micromanagement toward context architecture, task design, verifiers, permissions and feedback loops.
