What is Prompt Engineering?

The plain definition

A language model's behaviour is governed by its input. Prompt engineering is the systematic design of that input: what to instruct, what context to supply, what examples to include, and how to constrain the output. It requires no training, costs nothing to iterate, and takes effect immediately — which is why it should always be the first thing tried.

The term attracts scepticism because a great deal of what circulates under it is superstition. The useful core is small, evidence-backed, and closer to specification writing than to incantation.

Techniques that actually hold up

Be specific about the output contract. Most disappointing results come from underspecified requests. State the format, the length, the audience, what to do with edge cases, and what to do when the answer is unknown. Supplying a JSON schema — or better, using the provider's structured-output mode — is far more reliable than asking for JSON in prose.

Few-shot examples. Two to five worked examples usually outperform any amount of abstract description, particularly for format and tone. Choose examples that cover the boundaries of the task, not just the easy centre.

Let the model work before it answers. Asking for reasoning steps before a conclusion measurably improves accuracy on multi-step problems, because the intermediate tokens function as working memory. On current reasoning-tuned models this is increasingly built in, so explicit chain-of-thought instructions matter less than they did — but structuring a hard task into stages still helps.

Decompose. One prompt doing extraction, judgement, and formatting at once will do all three unevenly. Splitting into chained calls each with a single job is easier to debug, easier to evaluate, and usually more accurate.

Give it an out. Explicitly permit 'I don't know' or 'not present in the provided context'. Without that permission, the model's objective pushes it toward producing something, which is where fabrication comes from.

Treat prompts as code

The difference between a demo and a system is discipline about change. Prompts are program logic expressed in English, and they deserve the same handling: version-controlled, reviewed, and tested. Keep an evaluation set of real inputs with expected outputs, and run every prompt change against it — otherwise a tweak that fixes one case silently breaks four others, and nobody notices until a customer does.

Two operational cautions. Prompts are coupled to model versions; behaviour shifts when a provider updates a model, so re-run evaluations on upgrade rather than assuming stability. And prompt injection is a genuine security boundary: any untrusted text that reaches the prompt — user input, retrieved documents, scraped pages, email bodies — may contain instructions the model will follow. Delimit untrusted content clearly, never grant the model authority based only on what the prompt says, and scope its tools narrowly.

Finally, know when to stop. If prompting has plateaued and you need consistency it cannot deliver, that is the signal to move to fine-tuning; if the gap is missing facts, the answer is retrieval.