What Is Prompt Engineering?

>_The skill everyone keeps burying

Every few months someone announces that prompt engineering is dead. The models got smarter, the reasoning got deeper, the agents can sort it out themselves. And every few months I watch a team file a bug that turns out to be a vague instruction, a missing constraint, or a prompt that asked for three things and got one.

I have shipped LLM features across products with very different risk tolerances, and one pattern never breaks: the quality of what comes out is capped by the precision of what goes in. That is not a quirk of weak models that better weights will quietly fix. It is what happens whenever you instruct a system in natural language, which is ambiguous by design. Prompt engineering is how you strip that ambiguity out on purpose rather than leaving it to luck.

>_A working definition

Prompt engineering is the practice of specifying a task precisely enough that a probabilistic model returns the output you want, reliably, across the inputs you actually see in production. The word that earns its keep is reliably. Anyone can charm one good answer out of a model. Getting the same quality on the thousandth call, on an input nobody anticipated, is the engineering.

The mental shift that helps most is to stop treating a prompt as a question and start treating it as a specification. A question is tuned to get an answer. A prompt is closer to a function signature written in English: it declares the inputs, the behavior, the shape of the output, and the edge cases you refuse to tolerate. The tighter the spec, the less the model has to guess, and guessing is exactly where quality leaks out.

>_The moves that actually work

Almost everything effective reduces to a small set of moves. None of them are secret, and all of them are more mundane than the phrase prompt engineering makes them sound.

• -Structure: separate the instruction, the context, and the data with clear delimiters so the model can tell a command apart from the content it is supposed to act on.
• -Examples: show two or three worked cases mapping a realistic input to the exact output you want. Demonstration beats description nearly every time.
• -Decomposition: split a hard task into ordered steps or separate calls instead of demanding one heroic leap in a single shot.
• -Role and framing: tell the model what stance to reason from, because reviewing a contract for liability directs different attention than merely summarizing it.
• -Constraints: pin the output format, the length, what to do when unsure, and what it must never do. Constraints are where reliability actually lives.

>_Structure beats cleverness

If you adopt one habit, make it structure. The failure I see most is a wall of text where the instruction, the user's data, and three afterthoughts are mashed together and the model cannot tell which is which. Put the instruction first, the data last, wrap the input in delimiters, and label the sections so nothing is load-bearing by accident.

Structure also means being ruthless about the output. A line like return a JSON object with keys status and reason and nothing else outperforms any amount of polite phrasing. When you pin the shape down, the result becomes parseable, testable, and boring in the best possible sense. Clever wording wins the demo. Structure is what survives contact with production.

>_Examples carry the load

Telling a model what you want is fine. Showing it is better. Few-shot prompting, dropping a handful of input and output pairs straight into the prompt, is the highest-leverage technique most teams still underuse. When you need a specific tone, a specific format, or a specific way to handle an awkward case, one good example encodes it more exactly than a paragraph of adjectives ever will.

The discipline is choosing examples that cover the cases you are worried about rather than the easy ones. Show the empty input, the input in the wrong language, the case where the honest answer is I don't know. Examples are how you teach the behavior you cannot quite put into words.

>_One task at a time

The other reflex worth building is decomposition. A single prompt that asks the model to extract, judge, rewrite, and format in one pass tends to do all four things at seventy percent. Break it into steps and each step gets the model's full attention, the intermediate output becomes something you can inspect, and a failure tells you which stage broke instead of leaving you to guess.

This is also where the context window earns respect. Everything you paste in competes for the model's attention, so more text is not more control. A focused prompt carrying the three facts that matter beats a bloated one carrying thirty, because the signal you need is not buried under the noise you added out of caution.

>_Agents raise the stakes, not lower them

The claim that agents make prompting obsolete has it backwards. When a model only answered questions, a weak prompt cost you one weak answer. When a model plans, calls tools, and acts across many steps, a weak prompt compounds. The system prompt becomes the operating contract. Every tool description is a prompt. Every rule about when to stop, when to ask, and when to refuse is a prompt that now has consequences out in the world.

This is the part engineering leaders miss. In an agentic system the prompt is not a UX nicety, it is control-plane logic. It sits upstream of retrieval, tool use, and orchestration, and it is usually the cheapest, fastest lever you have to change behavior without shipping new code. Which is precisely why it deserves the same rigor as code. I lay out the wider shape of that work in /resources/what-is-ai-engineering.

>_The myths worth killing

A few beliefs need to go, because they push people either to overinvest in the wrong things or to dismiss the discipline outright.

• -It is just typing politely: courtesy does nothing measurable. Precision, structure, and examples do the work.
• -Longer is better: longer is usually worse. Every irrelevant sentence is noise the model has to weigh, and a bloated prompt buries the instruction that mattered.
• -It disappears as models improve: better models raise the ceiling, they do not read your mind. The clearer your intent, the more of that ceiling you actually reach.
• -There is one perfect prompt: there is a prompt that works for your inputs, your model, and your tolerance for error. Change any of the three and the prompt changes with it.

>_Treat prompts like code

Here is the line between people who get consistent results and people who get lucky now and then: they stop editing prompts by vibes. The prompt goes into version control. They change one thing at a time. They measure the effect on a real set of inputs instead of eyeballing a single output and calling it a win.

That last point is the whole game. A prompt you cannot measure is a prompt you cannot improve. Build a small evaluation set of representative and adversarial inputs and score every change against it, the same muscle I describe in /resources/what-are-ai-evals. It is why prompting and testing are quietly collapsing into a single job.

The syntax will keep shifting as models and tools change underneath you. The discipline will not. Say what you mean, show what you want, constrain what you fear, and measure whether it worked. Get good at that, because for the foreseeable future the way you ask still decides what you get.