Lessons from Anthropic Deleting 80% of Claude Code's Prompts: New Rules for Context Engineering

A Counterintuitive Move: Deleting 80% of the System Prompt

Anthropic did something that seems quite radical: they deleted over 80% of Claude Code's system prompt. What's even more surprising is that after running their official benchmarks post-deletion, performance didn't drop at all.

This move comes from an article written by Anthropic engineers about context engineering rules for the Claude 4/5 era of models. It complements the earlier piece "The Faber Guide: Finding Your Unknowns" — that article was about how to ask AI questions and uncover capabilities you didn't know existed; this one is about the opposite: removing things the model doesn't need from the context, which actually improves the Agent's capabilities.

These two directions seem contradictory but are actually unified: one is addition (discovery), the other is subtraction (streamlining). At the core, both aim to keep only truly useful information in the context.

The Core Difference Between Prompt Engineering and Context Engineering

The article first clarifies a commonly confused concept. Every message you send to AI is only a small fraction of what it actually receives — the bulk consists of system prompts, CLAUDE.md files, memory, Skills, and more. All of these combined form the totality of what AI actually reads every time it works. This whole package is called the Context, and the work of managing all of it is called Context Engineering.

To understand why context management is so critical, you need to know some technical background: large language models operate on the Self-Attention mechanism in the Transformer architecture, where every token computes relevance weights against all other tokens in the context. When the context contains redundant or contradictory information, the model must distribute attention weights among these competing signals — essentially introducing noise into limited "cognitive bandwidth." Research shows that as context length increases, the model's attention to middle passages drops significantly (the "Lost in the Middle" phenomenon), and contradictory instructions force the model to perform additional "reconciliation" computations during the decoding phase, degrading output quality.

The key distinction from prompt engineering:

• Prompt Engineering: Optimizes the input for a single request
• Context Engineering: Manages information across multiple requests

Put differently, one wrong sentence in the context drags down every single subsequent request. This is exactly the underlying logic behind Anthropic's bold prompt deletion — redundancy and contradictions in the context continuously consume the model's attention.

Why Delete? Because the Rules Were "Fighting Each Other"

While reviewing transcripts from internal employees using Claude Code, Anthropic discovered a problem: within the same request, the AI would receive mutually contradictory instructions.

For example, one rule says "retain documentation where appropriate" while another says "never write comments"; the system prompt says one thing, a Skill says another, and the user says yet another. The model can usually guess what you actually want, but it must first spend attention reconciling these contradictions before it can start working.

It's worth explaining Claude Code's layered information architecture here: its context is composed of multiple layers — at the bottom is the System Prompt, which defines the model's basic behavioral boundaries; above that is the CLAUDE.md file, essentially a project-level configuration document; then come Skills (modular instruction sets) that can be loaded on demand; and the outermost layer is the user's immediate input. This layered architecture means that every time the model executes a task, the actual number of tokens it reads far exceeds what's visible in the conversation to the user. Bloat in any layer produces compound performance losses across every invocation. When instructions across multiple layers contradict each other, the model's "reconciliation cost" multiplies accordingly.

These rules originated because older models lacked sufficient judgment and needed hard constraints. But the new generation of models (Opus/Sonnet series) have enough capability and judgment that many "safety nets" can be removed entirely, letting the model decide based on the situation at hand.

This change reflects a deep paradigm shift in AI engineering: from rule-driven to capability-driven. Earlier models (like GPT-3.5, Claude 2) had weaker instruction-following abilities, forcing engineers to constrain behavior with extensive hardcoded rules — essentially a "defensive programming" mindset. But with advances in alignment techniques like RLHF (Reinforcement Learning from Human Feedback) and Constitutional AI, new-generation models have internalized extensive behavioral norms and judgment capabilities. At this point, excessive external rules are not only redundant but may conflict with the model's internalized judgment, creating a "double bind" dilemma that actually degrades performance. This is highly analogous to the software engineering principle that "over-configuration increases system fragility."

Six New Context Engineering Rules Explained

The article provides six specific solutions, which can be understood as context engineering principles for the new era.

Rule 1: Trust the Model's Judgment — Write Fewer Prohibitions

The old system prompt was filled with prohibitions like "don't write comments by default," "never write multi-line comment blocks," and "don't create planning/decision documents." But these prohibitions are useless in many scenarios — users may have their own documentation preferences, and complex code genuinely needs multi-line comments.

The new system prompt replaces that entire section with a single sentence: Write code that looks like the surrounding code — match the comment density, naming conventions, and style of the existing repository.

Rule 2: Let the Tools Speak for Themselves

In the past, when teaching AI to use tools, we'd provide examples to guide it. But with new models, these examples actually box the model into a fixed pattern, locking down the exploration space it could otherwise leverage.

The article gives an excellent example: a to-do tool has only three states — in progress, completed — plus one rule: "only one item can be in progress at a time." The state values themselves tell the model what to do; there's no need for a bunch of examples explaining what "in progress" means. This also explains why new models sometimes seem to "not understand" when you want divergent thinking — they've been locked down by old frameworks.

Rule 3: Load on Demand (Progressive Disclosure)

Previously, instructions for "how to do code review" and "how to do verification" were all packed into the system prompt, regardless of whether they'd be used in the current session. Now these are split into independent Skills that are loaded only when needed. The official term is Progressive Disclosure, which is essentially the "load on demand" principle that Skills have always emphasized.

Progressive Disclosure is a classic design principle from Human-Computer Interaction (HCI), proposed by IBM researchers in the 1980s. The core idea is: only present complex information when the user needs it, avoiding cognitive overload from showing all options at once. Anthropic's migration of this principle to AI context management means they've started treating the model as an "intelligent agent with a cognitive load ceiling." At the implementation level, after Skills are split into independent files, Claude Code's routing mechanism dynamically loads relevant Skills based on the current task type, rather than stuffing all instructions into the context window at the start of every conversation. This design not only saves precious context space but also prevents irrelevant instructions from interfering with the current task.

It's worth noting that this approach of "storing routing rules, hooks, and skills separately" had already been explored by practitioners. Now the official team has essentially written it into the system prompt.

Rule 4: Say Important Things Once — That's Enough

Older models had a quirk: they didn't retain instructions from the beginning well and preferred to follow instructions near the end. So the official team used to write usage instructions once upfront and then repeat them inside each tool. Now all that repetition has been removed — how to use a tool is written only within the tool itself, read only at invocation time, and no longer takes up space in the system prompt.

The technical foundation for this change is that new models have dramatically improved their ability to process long contexts. Earlier models, limited by positional encoding and attention decay, tended to "forget" information at the beginning and middle of the context, making repetition a necessary engineering compromise. New-generation models, with improved attention architectures, can attend more evenly to information at all positions in the context, making "say it once" viable.

Rule 5: Automatic Memory Instead of Manual Notes

Previously, users needed to take manual notes. Now the model itself judges what's worth storing. This rule hands the initiative for memory management to the model itself, reducing the user's maintenance burden.

Rule 6: Provide Rich Reference Materials, Not Simple Documentation

Previously, planning mode relied on Markdown for plans and specifications. Now the model can consume much more complex reference materials: HTML prototypes, test suites, even existing functions from other codebases can all be used directly as specifications.

The article also mentions a type of reference material called rubrics — write your taste into a standard and have AI run a verification agent to check against it. This approach is known in AI engineering as the LLM-as-Judge pattern, where the core idea is using an independent AI agent as a "quality inspector" to evaluate another AI agent's output against preset criteria. This method was first widely validated in automated academic paper review and later introduced into software development workflows. Its advantage lies in converting subjective "taste" and "preferences" into executable evaluation protocols, giving AI output quality a reproducible verification path. In Claude Code, this means users can write personal preferences like "I prefer concise function names" or "error handling should cover edge cases" into structured criteria and hand them to a verification agent for automatic execution — achieving "programmable aesthetics."

Practical Advice for Regular Users

This context engineering methodology, when applied to regular users, distills into several actionable tips:

• Don't worry about the system prompt: Only people building their own Agents need to work on this; regular users won't notice much difference.
• Keep CLAUDE.md lightweight: Briefly explain what the repository does and include information only you would know (like naming preferences). Don't repeat things the AI can already infer from the code.
• Make Skills into lightweight guides: Don't write them as regulations. The most valuable Skills are the ones containing your own opinions and workflows. Split long Skills into multiple files and continue loading on demand.
• Make good use of reference materials: You can now feed reference materials directly to it — this feature has long been available in Codex and VS Code, but this is the first time Claude Code has formally proposed it.

Additionally, the official team created a convenient command: type /doctor in a conversation, and it will automatically "diagnose" and optimize your Skills and CLAUDE.md files. The logic behind this command is precisely the context engineering principles discussed in this article — it detects whether your configuration files contain redundant instructions, contradictory rules, or content that could be migrated to Skills, then provides streamlining suggestions.

Core Takeaway: Remove the Patches Written for Old Models

The core of the entire article can be condensed into one sentence: Once the model is powerful enough, you don't need so many rules to constrain it.

All those rules we wrote in the past were essentially "patches" for old models. After the model upgrades, these patches aren't just useless — they become stumbling blocks: they consume attention, create contradictions, and lock down exploration space.

This is perhaps an important signal that context engineering is maturing: shifting from "telling AI exactly how to do everything" to "giving it sufficient judgment space and high-quality reference materials." This transition evokes a classic proposition in management theory — the comparison between Micromanagement and Empowerment. When team members lack capability, detailed instructions are necessary; but when members are mature enough, excessive instructions actually suppress creativity and judgment. The evolution of AI models is undergoing the same phase transition: from a "junior employee" who needs hand-holding, to a "senior expert" who can deliver autonomously given only goals and reference materials.

Sometimes, subtraction takes more skill than addition.