Prompt engineering is the practice of designing what a language model reads — instructions, examples, context, constraints — so that what it produces is reliably useful. The name undersells it: because a model has no settings panel, the prompt *is* the configuration surface, and the difference between a system that works and one that almost works is usually written in it. The craft exists because models are steerable but literal-minded collaborators: they do what the words make likely, not what the author meant.
A handful of techniques carry most of the weight. System prompts set standing instructions that outrank the user's turn-by-turn requests — role, rules, tone, refusals. Few-shot examples show the model the shape of a good answer instead of describing it, and remain the most reliable lever per line of effort. Chain-of-thought asks the model to reason before concluding, trading tokens for accuracy on multi-step problems. Structured output — schemas, fixed formats — turns prose into something software can consume. None of these are incantations; each works by changing what the model conditions on, which is why the productive mindset is closer to interface design than to spellcraft.
From prompts to context engineering
As systems grew from single calls into agentic loops, the discipline widened. An agent's behaviour is shaped by everything in its context window: the system prompt, yes, but also tool names and descriptions, retrieved documents, the accumulating history of steps taken. Practitioners increasingly call the whole job context engineering — deciding what the model sees at each step, in what order, with what framing. Two consequences deserve emphasis. Tool descriptions are prompts: the model chooses actions by reading them, so a vague description is a behaviour bug. And retrieved content is a prompt too, written by whoever authored the document — which is precisely how prompt injection works, and why content an agent reads must be treated as untrusted input.
The limit that matters
The sharpest thing to know about prompt engineering is what it cannot do: a prompt is advice, not a boundary. A model can be argued out of its instructions by sufficiently adversarial input, which is why no consequential control should live only in the prompt. The prompt asks; the tool surface, permissions, and runtime gates enforce. Teams that internalise this split spend their prompt effort on quality — and their engineering effort on the controls that hold when the prompt falls — instead of writing ever-sterner instructions and hoping.