Anthropic Deleted 80% of Its System Prompts and Coding Scores Didn't Budge
Although some of A's recent practices are indeed off-putting, Thariq's ability to write technical articles is something I respect. So, criticize what needs criticizing, and learn from what's worth learning.
On July 24, Anthropic published an article on context engineering. A core viewpoint in the article is:
They deleted over 80% of the system prompt for new models like Claude Opus 5 and Claude Fable 5, yet there was no significant loss in coding evaluation scores.
So, are most of the rules we painstakingly wrote in the past now obsolete, or even counterproductive?
This article starts with this question, and then I'll walk you through the full picture.
The term "context engineering" in the text means the same as context engineering.
A Prompt is just your current round of conversation with Claude.
The System prompt, Skills, CLAUDE.md, memory, tool definitions, file content, and terminal output—these together constitute the actual context the model receives.
As many large models become increasingly capable, such as Kimi K3, Fable 5, Opus 5, and GPT-5.6 Sol, more skills are often not better; on the contrary, they can become a burden.
A core viewpoint of the article is: In the era of strong models, context engineering needs subtraction.
Give the model the most useful information at the right time.
Past Constraints and Current Judgments
Anthropic previously introduced a very important concept in their context engineering guide: models have a limited attention budget.
A longer context window does not mean more attention.
If you add an irrelevant rule to the model, the model spends some attention judging whether it's useful; if you add a priority rule, the model also has to decide which one to follow first.
As a result, the context may seem large and rich, but effective attention gets drowned out.
So the 80% figure means that the judgment of the new generation of models is now strong enough that many behaviors that previously needed to be hard-coded can now be left to the model's own judgment.
Of course, the basis for judgment includes the codebase, user requirements, and environmental information.
Anthropic summarized this change into six pairs of old and new practices:
Image source: Anthropic
I think these six changes can be summarized in one sentence: Previously, we relied on rules to constrain the model's decisions; now, we clarify the reference sources and let the model make its own decisions.
Claude Unshackled
When Anthropic internally reviewed Claude Code's execution logs, they found that a single request often contained several conflicting scenarios.
The System prompt said not to add comments, a Skill said to supplement documentation when necessary, and the user requested that complex code should have clear documentation.
Image source: Anthropic
Claude can usually guess what the user wants, but it first has to process the conflicts between these contexts.
Old system prompts typically hard-coded rules about comments: don't write comments, don't write multi-line docstrings, don't proactively create planning or analysis documents.
This could correct bad habits of older models, such as over-generating comments or fabricating design intent for code.
But the cost was equally obvious: when encountering complex code or tasks that genuinely required documenting design decisions, it would conversely prevent the model from supplementing necessary information.
So the new system prompt retains only one rule:
Write code consistent with the surrounding code style, matching the existing project's comment density, naming conventions, and idiomatic patterns.
To summarize: An effective, long-term rule should tell the model how to judge, but don't make the decision for it.
The model will read the code itself and decide whether to write comments.
Design Interfaces
Previously, when teaching a model to use a tool, a common practice was to provide a few call examples. But Anthropic found that models like Claude 5 might be limited by these examples.
They gave an example of a TODO tool:
Image source: Anthropic
The TODO tool does only two things: restricts the status to pending, in_progress, and completed, and stipulates that only one task can be in_progress at a time. Claude can understand how to maintain task status just by looking at the parameters.
If a constraint can be written into the interface, don't put it in the system prompt.
Context
Claude Code previously stuffed code review, verification, and tool usage instructions all into the system prompt. But most tasks never needed this content, and it consumed attention every round.
Now this part has been split into Skills and lazily loaded tools.
When verification is needed, load the verification Skill; when a tool needs to be used, first find the complete definition through ToolSearch. Normally, only the name, purpose, and file path are kept, letting Claude know where the tool is.
This is called progressive disclosure.
This principle also applies to CLAUDE.md. It should only store content that every task needs to know, such as the project's purpose, build commands, special directories, and pitfalls in the codebase.
Claude Code now recommends keeping each CLAUDE.md within 200 lines.
There's also an easy pitfall here: splitting large chunks of content into several files and then importing them all into CLAUDE.md via
@only makes it look cleaner; at startup, they all still enter the context.To truly save context, use rules loaded by path, or turn task flows into Skills.
Memory also has a clearer division of labor.
For example, a JavaScript project's CLAUDE.md could be written like this:
- Run `npm test` after modifying JavaScript.
- Prefer using `pnpm` for installing dependencies.
- Place API handlers uniformly in `src/api/handlers/`.
These are rules you proactively set, to be followed every time you work.
Auto memory might contain:
- Integration tests report `ECONNREFUSED` when local Redis is not started.
- After modifying the schema, types need to be regenerated, otherwise tests will read old types.
- The user prefers PR descriptions to state risks first, then changes.
These are experiential summaries Claude discovers while working. An occasional one-off error doesn't need to be hastily written into CLAUDE.md. If the same problem recurs, or if team members also need to know, then upgrade it to a formal rule.
What you require Claude to follow every time goes in CLAUDE.md; what Claude figures out on its own goes into auto memory.
Reference
Another change is that references are no longer limited to Markdown format specs.
It can be an HTML prototype, a set of tests, a function in another repository, or a clear set of scoring criteria.
Image source: Anthropic
If you want Claude to build a page, giving it a runnable HTML is usually more accurate than writing two pages of visual description.
If you want it to port a certain behavior, pointing directly to existing code is more direct than re-explaining it.
If you want it to judge what constitutes a good API, give it a set of scoring criteria. For example, check naming, error formats, permission boundaries, and compatibility, then have another Agent check item by item against this standard.
Anthropic gave the same judgment in the Fable 5 usage guide: in complex tasks, source code is often the most information-rich reference, because structure, semantics, and boundaries are all defined there.
The original Anthropic article also preserved a boundary: Skills should still maintain strict constraints in extremely important domains. Deleting files, accessing sensitive data, sending external messages, modifying production environments—these operations cannot rely solely on the model's judgment and must be strictly defined.
So it's not that just because the model's judgment is strong, all rules can be deleted.
The official documentation states very clearly: CLAUDE.md is context, not an enforcement layer. Rules that truly must be followed need to be placed in permissions, sandboxes, hooks, and code.
I think it can be differentiated like this:
For code style, comment density, and documentation habits, let the model judge based on the project.
For permissions, compliance, funds, and irreversible operations, enforce them directly.
So to summarize the main content of this article:
System prompt: State what permissions the Agent has and what type of work it needs to complete. People building their own Agent harnesses should mainly consider this part.
CLAUDE.md: Only put project pain points needed every time, precise instructions, and hidden pitfalls. Content that Claude can know just by glancing at the directory or code should be deleted.
Skills: Save operational methods for specific tasks, such as releases, code reviews, and frontend verification. When a Skill is very long, separate detailed references and scripts for on-demand reading.
Memory: Save experiences and preferences accumulated during work.
References: Prioritize giving code, tests, HTML prototypes, and measurement standards.
Claude Code now incorporates these practices into the /doctor command, which can first check Skills and CLAUDE.md.
Context used to be like writing an employee handbook, afraid of missing a single rule.
Now it's more like preparing a work environment for a smart engineer: what the constraints are, where the tools are, where the materials can be found, and how to test and verify after completion.
This is the main thing this article aims to explain.
Reference Links
- The new rules of context engineering for Claude 5 generation models
https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
- Effective context engineering for AI agents
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- A field guide to Claude Fable 5: Finding your unknowns
https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
- How Claude remembers your project