Anthropic's updated context engineering guidance for Claude 5 generation models is less a list of new tricks and more a correction: a lot of prompting habits developed for weaker models actively hurt performance on models that no longer need them. The guidance generated significant Hacker News engagement — 291 points, 181 comments — largely because it forces a reassessment of prompting patterns many developers have been carrying forward by habit rather than by testing.
This article covers why prompting practices calibrated for older models can actively underperform on newer ones, what changes when a model's instruction-following genuinely improves, and how to tell the difference between a prompting habit worth keeping and one worth dropping.
Old scaffolding can actively hurt a model that's outgrown it
Context engineering is the discipline of structuring what information, instructions, and examples a model sees before generating a response — distinct from the model itself, but just as consequential for output quality. Much of the received wisdom in this space (heavy few-shot examples, highly explicit step-by-step instructions, defensive repetition of constraints) developed because earlier models genuinely needed that scaffolding to behave reliably.
The problem is that scaffolding built for a weaker model doesn't just become unnecessary as models improve — it can become actively counterproductive. Extra examples can anchor a more capable model to a narrower pattern than it would otherwise generate on its own; excessive explicit constraint can crowd out context budget that would be better spent on the actual task. This mirrors exactly what Anthropic's own Claude Code team described in their fireside chat about an 80% system prompt reduction — the same organization removing scaffolding from its own product because newer models no longer need it.
A prompting technique that helped a weaker model can become dead weight — or worse, a constraint — on a model good enough to figure out the task without it.
What "improved instruction-following" actually changes
When a model's instruction-following genuinely improves, the practical shift is less about what you can ask for and more about how much you have to specify to get it. A model with weaker instruction-following needs every edge case spelled out explicitly, because it won't reliably infer the intent behind an underspecified request. A model with stronger instruction-following can often infer reasonable defaults from a shorter, less exhaustive prompt — which frees up context budget for the parts of the task that actually need explicit detail.
This is the same dynamic behind the retirement of exhaustive few-shot examples: examples exist to demonstrate a pattern the model might not infer on its own. If the model already infers that pattern reliably from a clear instruction, the examples are consuming context space without adding proportional value — and in some cases actively narrowing the model's output toward the examples' specific style rather than the task's actual requirements.
Telling a habit worth keeping from one worth dropping
The practical challenge for developers is that prompting habits accumulate by trial and error against whichever model was current at the time, and rarely get re-tested against newer ones. The discipline the guidance implies is treating prompt structure as something to periodically re-benchmark, not something to set once and inherit indefinitely — a habit that worked well on an older model deserves an explicit A/B test against a stripped-down version once a materially more capable model is available, rather than an assumption that "more guidance is always safer."
This connects to the broader verification-bottleneck theme from Fowler's retreat notes — re-testing prompting assumptions against a new model is itself a verification task, and skipping it because the old prompt "still works" is exactly the kind of untested inertia that harness engineering as a discipline is trying to push teams away from.
What this means for builders
If your prompts were tuned against an earlier Claude generation, budget time to re-test a leaner version against Claude 5 rather than assuming your existing scaffolding is neutral at worst. Specifically test removing few-shot examples and collapsing overly explicit step-by-step instructions into higher-level task descriptions — Anthropic's own internal experience suggests the newer models often perform as well or better with less, and the freed-up context budget can go toward the parts of your task that genuinely need it.
Conclusion
The most useful takeaway from Anthropic's updated guidance isn't a specific new technique — it's the reminder that prompting practices have a shelf life tied to the model they were tuned against, and carrying them forward unexamined into a materially more capable model can cost you performance rather than protect it. Re-testing your context engineering assumptions against Claude 5 is a small investment against the risk of dragging outdated scaffolding into a model that's already outgrown it.