The problem
Every few months someone declares prompt engineering dead, and every few months a company acts on that and ships something unreliable.
Gartner said it plainly: context engineering is in, prompt engineering is out. The framing spread fast, and now I am seeing teams treat prompt design as beneath them, something the model should just handle.
I write prompts that run in production every day, for systems that process thousands of records without a human reading the output. After 4 years of that, here is what I think actually happened.
What died was real
The thing being declared dead deserved it. Around 2023 there was a genuine cottage industry in magic words. Prompt marketplaces. Threads promising that one phrase would unlock a better model. Adding "you are a world class expert" to everything.
That was never engineering. It was superstition, and the models outgrew it. Modern models do not need to be told to think step by step, and they are not fooled into competence by flattery.
If that is what you meant by prompt engineering, then yes, it is over, and good.
What replaced it is not what people think
The replacement narrative says: stop writing prompts, start engineering context. Feed the model the right information and the prompt stops mattering.
The first half is right and important. The second half is wrong in a way that costs money.
Context engineering decides what the model knows. The prompt decides what the model does with it. These are different jobs and you need both.
I can give a model perfect, fresh, well ordered context and still get useless output, because I never specified what a correct answer looks like, what to do with ambiguity, or what format the next system in the chain expects.
Better context raises the ceiling. A precise instruction is what lets you actually reach it.
What a production prompt is actually made of
This is the part that separates it from writing a good ChatGPT message. When a prompt runs 5,000 times unattended, most of it is not phrasing.
A decision boundary
The single highest value thing in most of my prompts is telling the model exactly when not to answer.
What does insufficient information look like. What should it output when it hits that. Where does it escalate. A model with no defined exit will produce a confident answer to every input, including inputs that deserved a shrug.
An output contract
If the output feeds another system, and in real automation it always does, the shape is not cosmetic. It is an interface.
Structured fields, defined enums, explicit nulls. Not "return some JSON." Return this schema, with these allowed values, and this specific token when a field is unknowable.
Failure semantics
What does the model do with a record that is half empty? With conflicting sources? With something that looks like an injection attempt in a scraped field?
You decide this at design time or the model decides it for you at 3am.
Reasoning structure
Not "think step by step." The actual steps, when the task has a known good procedure. If there is a right order to consider things in, encode the order.
Almost no personality
Style instructions are the part people spend the most time on and the part that matters least. In batch systems they are actively harmful, because heavy style guidance flattens outputs toward each other.
The honest hierarchy
If I had to rank what moves reliability in production systems, from what I have actually seen:
1. What information the model receives, and whether it is fresh and relevant
2. Whether the task is scoped small enough to be doable at all
3. Decision boundaries and failure paths
4. Output contracts
5. Reasoning structure
6. Wording and tone
Context engineering owns one and two. Prompt engineering owns three, four and five. Six is where the discourse spent five years.
So the people saying context matters more than prompts are right about the ranking and wrong to conclude that three through five are free.
Where this shows up in real work
An agent that handles a customer question, checks an order, and decides whether to refund is not a context problem alone. Somebody has to define what a refundable case is, what evidence is required, what the agent does when the order record contradicts the customer, and what it emits when it is not sure.
None of that is retrieval. All of it is instruction design. And if you get it wrong the agent will refund things it should not, confidently, at scale.
What I would tell a team right now
Stop optimizing phrasing. It has been a dead end for two years.
Start writing prompts like you are writing a specification for a junior employee who is fast, literal, has no memory, and will never ask you a clarifying question. Because that is precisely what you have.
The name of the discipline changed. The work of specifying behavior precisely did not go anywhere, and the systems that skip it are the ones failing in production right now.
This is most of what I do day to day, alongside the context side of the same problem. If you have a system where the model is technically working and the outputs are still wrong, that is usually specification, not retrieval.