Prompt engineering did not die. Its ceiling moved, and the real gains shifted to what you load into the context window at all.
Higlights
- Prompt engineering is the practice of writing instructions that get reliable output from a language model, and it mattered enormously in 2023 because models were easily derailed by ambiguity.
- Frontier models handle vague requests far better than they used to, so the gap that clever wording exploited has narrowed considerably.
- Five techniques still earn their keep, and all five are about supplying information the model cannot have rather than about phrasing tricks.
- Context engineering became the mainstream term in June 2025, after Shopify's Tobi Lütke and Andrej Karpathy endorsed it within a week of each other.
- Karpathy's framing is worth keeping, since it treats the model as a processor and the context window as its working memory.
- Bigger context windows made discipline more important rather than less, because accuracy degrades well before the stated limit is reached.
- Prompts should be evaluated against a fixed set of real cases, since tuning by impression is how teams convince themselves that a change helped.
Most prompt engineering advice you will find was written for models that no longer exist. In 2023, rewriting a request carefully could lift an answer from unusable to good, because models of that era lost their footing on anything ambiguous and needed the scaffolding. Frontier models in 2026 handle a vaguely worded request perfectly well, which means a large share of the tricks that once felt essential now do very little.
That does not make the discipline worthless. It moves where the value sits. The techniques that survived are the ones supplying information the model could not otherwise have, and the term that describes that work has changed too. This guide starts with the basics, separates what still helps from what stopped mattering, and then covers context engineering, which is what the job became.
What prompt engineering is
Prompt engineering is the practice of writing the instructions, examples, and constraints you send to a language model so that it produces useful and repeatable output, without changing the model itself in any way.
The last clause matters. Nothing about the model changes. You are choosing what it reads before it answers, which is why the discipline is closer to writing a good ticket than to programming.
Why it worked so well, and what changed
Early models were capable and brittle. Ask vaguely and you got something vaguely relevant. Ask precisely, supply an example, name the format, and the same model produced something usable. That gap between a lazy request and a careful one was enormous, and prompt engineering existed to exploit it.
Three things narrowed that gap. Models became substantially better at inferring intent from an underspecified request. Instruction tuning made them follow directions without being coaxed. And reasoning capability moved inside the model, so asking it to think step by step, once a genuinely powerful technique, now often duplicates something the model already does.
Did you know
The phrase think step by step became famous because it worked so well. Adding it to a prompt measurably improved results on multi step problems, and it spread through the industry as close to a magic incantation. On current reasoning models it frequently changes nothing at all, because the model already reasons before answering. The technique was never magic, it was compensating for a limitation that has since been engineered away. That is the pattern to watch for whenever you meet a prompting tip: ask what limitation it was working around, then ask whether that limitation still exists.
The five techniques that still earn their keep
Notice what these have in common. Every one supplies something the model genuinely cannot know, rather than trying to phrase a request more cleverly.
The first is the one beginners skip most often and the one that fixes the most bad answers. A request to write a deployment manifest produces something generic. The same request stating your Kubernetes version, your ingress controller, your naming convention, and your resource limits produces something you can almost use.
Equally underrated is the final row. Left unspecified, a model produces its best guess with complete confidence, and you cannot tell that guess apart from knowledge. Instructing it to say when the information is insufficient converts a silent failure into a visible one.
Quick tip
When an answer is wrong, resist retrying the same prompt hoping for better luck. Work out which of four causes applies: the model lacked context you could have supplied, the request was ambiguous about scope or format, the task needs exact recall the model cannot have, or the temperature is high enough that you are sampling noise. Each has a different fix, and rerolling addresses none of them. This one habit saves more time than any prompt template.
What quietly stopped mattering
Being specific here is more useful than being diplomatic, because a lot of circulating advice is cargo cult.
Elaborate role assignment. Telling a model it is a senior engineer with twenty years of experience made a real difference once. Now it mostly adds tokens. Naming a perspective still helps when the perspective genuinely changes the answer, such as asking for a security review rather than a readability review, but the biographical detail does nothing.
Politeness, threats, and offers of payment. These circulated widely as ways to improve output. They are noise. Write clearly because clear writing is easier for you to maintain, not because the model responds to courtesy.
Chain of thought on reasoning models. Still valuable on smaller and faster models, and largely redundant on models that reason by default.
Long preambles about importance. Telling a model that a task is critical and that careers depend on it consumes context without changing behaviour.
Watch out
Prompt templates copied from a blog post are the most common source of wasted tokens on a team. They accumulate role play, emphasis, and phrasing that was tuned against a model from two generations ago, and nobody removes any of it because nobody knows which part is load bearing. If you inherit a long system prompt, strip it back to instructions, format, and constraints, then measure. Most of the time the shorter version performs the same or better, and it costs less on every single call.
Enter context engineering
Here is the shift that gave the discipline a new name.
Prompt engineering asks how to phrase a request. Context engineering asks what the model needs to see in order to answer it. That includes your system instructions, retrieved documents, conversation history, tool outputs, and the user's actual question, all competing for the same finite space.
The term went mainstream in June 2025. Shopify's Tobi Lütke posted that he preferred it to prompt engineering, describing it as providing all the context needed for the task to be solvable at all. Andrej Karpathy amplified it days later, describing the work as choosing precisely which information belongs in the window ahead of each step, a framing he called equal parts craft and science. Gartner then put it bluntly, telling analysts to treat context as the priority and prompts as the fading concern.
Karpathy's accompanying analogy is the one worth keeping. The model is a processor, the context window is its working memory, and your job is deciding what gets loaded before each call. A fast processor given the wrong data still produces wrong answers.
Did you know
The rename is not a rejection of the old techniques. Anthropic's framing separates them cleanly: prompt engineering covers writing and organising instructions, while context engineering covers curating the whole set of tokens the model sees during inference. Instructions are one input among several. What changed is that in a single question and answer exchange the prompt was almost everything, whereas in an agent running dozens of steps and accumulating tool output, the prompt is a rounding error next to everything else in the window.
The two disciplines, side by side
Holding both in view at once makes it clearer why one absorbed the other rather than replacing it.
The bottom row is the honest summary. Prompt engineering is a skill you can largely acquire in a sitting, then apply for years. Context engineering is a system you build and keep maintaining, because the documents change, the conversation grows, and the tools return new things every run.
Why bigger windows made this harder, not easier
The intuitive response to a million token context window is that careful management stops mattering. The evidence points the other way.
Chroma Research put eighteen leading models through a length study in July 2025. Every single one lost accuracy as the input grew, and the worst cases slid from roughly 95 percent down to about 60 percent while still nowhere near their advertised ceiling. The phenomenon acquired a name, context rot, and it means the number on the model card is a capacity rather than a working range.
That reframes a large window as rope rather than as a solution. Filling it indiscriminately produces worse answers than filling a fraction of it deliberately.
The four ways context goes wrong
Having names for the failure modes makes them diagnosable rather than mysterious.
The clash row is the one that surprises teams. A retrieval system happily returns both the current runbook and the superseded one, the model has no way to know which is authoritative, and the answer blends them. Adding a date filter fixes more of these than any amount of prompt refinement.
Learn the model and API layer underneath
Prompting makes far more sense once you have called an API yourself, watched token counts move, and seen how the system message differs from the user message. The Introduction to OpenAI course on KodeKloud covers models, prompts, and APIs from first principles, which is the layer everything in this guide sits on.
Four things you can actually do about it
The strategies have settled into four verbs, and they map onto ordinary engineering habits.
Write. Persist information outside the window so it does not have to live inside it. Notes, scratchpads, and state files let a long task carry knowledge without carrying every token.
Select. Retrieve only what is relevant, then filter by metadata such as date, version, or document type before similarity is even considered. Most retrieval quality problems are selection problems.
Compress. Summarise older turns rather than replaying them verbatim. The cost is that summarisation always discards something, so choose deliberately what survives.
Isolate. Give separate concerns separate contexts. A subtask that needs a large document does not need the main conversation, and keeping them apart stops one polluting the other.
In the wild
A team debugging a long running assistant found it contradicting decisions made earlier in the same session. The instinct was to blame the model and try a stronger one. The actual cause was compression, since their summarisation step had dropped a constraint agreed thirty turns earlier, so the model was not changing its mind, it simply could no longer see the commitment. The fix was pinning agreed decisions into a section of the context that summarisation never touched. Whenever a system seems to forget something, check what your own pipeline discarded before questioning the model.
Prompting for engineering work specifically
Four patterns cover most of what an engineer actually does with a model.
Structure the input, not just the request. Label the parts of what you paste, so an error section, a configuration section, and a question section are distinguishable. Models parse delimited input far more reliably than a wall of text, and this removes a whole class of confusion where the answer addresses the wrong part.
Define an output contract. If you will parse the response, say exactly what shape it must take and what to do when it cannot comply. A model told to return only JSON and to use a specific error object when it cannot is far easier to build on than one asked politely for JSON.
Ask for the reasoning where you will need to check it. For anything you must verify, having the model state its assumptions makes review possible. For a formatting task, it is wasted output.
Give it the failure, not the summary of the failure. Paste the actual error, the actual config, the actual version. A description of a problem is a lossy compression of the problem, and you compressed out exactly the detail that would have identified it.
CONTEXT
Kubernetes 1.31, nginx ingress controller, staging cluster.
Convention: all resources carry app and tier labels.
PROBLEM
Pod checkout-7d9f is in CrashLoopBackOff with 14 restarts.
LOGS
[paste the previous container's logs here]
MANIFEST
[paste the deployment spec here]
QUESTION
What are the three most likely causes, and what would confirm each one?
If the logs are insufficient, say what else you need.That skeleton is worth keeping as a snippet. The labelled sections stop the model guessing which block is which, the question asks for candidates and confirmations rather than a single confident answer, and the final line converts a silent guess into a visible request for more information.
Stop tuning by impression
The habit that separates teams who improve their prompts from teams who churn them is having something to measure against.
Collect ten to twenty real inputs where you know what a good answer looks like. Run them before and after any change. That is the entire method, and without it you are relying on your impression of a handful of outputs, which is exactly how a team convinces itself that a change helped when it did not.
Three things are worth measuring rather than one. Whether the answer was correct. Whether it was correct for a checkable reason rather than by luck. And whether the system said so when it genuinely could not answer, since a model that never admits uncertainty has not earned the confidence it displays.
Practise on real environments
Prompting is a hands on skill, and the difference between reading about output contracts and watching a model break one is the difference between knowing and understanding. The KodeKloud playgrounds give you environments to call models and run experiments against your own inputs.
Where to start
- Take your team's longest system prompt, strip it back to instructions, format, and constraints, and compare the results.
- Build a set of twenty real inputs with known good answers, because you cannot improve what you are not measuring.
- Add the missing context to one prompt you use often, naming your versions, conventions, and constraints explicitly.
- Add an instruction telling the model to say when it cannot answer, and check that it actually does.
- Label the sections of anything long you paste, rather than sending an undifferentiated block.
- Look at what your retrieval or summarisation step discards, since that is where most mysterious failures originate.
- Delete one prompting habit you cannot justify, such as role play biography or an appeal to importance.
Conclusion
Prompt engineering is worth learning and worth learning accurately, because a lot of what circulates is advice tuned against models that have since improved past it. The techniques that survived all do the same thing, which is supply information the model has no other way of getting: your context, your format, your constraints, an example, and permission to admit uncertainty.
Everything else moved up a level. The question stopped being how to phrase a request and became what to put in front of the model at all, which is why context engineering earned its own name and why bigger windows made the discipline more necessary rather than less.
So start with the measurement set this week. Twenty real inputs with known good answers turns prompting from a matter of taste into something you can actually improve, and it will tell you within an afternoon which of your team's habits are doing anything at all.
Ready to Build Real AI Engineering Skills?
Prompting sits on top of models, APIs, and retrieval, and understanding those layers is what turns guesswork into engineering. The Introduction to OpenAI course on KodeKloud covers models and APIs from first principles, the Fundamentals of RAG course covers the retrieval half of context engineering in depth, and the KodeKloud playgrounds give you somewhere to run every experiment here. Start with one today.
FAQs
Q1: What is prompt engineering, and is it still worth learning?
Prompt engineering is the practice of writing the instructions, examples, and constraints you send to a language model so it produces useful and repeatable output, without changing the model itself. It is still worth learning, though the reasons have shifted. In 2023 it mattered enormously because models were easily derailed by ambiguity, so careful phrasing could roughly double the quality of an answer. Current models handle vague requests far better, which means the payoff from clever wording has shrunk considerably while the payoff from supplying good information has not. What survived are the techniques that give the model something it could not otherwise have: your versions and conventions, the output format you need, one worked example, the constraints that apply, and an instruction to flag uncertainty rather than guess. Those five are worth an afternoon of practice. The elaborate role play, emphasis, and magic phrases that fill a lot of online advice are largely residue from an earlier generation of models.
Q2: What is context engineering, and how does it differ from prompt engineering?
Prompt engineering is about the instructions you write, while context engineering is about everything the model can see when it answers, including the system prompt, retrieved documents, conversation history, tool outputs, and the current question. The term went mainstream in June 2025 when Shopify's Tobi Lütke said he preferred it, and Andrej Karpathy amplified it days later, describing it as filling the context window with the right information for the next step. Anthropic's framing separates them cleanly, with prompt engineering covering how instructions are written and organised, and context engineering covering the curation of every token the model sees during inference. The distinction matters most as systems get longer running. In a single exchange the prompt is nearly everything, whereas in an agent taking dozens of steps and accumulating tool output, the prompt is a small part of what fills the window. Prompt engineering was not replaced so much as absorbed into a larger job.
Q3: What do I need to know before getting good at this?
Very little that is specialised, and none of it is mathematics. Understand what a token is, since it is the unit of both cost and context. Understand the context window as a shared budget covering your instructions, the conversation, anything you paste, and the response. Know that temperature controls how deterministic the output is and should sit near zero for engineering work. And know that the model has no knowledge of your environment unless you tell it, which is the single most useful fact in this guide. On the practical side, being able to call an HTTP API and read JSON covers the technical requirements entirely. What genuinely helps is your existing engineering judgment, because recognising a wrong answer is the skill that makes these tools safe to use. For structured practice, the Introduction to OpenAI course on KodeKloud covers models, prompts, and APIs from the ground up.
Q4: Do larger context windows mean I can stop worrying about what I send?
The opposite, and this surprises people. Chroma Research ran a length study across eighteen leading models in July 2025, and every one lost accuracy as input grew, with the worst sliding from roughly 95 percent to about 60 percent while still far short of their advertised ceiling. The effect became known as context rot, and it means the number on the model card describes capacity rather than a working range. A large window is best understood as rope, with the discipline being knowing how much of it to use. In practice, five well chosen passages usually beat fifty in arbitrary order, because relevant material gets drowned by volume and because contradictory material confuses the answer. The failure modes have useful names: poisoning when a wrong fact enters and propagates, distraction when relevant content is buried, confusion when irrelevant content pulls the answer off course, and clash when two pieces of context disagree. Filtering by date or version before retrieval fixes more real problems than any amount of prompt refinement.
Q5: Which prompting techniques are now a waste of time?
Four categories, and being blunt about them saves tokens on every call. Elaborate role assignment, meaning telling the model it is a senior engineer with decades of experience, mostly adds length, although naming a perspective still helps when it genuinely changes the answer, such as asking for a security review rather than a readability review. Politeness, threats, and offers of payment do nothing, so write clearly for your own maintainability rather than to influence the model. Chain of thought instructions remain useful on smaller and faster models and are largely redundant on models that reason by default, since you are asking for something already happening. And long preambles about how important the task is consume context without changing behaviour. The practical implication is that inherited system prompts are worth auditing, since they accumulate techniques tuned against older models and nobody removes any of it because nobody knows which part is load bearing. Strip one back to instructions, format, and constraints, then measure the difference.
Q6: How do I tell whether a change to my prompt actually helped?
By testing it against a fixed set of cases rather than by impression, which is the single habit that separates teams who improve their prompts from teams who churn them. Collect ten to twenty real inputs where you know what a good answer looks like, run them before and after any change, and compare. Without that, you are judging from a handful of outputs, which is exactly how a team convinces itself that a change helped when it did nothing. Measure three things rather than one. Whether the answer was correct, which is the obvious one. Whether it was correct for a checkable reason rather than by luck, since a lucky answer will fail on the next case. And whether the system said so when it genuinely could not answer, because a model that never admits uncertainty has not recognised the boundary of what it knows. Re run the set whenever anything changes, including the model version, since a change in this area often improves one category while quietly degrading another.
Discussion