This week, Anthropic published a blog post titled “The new rules of context engineering for Claude 5 generation models.” It shot to the top of Hacker News — 301 points, 187 comments — and was greeted with the kind of earnest enthusiasm the developer community reserves for new frameworks, new paradigms, new things to put on a resume.
The post is, by all accounts, useful. It explains how to manage the context window: what to load, when to load it, how to compress accumulated history, how to route queries to the right sub-agent, how to avoid the “lost in the middle” problem where models forget things buried deep in a prompt. These are real problems. The advice is probably good.
But step back and look at what’s actually being celebrated here. A company has shipped a product so finicky about what information it sees and in what order that using it effectively now requires a formal discipline — complete with named patterns, best-practice guides, and a growing cottage industry of consultants who will teach your engineering team how to talk to the box correctly.
This is not a sign of maturity. It is a sign that the abstraction is leaking, badly, and we’ve decided to call the leak a feature.
The Leaky Abstraction Tax
Joel Spolsky coined the “law of leaky abstractions” in 2002: all non-trivial abstractions leak, and the only question is how much of the underlying complexity the user has to absorb. By that measure, Claude 5 is a fire hose.
The context window on Claude 5 is enormous — Anthropic pushed it to 500,000 tokens in the previous generation, and Claude 5 almost certainly goes further. That sounds like freedom. In practice, it means the model can hold an entire codebase in memory and still forget the function you asked it to fix three messages ago. The window is big enough to lose things in. Hence “context engineering”: the art of deciding what the model should and shouldn’t see, because giving it everything makes it worse.
This is not how good tools work. A hammer does not require you to understand grain patterns in wood to drive a nail. A car does not ask you to manage fuel-air mixtures. When a tool requires the user to develop specialized knowledge about its internal failure modes, the tool is incomplete. The fact that we’ve now formalized that knowledge into a discipline — with official corporate documentation — doesn’t make the tool complete. It makes the incompleteness institutionalized.
The Job Title That Shouldn’t Exist
“Context engineer” is now a thing people put in their LinkedIn headlines. Job postings list it as a desired skill. Conference talks are being given about it. The Towards AI blog published a “State of Context Engineering in 2026” roundup this month that reads like an industry survey of a mature field.
But what does a context engineer actually do? They manage the attention span of a piece of software. They decide which documents to feed it, in which order, with which system instructions, so that it doesn’t get confused and produce nonsense. This is not engineering. This is the kind of work that, in any other product category, would be handled by the product itself — silently, invisibly, without the user ever knowing it was a problem.
One developer I spoke with in a Slack channel for AI tooling put it bluntly: “I spend 40% of my time on a Claude project just managing what goes into the prompt. Not writing code. Not designing systems. Just pruning context so the model doesn’t wander off.” He asked not to be named because his employer sells AI consulting services and doesn’t want clients to know how much of the labor is janitorial.
If 40% of the labor in using a tool is compensating for the tool’s limitations, the tool is not ready. The fact that we’ve given that labor a respectable name doesn’t change what it is.
What Apple Would Have Done
There’s a useful thought experiment here. Imagine Apple had shipped the iPhone in 2007 with a 50-page guide called “The New Rules of Touchscreen Capacitance Engineering.” The guide explains that your finger has a certain electrical profile, and if you tap too quickly the screen gets confused, and here are five patterns for managing your tap cadence. The developer community would have been thrilled. Normal people would have put the thing in a drawer.
The difference between a technology and a product is that a product absorbs complexity on the user’s behalf. A technology exports it. Claude 5, for all its genuinely impressive capabilities, is still exporting an enormous amount of complexity. The context engineering guide is the receipt.
This is not an argument against Claude or Anthropic. The models are remarkable. The progress is real. But the framing matters. When a company publishes a guide to working around its own product’s limitations and the industry treats it as a landmark contribution to a new field, something has gone wrong with our standards. We’ve confused documentation for innovation.
The best AI product of the next five years won’t be the one with the most comprehensive context engineering guide. It will be the one whose users have never heard the phrase.