Anthropic recently shared that it removed more than 80% of Claude Code’s system prompt for its newer models, with no measurable loss on its coding evaluations.
That is a striking result. But the most important lesson is not simply that shorter prompts are better.
It is that we may be over-engineering instructions while under-engineering the environment around the model.
Earlier-generation models needed detailed rules, repeated reminders and examples of expected behaviour. Over time, those instructions accumulated across system prompts, repository files, skills and user requests.
The result was often a wall of overlapping guidance: add documentation where appropriate, do not add unnecessary comments, follow existing patterns, but also apply this specific example.
Newer models are increasingly capable of interpreting intent and exercising judgment. Giving them too many rules can make them less effective, not more. They spend effort resolving our contradictions instead of solving the actual problem.
Anthropic’s recommendations reflect this shift:
- Replace rigid rules with guidance grounded in the surrounding code.
- Design expressive tool interfaces instead of documenting every possible usage through examples.
- Load specialized instructions only when needed through progressive disclosure.
- Keep repository-level guidance focused on non-obvious constraints and project-specific gotchas.
- Use code, tests, specifications, mockups and rubrics as high-fidelity references.
From an engineering perspective, this feels less like prompt optimization and more like good system design.
The interface is part of the context
A well-designed API does not require pages of instructions explaining how every parameter combination should work. Its interface, types, validation and boundaries communicate much of that intent.
Agent tools should work the same way.
If an agent regularly misuses a tool, the problem may not be the prompt. The interface itself may be ambiguous. Better parameter names, constrained values, sensible defaults and explicit validation can communicate intent more reliably than another paragraph of instructions.
This changes where we should invest our effort. Instead of teaching the model to work around a confusing interface, we should improve the interface.
Progressive disclosure beats monolithic context
The same principle applies to context.
A massive CLAUDE.md or system prompt becomes the AI equivalent of a monolithic configuration file: difficult to maintain, easy to contradict and loaded into situations where most of it is irrelevant.
Progressive disclosure gives us a cleaner model. Keep the default context small, then load domain-specific knowledge, workflows and verification guidance when the task requires them.
This is not just about saving tokens. Relevant context is easier to reason over. A focused code-review skill is more useful during review than a general repository file containing release instructions, migration guidance, API conventions and incident-response procedures all at once.
Repository-level guidance still matters, but it should concentrate on what the model cannot easily infer: unusual architectural constraints, project-specific failure modes, non-standard commands and decisions that look wrong without historical context.
Everything else may already be expressed more clearly by the codebase itself.
Rich references are better than verbose instructions
There is another important shift here: from describing the desired result to showing it precisely.
Code, tests, specifications, mockups and rubrics are often higher-fidelity references than prose. A test suite communicates expected behaviour in an executable form. A typed interface defines valid inputs. A mockup captures design intent more precisely than a long description of spacing and hierarchy. A rubric makes subjective quality easier to evaluate.
These references do more than tell the model what to do. They also give it a way to check whether the work is correct.
That is a much stronger foundation than adding more words to a prompt.
Judgment still needs boundaries
There is, however, an important enterprise caveat.
“Let the model use judgment” should not mean removing security controls, approval boundaries, compliance rules or verification. We should reduce instructional noise, not operational safeguards.
The better pattern is to give the model freedom inside clearly enforced boundaries:
- Scoped permissions
- Sandboxed execution
- Automated tests
- Policy checks
- Human approval for high-impact actions
- Observable execution
In other words, constrain the outcomes that matter, not every reasoning step the model might take.
This is another reason context engineering increasingly resembles architecture. The most dependable constraints are often enforced by the system rather than described in the prompt.
Treat context like code
I would also be careful about treating Anthropic’s result as universal.
Removing 80% of a prompt worked for particular models on particular coding evaluations. Different models, older deployments and regulated workflows may behave differently.
Context changes should therefore be treated like code changes: versioned, evaluated, monitored and rolled out gradually.
If a team simplifies its system prompt, it should run the same representative tasks before and after the change. It should measure outcome quality, tool-use behaviour, policy compliance and failure rates. It should also watch for regressions that a single aggregate benchmark might hide.
The goal is not the smallest possible prompt. The goal is the smallest context that reliably produces the behaviour the system needs.
From prompting to architecture
My main takeaway is that context engineering is maturing.
The first phase was about finding the right words to make a model behave. The next phase is about building the right environment for capable models to operate in.
That means leaner default context, better interfaces, richer references, stronger verification and fewer instructions that merely repeat what the model—or the codebase—can already determine.
The future of context engineering may involve writing less, but engineering considerably more.
Source: The new rules of context engineering for Claude 5 generation models