Prompt Engineering vs Context Engineering: The Skill That Actually Ships

Two years ago the job posting said "prompt engineer" and paid like a unicorn. The pitch was that the person who knew the magic words could make the model behave. Say "you are an expert" here, add "think step by step" there, and the output got better. For a while that was genuinely most of the game.

It is not the game anymore.

The moment you move from a chatbot you type into once to an agent that runs for twenty turns, calls tools, reads files, and remembers what happened three steps ago, the wording of your instruction stops being the thing that decides whether it works. What decides is everything else in the window: what you retrieved, what you left out, where you put it, and what you let pile up from earlier turns. That larger job got a name in 2025, and the name stuck: context engineering.

This post is about the real difference between the two, why the industry pivoted so fast, and what actually changes in your day job. No hype about one killing the other. The honest version is more useful.

What each term actually means

Prompt engineering is the craft of writing the instruction. You are shaping a single block of text: the wording, the role, the format you ask for, the few examples you inline. Anthropic's own framing is narrow and clean: prompt engineering is "methods for writing and organizing LLM instructions for optimal outcomes."

Context engineering is bigger. It is the craft of deciding what goes into the model's window at all, across the whole run. Andrej Karpathy put it as "the delicate art and science of filling the context window with just the right information for the next step." The word that matters there is filling. You are not polishing one sentence. You are curating a payload: the system prompt, the retrieved documents, the tool outputs, the conversation history, the memory, the few-shot examples, and the structured state the agent carries forward.

Anthropic draws the line directly. Prompt engineering is writing instructions; context engineering is what you reach for "as we move towards engineering more capable agents that operate over multiple turns of inference and longer time horizons," where you need "strategies for managing the entire context state (system instructions, tools, Model Context Protocol (MCP), external data, message history, etc)."

So the clean mental model: the prompt is one ingredient. The context is the whole plate.

Who named it, and when

Worth getting the history right, because it is often told wrong.

The term was popularized in a tight window in mid-2025 by three people, in this order. First was Ankur Goyal, founder of Braintrust, in April 2025: "As models get more powerful, i find myself focusing more effort on context engineering, which is the task of bringing the right information (in the right format) to the LLM." Then Tobi Lutke, CEO of Shopify, on June 19: "I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." Six days later Karpathy amplified it to a much larger audience with a blunt "+1 for 'context engineering' over 'prompt engineering'."

One honest caveat. None of them coined it. The phrase shows up earlier, including from Riley Goodside back in 2023, and Cognition's team was writing about the concept before the mid-2025 wave. So call these three popularizers, not inventors. The idea is older than the hashtag.

By September 2025 Anthropic made it semi-official in its engineering guidance, and framed the relationship the way most practitioners now do: context engineering is "the natural progression of prompt engineering." Not a replacement. A progression.

Why the shift happened at all

If prompt wording was enough two years ago and is not enough now, something changed. Three things did.

Systems got agentic. A single-shot chat has one instruction and one answer. An agent has a loop. It plans, calls a tool, reads the result, decides the next step, calls another tool. Every one of those turns writes more tokens into the window. The instruction you wrote at the top is now a small fraction of what the model is reading by turn fifteen. Managing the accumulation is the job.

Retrieval and tools became normal. Most serious LLM apps now pull in external data: documentation, database rows, search results, prior tickets. Karpathy's own list of what context engineering involves reads like a system design doc, not a writing tip: "task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting." None of that is prompt wording. All of it decides the outcome.

Long context turned out to be a trap. The big context windows arrived and everyone assumed the problem was solved: just stuff everything in. It does not work that way, and there is now hard data proving it. More on that next, because it is the part that actually changes how you build.

The through-line: as models got more capable, the bottleneck moved. It stopped being "does the model understand my instruction" and became "did I put the right information in front of it, in the right place, without drowning it." Goyal said exactly this when he made the shift: "As models get more powerful, i find myself focusing more effort on context engineering."

LangChain put the relationship in one line that is worth memorizing: "prompt engineering is a subset of context engineering."

The evidence that placement and quantity beat wording

This is where it stops being opinion. Three results, all reproducible, all pointing the same way: models do not read a long context uniformly, so what you include and where you put it dominates.

Lost in the Middle (Liu et al., Stanford, TACL 2024). The foundational one. Model accuracy on long inputs follows a U-shape: high when the relevant fact sits at the very start or the very end, and it sags in the middle. Their words: performance "is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models." The brutal number: when the needed document was buried in the middle, GPT-3.5-Turbo scored lower than answering with no documents at all (the closed-book baseline of 56.1%). Adding the right document in the wrong position made it worse than adding nothing.

NoLiMa (Adobe Research + LMU Munich, ICML 2025). This one exposes why the usual "needle in a haystack" demos look so good. Standard tests let the model cheat with literal keyword matching. NoLiMa removes the lexical overlap so the model has to actually reason across the distance. Scores collapse: GPT-4o, one of the strongest tested, fell "from an almost-perfect baseline of 99.3% to 69.7%" at 32K tokens, and at that length 10 of 12 models that advertise 128K-plus windows dropped below half their short-context score. The lesson: a model surviving a keyword-match haystack test tells you little about whether it can use messy real context.

Context Rot (Chroma, July 2025). Controlled runs across 18 frontier models (Claude Opus 4, GPT-4.1, o3, Gemini 2.5 Pro, and more), holding task difficulty fixed while only the input length grew. The finding kills the comfortable assumption directly: "Large Language Models are typically presumed to process context uniformly... in practice, this assumption does not hold." Performance "grows increasingly unreliable as input length grows," and it degraded even on a trivial repeat-the-words task. Chroma sells a retrieval product, so note the incentive, but the result ships with an open replication kit and has been reproduced independently, so the conflict of interest is a footnote, not a refutation.

Anthropic has a name for the mechanism: context rot, "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases." The cause is structural, not a bug they will patch away: attention is n-squared over the window, so every token competes with every other, and models saw far more short sequences than long ones in training. Anthropic frames the window as a finite "attention budget" where "every new token introduced depletes this budget." (Fair attribution: Anthropic did not invent the phrase "context rot." It came from a Hacker News comment in June 2025, got popularized by Chroma's study, and Anthropic's own docs link back to Chroma.)

Put together, these three say the same thing in three ways. The model's use of your context is fragile and position-sensitive. So the high-leverage work is deciding what earns a spot in the window, and where it sits. That is context engineering, and no amount of instruction-wording fixes a fact that got buried in the middle of 40K tokens.

The techniques, concretely

Context engineering is not a vibe. It is a set of levers. The core discipline, in Anthropic's framing, is finding "the smallest set of high-signal tokens that maximize the likelihood of your desired outcome." Everything below serves that.

• Retrieve, do not dump (RAG). Pull in only the documents the task needs, ranked by relevance, instead of pasting the whole knowledge base. Lost in the Middle is the reason: more documents in the wrong place can drop you below using none.
• Manage the window as a budget. Treat tokens as finite with diminishing returns. Every block you add competes for attention with every other. Ask of each one: is this high-signal, or am I padding?
• Compact long histories. Anthropic calls this the first lever: "taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary." It is lossy by design, so summarize deliberately, keeping decisions and open threads, dropping resolved chatter.
• Clear spent tool results. Old tool outputs that no longer matter are pure noise burning your budget. Drop them once they have served their purpose.
• Use memory for what must survive. Persist the durable facts (goals, constraints, decisions) outside the live window so a long run does not lose them to compaction.
• Place critical facts at the edges. Start or end, never the middle. This is the single cheapest win from the research: same information, better position, higher accuracy.
• Format tool results and state for signal. Structured, compact, labeled output beats a raw dump. The model spends less budget parsing and more reasoning.
• Test on realistic retrieval, not keyword haystacks. NoLiMa's warning: if your eval lets the model keyword-match, it will look great and fail in production. Test with the lexical shortcuts removed.

Notice what is missing from that list: clever instruction phrasing. It is not that wording stopped mattering. It is that these levers move the outcome more, in the systems people actually ship.

So is prompt engineering dead?

No. That framing is clickbait, and reading Karpathy's tweet as an obituary gets it backwards.

The accurate version is subsumption. Prompt engineering is now one subskill inside context engineering. You still need to write a clear instruction, ask for the right format, and pick good few-shot examples, because a sharp prompt sitting on top of a well-built context beats a sloppy one. But that skill is now the last mile of a longer job, not the whole job. Anthropic's "natural progression" is the right word: the craft grew a layer, it did not get replaced.

What actually changes in your day-to-day:

• When the output is wrong, stop reflexively rewording the prompt first. Ask whether the needed information is even in the window, and whether it is positioned where the model will use it. The bug is more often missing or buried context than bad phrasing.
• Design the whole payload, not the sentence. Decide what to retrieve, what to compress, what to remember, what to throw away. That is the work now.
• Treat the context window as a scarce resource with a real budget, and spend it on signal.
• Build evals that reflect messy production retrieval, not tidy keyword tests that flatter the model.

The magic-words era is over, but not because the words stopped working. It is because the job got bigger. The people who do well from here are not the ones with the cleverest phrasing. They are the ones who can decide, out of everything that could go into the window, the small set that should, and put it where the model will actually read it.

Prompt engineering was never the whole skill. It was the visible tip of it. Context engineering is the rest of the iceberg, and now it has a name.

---

Md. Tausif Hossain leads engineering at DevTechGuru and runs TechnicalBind, an independent software studio. He writes about AI-assisted engineering, distributed teams, and the craft of shipping. Reach him at tausif.bd or @tausif1337.

Sources

• Ankur Goyal, tweet on context engineering (April 2025): https://x.com/ankrgyl/status/1913766591910842619
• Tobi Lutke, tweet on context engineering (June 19, 2025): https://x.com/tobi/status/1935533422589399127
• Andrej Karpathy, "+1 for context engineering" (June 25, 2025): https://x.com/karpathy/status/1937902205765607626
• Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic / Claude Cookbook, context engineering with tools: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
• LangChain, Context engineering for agents: https://www.langchain.com/blog/context-engineering-for-agents
• Liu et al., Lost in the Middle: How Language Models Use Long Contexts (TACL 2024): https://arxiv.org/abs/2307.03172
• NoLiMa: Long-Context Evaluation Beyond Literal Matching (ICML 2025): https://arxiv.org/abs/2502.05167
• Chroma, Context Rot research: https://research.trychroma.com/context-rot
• Simon Willison, Context engineering: https://simonwillison.net/2025/Jun/27/context-engineering/