Prompt engineering

Prompt engineering: design a contract for reliable behavior.

A prompt is not a magical phrase. It is an interface between an objective, the context available to the model, and an output another person or system can use. Study the interface, then test it under realistic conditions.

From request to specification

“Summarise this document” leaves important decisions unanswered: for whom, at what depth, with which facts preserved, in what format, and what should happen when the source is incomplete? Architecture questions often distinguish a convenient prompt from one that makes these conditions explicit.

The right level of detail is not “as much as possible.” It is enough detail to make the desired behavior observable and repeatable. If a reviewer cannot tell whether an answer succeeded, the prompt has not defined a useful contract.

Five building blocks of a robust prompt

Outcome

State the job to be done and what a successful answer enables. A concrete outcome gives the model a target beyond a vague topic label.

Context

Include the facts, constraints, audience, and source boundaries that materially change the answer. Remove context that is merely adjacent or distracting.

Contract

Specify the expected structure, fields, decision criteria, and failure behavior. An output format should be easy for a person or program to verify.

Examples

Use examples to demonstrate the behavior you want, not to accidentally introduce exceptions or conflicting style rules.

Evaluation

Test prompts against representative success cases and edge cases. Improve the instruction from observed failure modes rather than intuition alone.

Structured output is a product boundary

When another system consumes a model response, the output needs a contract just as an API does. Define required fields, valid values, and what should be returned when evidence is unavailable. Then validate the response where it crosses into deterministic software.

A format instruction alone does not replace validation. The stronger design pairs a clear model-facing schema with application-side handling for malformed, missing, or uncertain results.

How to review a prompt scenario

  1. Identify the actual decision the model must make, not just the final wording.
  2. Separate trusted instructions from untrusted input or retrieved material.
  3. Check whether success can be evaluated from the requested output.
  4. Choose the design that reduces ambiguity without giving the model unnecessary authority.

Primary sources to verify

Practise the decision, not the buzzword.

Use original scenarios to choose the clearest, safest, and most testable instruction design.

Practise prompt engineering questions →