Prompt Engineering Is Dead. Long Live Context Engineering.

[Glenn83]

For roughly two years, prompt engineer was a genuine job title. Companies posted six figure salaries for people who knew the specific magic words, say think step by step, add a few examples, phrase the instruction just right, and watch output quality visibly jump. That job title has largely disappeared from listings in 2026, not because the underlying skill stopped mattering entirely, but because the actual bottleneck in building useful AI systems has moved somewhere else, and the industry has increasingly settled on a new term for where it went: context engineering. This piece traces where that term came from, what it actually means in practice, why bigger context windows have made the problem harder rather than easier, and what the shift genuinely changes for anyone building with AI day to day.

Where the term actually came from

The phrase has a fairly traceable origin, which is unusual for a piece of tech jargon this widely adopted. Shopify CEO Tobi Lutke used it publicly in a post around early June 2025, and about a week later Andrej Karpathy, the former Tesla AI director and OpenAI founding member, amplified it with a definition that has since become the field's most quoted framing, calling context engineering the delicate art and science of filling the context window with just the right information for the next step. Within roughly a month, academic researchers had produced a survey paper cataloguing more than 1,400 related papers, showing just how quickly the underlying practices this term describes had already been developing in scattered form before anyone gave them a shared name. By early 2026 the term had gone fully mainstream, in the first quarter of that year Neo4j, Elastic, ByteByteGo and Firecrawl all independently published comprehensive guides specifically on context engineering rather than prompt engineering, a genuinely notable convergence given those companies serve fairly different corners of the AI infrastructure market. A State of Context Management report circulating in 2026 found 82 percent of IT and data leaders now agree that prompt engineering alone is no longer sufficient to run AI at meaningful scale, and 95 percent of surveyed data teams said they planned to invest specifically in context engineering training during the year.

What the distinction actually means

The core distinction being drawn is genuinely simple even if the engineering underneath it is not. Prompt engineering treats an AI interaction like a copywriting problem, craft the ideal instruction, tune the wording, add the right examples, and optimize a single message in isolation. Context engineering treats the same interaction as a systems design problem instead, the question is no longer just how do I phrase this, it's what does the model actually need in front of it right now to do this well, where does that information come from, and how do you keep it clean, current and free of noise. One widely shared framing compares it to how a doctor works, a good doctor does not just answer whatever question you ask on the spot, they pull your chart, your history, your vitals, and respond with all of that context already loaded. Context engineering is essentially building that chart for the model before it ever has to answer anything.

Most practitioners now describe context engineering as resting on roughly four pillars. Instructions, meaning system prompts and behavioral framing, is where classic prompt engineering genuinely still lives on as one component rather than the whole discipline, a well written system prompt and precise tool descriptions still matter enormously. Retrieval, meaning RAG and grounded search pulling in relevant external documents or data, is the pillar most people already associate with this space. Memory, both short term conversational state within a single session and longer term persistent facts about a user or task that carry across sessions, is the pillar that separates a genuinely useful assistant from one that starts every conversation from zero. And available tools, the function calling surface a model can actually act through, increasingly standardized across the industry through protocols like MCP, is the pillar that turns a model from something that only talks into something that can actually go and do things. RAG specifically is often misunderstood as being synonymous with context engineering, but it is really just one input into the retrieval pillar, the broader practice is deciding what the model's entire visible context actually contains, and retrieval is only one of several ways that content gets assembled.

Why bigger windows made this harder, not easier

A genuinely important nuance getting real attention in 2026 is that bigger context windows have not made this problem go away, if anything they have made careless context management more costly rather than less. Models now routinely offer windows exceeding a million tokens, and the intuitive assumption for a lot of people building on top of them was that a bigger window meant you could simply stop worrying about what goes in and just include everything plausibly relevant. Researchers have since documented a real and measurable phenomenon nicknamed context rot, where model accuracy and reliability degrade as more content gets stuffed into that window, even when the window technically has room for it, and a closely related failure mode known as lost in the middle shows models process information sitting at the very start or very end of a context far more reliably than content buried in the middle of a long document dump. One widely cited comparison sums this up well, a large context window is rope, and context engineering is knowing how much of that rope you actually need for the specific job rather than using all of it by default just because you can.

This plays out very concretely in retrieval pipeline design. A pipeline that retrieves fifty candidate documents with high recall and then re-ranks them down to a precise top five is usually better in practice than one that simply dumps all fifty chunks straight into the prompt and hopes the model sorts out what actually matters on its own. Coding agents have become a particularly useful laboratory for studying this, because the relevant context in a codebase is genuinely structured, the retrieval problem is well defined, and failure modes show up in test suites within seconds rather than requiring subjective human judgment to spot. AI agents specifically have driven a lot of this urgency, because agents fail differently than simple chatbots do, an agent's failure modes tend to be state management failures, losing track of what it already tried, forgetting an earlier instruction, or acting on stale retrieved information, rather than pure prompt phrasing failures, and that distinction is a large part of why context engineering became the dominant framing specifically once agentic systems moved from research demos into genuine production use during 2025.

What this changes for people actually building with AI

None of this fully retires prompt engineering as a skill, and it is worth being precise about that rather than overselling the shift as a total replacement. Writing a clear, well structured system prompt and precise tool descriptions still matters and still shows up as one explicit layer inside the broader context stack, described by practitioners in this space as roughly five percent of what determines final output quality in a modern production AI system, with the remaining ninety five percent coming from the information the model is actually given to work with at that specific moment. For anyone building AI agents, coding assistants, or any system meant to run reliably in production rather than as a one off chatbot demo, that shift in emphasis, from clever phrasing toward disciplined information architecture, is arguably the single most consequential change in how practical AI engineering actually gets done this year. It also changes what the actual valuable skill looks like day to day, less time spent iterating on exact wording, more time spent thinking carefully about data pipelines, memory design, retrieval quality and knowing precisely what to deliberately leave out of the window rather than what to cram in.

[MickFoley00]

Really enjoyed this breakdown, especially the four pillar structure, but I think it slightly overstates how clean the split between prompt and context engineering actually is in practice. In my own experience building agent workflows, the two are so tangled together that treating them as genuinely separate disciplines with separate job descriptions feels more like a marketing convenience for consultants selling new training packages than a description of how the actual work gets done day to day. A system prompt that tells the model how to prioritize conflicting retrieved documents is simultaneously a prompt engineering decision and a context engineering decision, you can't really cleanly separate the wording of an instruction from the information architecture it's operating inside of. I also think the essay is a bit too quick to treat the 95 percent versus 5 percent split as a settled fact rather than a widely repeated but essentially unverifiable claim, nobody's actually run a rigorous controlled study measuring that ratio across a representative sample of production systems, it's a talking point that spread because it sounds authoritative and confirms what people already suspected, not because someone measured it properly. None of this means the underlying shift toward thinking carefully about retrieval, memory and tool design is wrong, that part is genuinely well argued and matches what I've seen change in how teams actually structure their work over the last year, I just think the essay could be a little more skeptical about how tidy and quantified the framing has become considering how recently the term itself was coined.