Anthropic published an engineering post on 24 July that retires a run of its own recommended practices for working with Claude. The post's word for them is myths, and it names six.

The number in the subtitle is why it travelled. "We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5," writes Thariq Shihipar, a member of technical staff at Anthropic, "with no measurable loss on our coding evaluations."

For anyone who has spent two years writing careful instructions for a coding agent, that is a bracing sentence. A large share of that work may now be doing nothing — or, given what the post says about instructions colliding, worse than nothing.

What actually got deleted

The most useful thing in the post is that it prints the before and after.

The old Claude Code system prompt said:

In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max. Don't create planning, decision, or analysis documents unless the user asks for them — work from conversation context, not intermediate files.

The new one says:

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

Thirty-nine words of prohibition became fifteen words of direction. The replacement does not tell the model what to avoid; it tells the model what good looks like and leaves the call to it.

The reason for the change, per the post, is that the prohibitions were sometimes wrong. "For a certain subset of prompts, this guidance would be wrong" — a user may have their own documentation preferences, and "specific parts of very complex code might need multi-line comment blocks." The rule was a blunt instrument accepted as a tradeoff, and the post says the tradeoff is no longer worth making.

There is a related finding about instructions colliding. Reading transcripts of internal Claude Code usage, the team saw "several conflicting messages in a single request" — "leave documentation as appropriate" from one layer against "DO NOT add comments" from another, as system prompt, skills and user request clash. Claude can generally work out what the user meant, the post says, but it "must think more carefully about these overlapping and conflicting messages before deciding what to do." Contradictory guidance is not free even when it is survivable.

The six reversals it names

• Give Claude rules → let Claude use judgement. The guardrails existed to prevent worst cases; newer models are said to handle the decisions without them.
• Give Claude examples → design interfaces. Covered below; the biggest practical change.
• Put it all upfront → use progressive disclosure. Verification and code review moved out of the system prompt into skills the agent calls when it needs them. Some tools are now "deferred loading" — the agent has to look up their full definitions with a tool search before it can use them, so they cost no context until they are wanted.
• Repeat yourself → simple tool descriptions. Earlier models "could sometimes need repeated instructions or be more likely to listen to instructions at the end of their context window than at the start." The repeated examples were deleted, and instructions moved into the tool descriptions themselves.
• Memory in CLAUDE.md → auto-memory. The # hotkey that wrote memories into CLAUDE.md gives way to memories the model saves on its own.
• Simple specs → rich references. A spec can be a test suite, or a function in another codebase to port. Rubrics let the model "try and verify" your taste, using verifier agents run against them.

The post presents these as examples rather than an inventory — "there were a number of previous context engineering best practices that had become myths," it says, "including" the six.

The reversal that will cost the most rework

The examples one. "The number one rule for tool usage was to give Claude examples on how to use them," the post says. "With our newest models, we've found that giving examples actually constrains them to a certain exploration space."

That is narrower than "stop writing examples" — the remedy is aimed at the design of your "tools, scripts and files" — but it inverts advice that shaped a great deal of agent tooling.

What replaces it is not an absence of instruction, which is the part worth getting right. The post's own illustration is a todo tool whose status field is an enumeration of pending, in_progress and completed: the enumeration "hints to Claude about how to use it," and a single instruction about keeping one item in_progress "helps define our requested behavior." The guidance moves into the shape of the interface instead of sitting beside it as a worked example.

Guardrails written for the tail, removed on the average

The post is unusually direct about why the deleted rules existed. "When we first rolled out Claude Code, we needed to be sure that Claude avoided worst case scenarios, such as deleting files." It also says: "while these constraints were once needed to avoid worst case scenarios, we have since found we can delete many of them and let the model use surrounding context and judgement instead."

The only quantitative evidence offered for removing them is "no measurable loss on our coding evaluations." The rest is a judgement call, stated as one: "newer models have better judgement and can handle these decisions well without explicit rules."

The measurement and the rationale are not the same test. An evaluation suite reports how a model does across a benchmark; the constraints were written for the tail — the run where the agent deletes the wrong file. The post does not claim the evals cover that, and it says "many of them," not all. But a developer lifting the advice into their own agent is inheriting a judgement made against Anthropic's workload, on Anthropic's evaluations, in one domain.

The scope qualifier is easy to lose and does real work: this is for "models like Claude Opus 5 and Claude Fable 5" — "more advanced models," per the subtitle. The post is explicit that the guardrails earned their place on what came before: "Still, without these guardrails for older models, the comments Claude wrote would be incorrect in many cases and we had to accept this tradeoff." If your agent runs on a cheaper or older model, the myths may still be true where you are.

A note on where this comes from

Three weeks before this post, Claude Code was in the middle of a row about routing that users had not been told about: requests flagged with an internal marker named TOO_DUMB_TO_NEED_FABLE were being quietly sent to Opus 4.8, a cheaper model than the Fable 5 tier subscribers were paying for.

Anthropic's redeployment post, published on 30 June — before the row broke — had already described a fallback of that shape: "Users will be notified if a request to Fable 5 is blocked, and the request will instead be sent to Opus 4.8." That post names no internal marker, and Anthropic has not publicly connected the fallback to the TOO_DUMB_TO_NEED_FABLE label; treating them as the same mechanism is an inference, not a company statement. But the promise in that sentence is the one the row was about, and users were not notified. Shihipar's reply at the time, as reported then, was "Honestly, I didn't expect you to look at the logs." We covered it in the 3 July Daily Update.

A detailed public account of what the system prompt contains, and what has been taken out of it, is a markedly more open posture toward the same audience. If you want the background on what a system prompt is and why its contents matter, we have an explainer.

What to actually change

The post closes with advice by layer, and it is specific enough to act on:

• System prompt. Tied to the product it runs in. Claude Code users will likely never modify it — but "if you are building your own agent harness, this is where you should spend a lot of time."
• CLAUDE.md. Keep it light. Say briefly what the repo is for and "spend most of the tokens on gotchas inside of the codebase." Avoid stating the obvious things the model can read off your file system. Where you have several instructions on verifying work, make a verification skill and point at it from CLAUDE.md rather than inlining it.
• Skills. Lightweight guides that help the model find information when it needs it. Avoid overconstraining them, "except in highly important areas." Split long ones across several files. They work best encoding opinions and practice particular to you or your team.
• References. You can @-mention files. Prefer things written in code, "as it provides clear, high-fidelity instructions to Claude in a language it knows very well" — an HTML mockup of a design "will generally produce better results than a description of the design or a screenshot."

There is tooling for the cleanup: Anthropic says it has put these practices into /doctor in Claude Code, to rightsize skills and CLAUDE.md files.

The through-line across the six reversals is the same one visible in the rewritten comment rule. The instruction that survived was the one describing what good work looks like, not the one enumerating what to avoid. That pattern is worth carrying to whichever model you build on — and unlike the eval result, it costs nothing to test on your own.

For the adjacent economics of what you put in front of a model, see our explainer on prompt caching, and on how a large vendor measures its own coding agents, Microsoft's study of its internal rollout.