# Prompt engineering is dead. I never did it. The industry spent two years hunting for magic words to whisper at the model. Now it's quietly declaring 'prompt engineering' dead and replacing it with context engineering and harness engineering. Here's the thing: those aren't new tricks — they're just engineering, the work real systems people were doing the whole time. Why the words were never the point, and what actually makes an agent work. - **Author:** Fedor Chishchin - **Published:** 2026-06-03 - **Tags:** agents, methodology, ai-native - **Source:** https://fedorthinks.com/blog/prompt-engineering-is-dead --- For about two years, the internet was full of magic spells. "Act as a senior engineer." "Take a deep breath and work through this step by step." "I'll tip you $200 for a better answer." People traded these incantations like cheat codes, as if the model were a genie and the right phrasing were the secret word that unlocked the good answer hiding inside. There was a whole job title for it: _prompt engineer_. The premise was that the skill of the AI era would be wording — finding the magic sentence. That era is ending, and it's worth understanding why, because the thing replacing it isn't a better spell. It's the realization that there was never a spell at all. ## The industry is quietly burying the term In mid-2025, Shopify's CEO Tobi Lütke [posted](https://x.com/tobi/status/1935533422589399127) what a lot of people were already feeling: > 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. Within a week Andrej Karpathy [endorsed it](https://simonwillison.net/2025/Jun/27/context-engineering/) and added the metaphor that makes it click: the LLM is the CPU, and its context window is the RAM. Your job isn't to whisper the right words — it's to load the right things into memory before the model runs. By 2026 this had hardened into the consensus skill. As one widely shared field guide put it, **wording is only about 10% of the problem.** Context engineering owns the other 90%: what information the model sees, in what form, at what moment — memory, retrieved documents, tool outputs, state, and what to _drop_ as the window fills. The reframe is correct. But notice what it actually is: the field looked at "finding magic words," decided that was never the real work, and renamed the discipline after the thing that always mattered — engineering the inputs. ## The words were never the point Here's why prompt engineering was always going to die: a prompt trick is tied to a specific model on a specific day. The clever phrasing that squeezed a better answer out of one model is useless — or actively harmful — on the next one. You were building on sand. Every model release washed your incantations away, and you went hunting for new ones. A _system_ doesn't rot like that. If the reason your agent gives a good answer is that you fed it the right facts, the right tools, and a clear task, then a better model makes it _better_, not broken. You were never relying on a magic sentence; you were relying on good inputs. Good inputs survive model upgrades. Magic sentences don't. This is the whole difference between a trick and an engineering practice. A trick is something you discover and hoard. An engineering practice is something you can reason about, test, and rely on across changes. Prompting was the former pretending to be the latter. ## What actually breaks an agent (it's not the wording) Watch a real agent fail in production and you almost never see "the prompt was phrased badly." You see something far more boring and structural. You see **context rot** — Anthropic's [engineering team](https://www.anthropic.com/engineering/harness-design-long-running-apps) describes how a model gets worse at reasoning as its context window fills with stale, noisy history. You see the agent drift off-track after fifty steps, lose the thread of the original task, call a tool with the wrong shape, or act on state that's no longer true. One analysis of enterprise AI failures traced [**65% of them to "harness defects"**](https://atlan.com/know/what-is-harness-engineering/) — context drift, schema misalignment, state degradation — not to the model and not to the prompt. There's a line from that work I keep quoting to people: **a one-percent benchmark improvement means nothing if the agent drifts off-track after fifty steps.** No prompt phrasing fixes that. It's not a wording problem. It's a systems problem — what the agent is allowed to see, hold, do, and forget over a long task. That's the layer the industry now calls **harness engineering**: the environment around the model — its tools, its memory, its constraints, its feedback loops, when to compact the context and reinject the goal. The prompt is a tiny piece of that. The harness is the rest. ## This was always just engineering Strip the new vocabulary away and look at what context engineering and harness engineering actually ask you to do: - Decide **what inputs** the system gets, from trusted sources, in a clean shape. - Manage **state** over time — what to keep, what to drop, what to persist outside the model. - Define **boundaries** — which tools, what they're allowed to do, what the contracts are. - Build **feedback loops** — checks, evals, recovery when something drifts. That's not a new AI discipline. That's _engineering_. Inputs, state, boundaries, feedback — it's the same job whether the component in the middle is a function, a service, or a language model. The model is unusual in one way (it's a non-deterministic guesser, which is why you [ground it](/work/astrolinkers)), but everything _around_ it is ordinary systems work. So when people ask what I do with prompts, the honest answer is: as little as possible. I never had a prompt-engineering phase. The work was always building the system — deterministic sources the model can't override, typed contracts at the edges, the task captured in a [spec rather than a prompt](/blog/specs-are-the-artifact), [evals so I'd know if it regressed](/blog/evals-or-it-didnt-ship). The prompt was the least interesting part, and I wanted it to stay that way. The more your result depends on exact phrasing, the more fragile it is. ## Why this is good news It's tempting to read "prompt engineering is dead" as the ground shifting under everyone again — another skill obsoleted, learn the new thing. It's the opposite. The death of prompt engineering is the AI field admitting that the durable skill was never a bag of model-specific tricks. It was engineering all along — and engineering doesn't get washed away by the next release. The reasoning you do about inputs, state, and boundaries today still holds when the model underneath gets twice as good. The magic words never worked the way people hoped. The system around the model always did. Prompt engineering isn't dead because we found better spells — it's dead because we finally admitted there was never a spell, just the engineering we should have been doing the whole time.