What is context engineering and why does it matter?
When you send a message to Claude, your prompt represents only a tiny fraction of what the model actually receives. Most of the context is assembled from several sources: the system prompt, CLAUDE.md files, Skills, persistent memory and other elements configured upstream. This entire process is called context engineering.
Unlike a standard prompt, which is written for a specific request, context is used across many different requests. It must therefore be general enough to remain relevant in a variety of situations while still guiding the model effectively. It is a delicate balancing act, and that balance has shifted considerably with the arrival of the Claude 5 models.
The team behind Claude Code recently made a surprising discovery: when working with models such as Claude Opus 5 and Claude Fable 5, it was possible to remove more than 80% of the Claude Code system prompt without any measurable loss on coding evaluations. This figure illustrates how much the new context engineering practices differ from those that were standard just a few months ago.
Freeing Claude from excessive constraints
One of the first lessons drawn from this evolution is that older models were overconstrained. System prompts accumulated rules that were sometimes contradictory, redundant examples and very rigid instructions designed to prevent the worst possible scenarios.
For example, an instruction such as “Never write multi-line comments” could be completely unsuitable for certain complex projects where detailed documentation is essential. These guardrails were necessary for older models, but they become counterproductive with newer generations, which have better contextual judgment.
The shift from a logic of rigid rules to a logic of trust in the model’s judgment is at the heart of this evolution. Rather than telling Claude exactly what to do in every situation, we now give it general principles and let it adapt its behavior to the actual context.
Old practices that have become obsolete
Here is an overview of the context engineering myths that have been called into question with the Claude 5 models.
Giving strict rules versus trusting judgment
Previously, you had to write very precise rules to prevent unwanted behavior. Today, an instruction such as “Write code that matches the surrounding code: respect its comment density, naming conventions and idioms” is enough. Claude adapts its behavior to the context, without you needing to anticipate everything.
Giving examples versus designing expressive interfaces
The number one rule for tool use used to be providing concrete examples. With the new models, examples tend to confine the model’s exploration to a space that is too narrow. It is better to design tools with expressive parameters.
For example, a task management tool whose status is defined by a clear enumeration (pending, in_progress, completed) naturally guides Claude on how to use it, without the need for detailed examples.
Putting everything upfront versus progressive disclosure
Older system prompts included all potentially useful information from the start, even when it was not always needed. Progressive disclosure means loading the right context at the right time. Specific instructions, such as those related to code verification, can be moved into dedicated Skills that Claude calls only when it needs them.
Repeating yourself versus concise tool descriptions
Older models sometimes needed instructions repeated in different places in the context to remember them properly. With Claude 5, it is enough to place instructions in the description of the relevant tool. Repetitions in the system prompt are not only unnecessary, they can even harm clarity.
Manual memory versus automatic memory
It used to be recommended to encourage users to manually save information in CLAUDE.md files. Now, Claude automatically saves relevant information about the project and the user, reducing the cognitive load required to manage memory.
Simple specifications versus rich references
Simple markdown files were the standard for storing plans and specifications. The new models can make use of much richer references:
- HTML artifacts;
- detailed test suites;
- functions from other codebases;
- evaluation rubrics that help Claude understand your stylistic or architectural preferences in a given area.
How to assemble your context today
By applying these new principles, here is how to structure your context effectively for Claude 5.
The system prompt
The system prompt is closely tied to the product context. It tells Claude what environment it is operating in and what its general role is. If you use Claude Code as is, you will probably never need to modify it. However, if you are building your own agent, this is where you should focus most of your design effort.
The CLAUDE.md file
Keep your CLAUDE.md light and concise. Briefly describe the purpose of the repository, then focus on the quirks and pitfalls specific to your codebase. Avoid repeating what Claude can infer directly by exploring your file tree.
- Mention non-obvious conventions (for example, all types in a single monolithic file).
- Reference Skills for detailed instructions rather than including everything directly.
- Use progressive disclosure: create a tree of files that are loaded at the right time.
Skills
Skills are lightweight guides that allow Claude to find the information it needs at the right moment. Avoid overconstraining them, except in critical areas. For long Skills, split them into several files and apply progressive disclosure. The best Skills encode opinions, knowledge or practices specific to your team or product.
References
You can mention files directly in your conversations with Claude to include them as references. Prefer references in the form of code rather than text descriptions or screenshots: an HTML mockup will generally produce better results than a written description of the same design, because Claude understands code with great precision.
Simplify: the key approach for the new models
If you built complex system prompts, Skills or CLAUDE.md files with older models, it is time to review them.
Simplification is not a loss: it is an opportunity to let the native capabilities of the Claude 5 models shine through fully.
The claude doctor tool (accessible via the /doctor command in Claude Code) was designed to help you automatically analyze and simplify your context files. It identifies redundant instructions, unnecessary constraints and sections that can be moved into dedicated Skills.
In summary, context engineering for Claude 5 rests on three main principles:
- trust the model’s judgment rather than trying to anticipate everything;
- load context progressively rather than putting everything upfront;
- design expressive interfaces rather than piling up examples.
These principles may seem counterintuitive if you are used to older models, but they reflect a profound evolution in the capabilities of next-generation LLMs.
Adopting these new practices not only improves the quality of your agents’ output but also reduces the complexity of maintaining them over the long term. Fewer rules, less repetition, and a model that truly understands what you want to build.
