Prompt engineering is the practice of designing the instructions, examples, and output constraints inside a single prompt to steer a model toward a specific result, working at the level of the immediate request rather than the surrounding context system.

How it works

Prompt engineering works the levers inside one request. Name the task explicitly and say who the output is for, and the target is set. A few well-chosen input-output examples show the shape of a good answer better than a description does. Delimiters that separate instruction from data keep the model from confusing the two. A specific output format, or room for the model to reason before it answers, shapes how the result comes back. Each move is a hypothesis about what the model needs to hear, tested by running the prompt and reading what changes, so prompt engineering is empirical rather than a fixed recipe: the same instruction can help one model and confuse another.

Why it matters

Prompt phrasing is the cheapest lever to reach for and the first one worth trying, because a clearer instruction or a couple of examples often closes the gap between a wrong answer and a right one at no infrastructure cost. The trap is treating it as the lever that decides everything. On a short task the prompt is most of what determines the result, but on a long or agentic task the system prompt, retrieved documents, prior tool results, and conversation history all compete for the model's attention, and no amount of prompt wording rescues an answer the wrong context already spoiled. So prompt engineering is necessary and bounded: it is the right tool for shaping a single response, and not enough on its own for an agent whose behavior is set by the whole window it carries.

In practice

A classification prompt keeps returning prose when the next step needs a single label. Rather than add more instruction text, the prompt is given three labeled examples and asked to answer in one word, and the output snaps to the expected shape. The change that fixed it was a worked example and a format constraint, not a longer description of the task, which is the empirical heart of prompt engineering: the prompt that works is the one that was tested, not the one that read well.

Practical considerations

Examples often carry more than instructions, so a few diverse, edge-case-covering examples usually beat another paragraph of description. Placement matters within a long prompt, since a long document tends to be used better when it sits before the question rather than after it. A prompt tuned tightly to one model is a liability across a version change, because phrasing that steered one model can land differently on the next, which is why prompt-level assumptions are worth re-checking on migration. Where the task is a single response a person or program consumes, prompt engineering is most of the job; where the task is an agent acting over many turns, it is one input to the larger discipline of engineering the whole context the model sees.

Related standards and prior art

Defined by Ready Solutions AI