The New Rules of Context Engineering for Claude 5 Models

If you have spent time building with Claude, you have probably absorbed a set of habits about how to prompt it and how to structure the context around it. Recently the team behind Claude Code shared something that upends a lot of those habits: they deleted more than 80% of Claude Code's system prompt for the newest generation of models and saw no measurable drop in coding performance. That is a striking result, and it points to a bigger shift in what "context engineering" actually means now.

Context engineering is the practice of assembling everything Claude sees beyond your immediate message: the system prompt, CLAUDE.md files, skills, memory, and reference files. Unlike a single prompt, this context is reused across many different requests, so it has to be general. The old instinct was to make it exhaustive. The new lesson is almost the opposite: give the model room to use its judgment, and only add structure where it genuinely earns its place.

Below I walk through the six biggest shifts, each with a simple analogy to make it stick.

Shift 1: From giving rules to trusting judgment

When Claude Code first launched, the team leaned on strong, absolute rules to avoid worst-case behavior, things like "default to writing no comments" or "never write multi-line comment blocks." Those rules were sometimes wrong (some complex code genuinely needs detailed comments), but older models needed the guardrails. Newer models have better judgment, so the guidance changed to something like: write code that reads like the surrounding code, matching its comment density and naming. Analogy: it is the difference between handing a line cook a rulebook that says "never add salt" versus hiring a seasoned chef and telling them the dish you want. You trust the chef's palate instead of scripting every move.

Shift 2: From giving examples to designing interfaces

The old number-one rule for tool usage was to give Claude examples. Counterintuitively, the team found that examples can constrain the newest models, boxing them into a narrow slice of the possibility space. The better move is to design the tool itself so its shape communicates intent. Take a simple Todo tool: defining a status field as an enum of pending, in_progress, and completed already hints at how it should be used, and a note like "keep only one item in_progress" defines the behavior without a single worked example. Analogy: think of a well-labeled control panel. If every knob and button is clearly named, you do not need a sticky note taped beside it explaining what to press.

Shift 3: From putting everything upfront to progressive disclosure

The old approach crammed everything Claude might ever need into one place, on the theory that it would not find the information otherwise. The new approach is progressive disclosure: load the right context at the right time. Claude Code moved things like code review and verification into separate skills it calls only when relevant, and some tools are now deferred, meaning Claude searches for their full definitions before using them so they do not eat up context until needed. The same idea applies to your own CLAUDE.md and skill files: prefer a tree of smaller files loaded on demand over one giant document. Analogy: a good textbook index. You do not read all 900 pages up front, you flip to the exact chapter you need, exactly when you need it.

Shift 4: From repetition to simple tool descriptions

Earlier models sometimes needed the same instruction repeated, and tended to weight instructions near the end of the context window more heavily than those at the start. So teams would mention a tool in the system prompt and then repeat instructions in the tool description. With newer models, those duplicate mentions can be deleted: put the instructions for how to use a tool inside the tool's own description, and leave it at that. Analogy: a good manager tells you something once and trusts you to remember it, instead of sending the same reminder five times before lunch.

Shift 5: From manual memory to auto-memory

The old habit was to manually save things into CLAUDE.md, often using a hotkey to append notes for Claude to remember. Now Claude automatically saves memories that are relevant to the work and to you, so you spend less effort curating a memory file by hand. Analogy: a colleague who quietly remembers your preferences, that you take your coffee black, that you hate meetings before ten, without you having to re-explain it every single morning.

Shift 6: From simple specs to rich references

Plans and specs used to live as simple markdown files. Newer models can handle much richer references: an HTML artifact instead of a plain markdown plan, a detailed test suite instead of a written spec, or even a function in another codebase that Claude can port. Rubrics are another powerful form of reference, letting Claude check its work against your taste in a given area, such as what good API design looks like, by spinning up verifier agents. The rule of thumb: prefer references that live in code, because it is a high-fidelity language Claude already understands well. An HTML mockup usually beats a screenshot or a prose description of the same design. Analogy: instead of describing a house to a builder in words, you hand them the actual blueprints.

The takeaway: simplify

If there is one thread running through all six shifts, it is this: keep your system prompt, CLAUDE.md, and skills lightweight. Describe what your project is for, spend most of your words on the non-obvious gotchas, and let the model handle the rest with its own judgment. Use progressive disclosure for the details, encode your genuine opinions and hard-won knowledge into skills, and reach for rich references over long descriptions. The newest models are capable enough that over-constraining them now does more harm than good. When in doubt, delete a rule and see if the model was already smart enough to not need it.