16 articles
Browse guides
Prompt engineering is the practice of stating the task, audience, format, and constraints precisely enough that a model can succeed. The reliable levers are specificity, examples, explicit output format, and giving the model the context it lacks. Most ’the model can’t do this’ problems turn out to be underspecified prompts. In practice: Adding two example outputs cuts format errors more than any adjective ever will.
A template freezes the parts that work and parameterises the parts that change. It is the point where prompting stops being a personal trick and becomes something a team can version, test, and improve. Templates are also what make prompt evaluation possible, since you can hold the structure constant. In practice: ‘Summarise {document} for {audience} in {n} bullet points.’
Role prompting sets a perspective — ‘you are a tax adviser reviewing this for risk’ — which shifts what the model treats as relevant. It reliably changes register and emphasis. It does not add knowledge or authority: telling a model it is a lawyer does not make its output legal advice. In practice: ‘Review this as a sceptical CFO’ surfaces different objections than ‘review this’.
Structured output constrains generation to valid JSON or a supplied schema, rather than hoping a prompt produces parseable text. It is the difference between a demo and a pipeline, because it removes the whole class of ’the model added a friendly sentence before the JSON’ failures. In practice: Guaranteeing every response has invoice_number, amount, and currency, or fails loudly.
The system prompt sits above the user turn and persists across the session, defining who the assistant is and what it must and must not do. It is where product teams put voice, scope, and refusal rules. It is influential but not a security boundary — treat it as configuration, not as a control users cannot reach. In practice: ‘You are a support agent for an EU fintech. Never give financial advice. Reply in under 120 words.’ ...
Zero-shot relies on the model already knowing the task from pretraining. It works well for common tasks and degrades when the output format is unusual or the task is idiosyncratic to your business. It is the right first attempt because it is the cheapest. In practice: ‘Classify this review as positive, negative, or neutral.’