Prompt Engineering Techniques

Zero-shot, few-shot, chain-of-thought and structured output — what each technique does, what it costs, and the failure mode that comes with it.

Techniques are tools, not a checklist

The common mistake at this level is stacking everything — a persona, six examples, “think step by step” and a JSON schema — onto a task that needed one of them. Each technique costs tokens, latency, and sometimes accuracy. Pick deliberately.

Zero-shot

Just describe the task.

Classify this review as positive, negative or neutral. Reply with one word. Review: “Delivery was late but the product quality is amazing.”

Use when the task is common and well-specified. It is the cheapest option and modern models are strong at it — start here and only escalate if results are inconsistent.

Fails when your definition of a category differs from the obvious one. The example above is genuinely ambiguous: mixed sentiment. Zero-shot cannot know whether your business counts that as neutral or negative.

Few-shot

Show examples instead of describing.

Review: “Absolutely love it!” → positive Review: “Broke after two days” → negative Review: “Arrived late, but works perfectly” → negative Review: “Delivery was late but the quality is amazing” →

That third example is doing the real work: it tells the model that in your business, a delivery complaint outweighs product praise. No amount of prose describes that as precisely.

Three failure modes worth knowing:

Distribution leakage. Examples convey the label balance as well as the format. Nine positives and one negative will skew predictions positive. Balance them, or say what the real distribution is.
Recency weighting. The last example tends to carry more influence than the first. Do not put your weirdest edge case last.
Format lock-in. The model copies surface form aggressively. If every example is one sentence, expect one-sentence answers even where more is warranted.

Rule of thumb: 3–5 examples covering your genuinely ambiguous cases beat 20 obvious ones.

Chain-of-thought

Ask for intermediate steps before the answer.

A shop has 15 apples, receives 3 boxes of 8, then sells 12. How many remain? Work through it step by step, then give the final number.

This measurably improves multi-step arithmetic and logic. The mechanism is not mysterious: each generated token conditions the next, so writing the intermediate results puts them into the context where later steps can use them. Reasoning tokens are working memory.

Where it helps: multi-step maths, logical deduction, planning, anything where step three depends on step two.

Where it does not: single-step extraction, classification, formatting. There you pay latency and tokens for nothing.

The honesty caveat

The reasoning text is not a trace of the computation. It is more generated text, produced by the same process as the answer. It correlates with better answers, which is why it works — but a model can produce impeccable-looking reasoning attached to a wrong conclusion, and it does.

Treat printed reasoning as a useful artefact for you to inspect, never as proof the answer is right.

Modern reasoning models do this internally with dedicated mechanisms rather than by instruction, which the expert tier covers. The caveat still applies.

System messages

The system message sets standing behaviour for the whole conversation: role, rules, tone, output contract.

You are a support assistant for a UK software company. Answer only from the provided documentation. If the documentation does not cover it, say so and offer to escalate. Never speculate about pricing or timelines. Reply in under 120 words.

Two things make system prompts work:

Positive instructions beat negative ones. “Reply in under 120 words” outperforms “don’t be verbose”. Describing the target is more reliable than prohibiting the miss.

Order matters for cost. The system prompt is the most stable part of a request, so it belongs at the front where caching can reuse it.

Structured output

Three levels of rigour, and the difference between them is not cosmetic:

Ask nicely. “Reply in JSON.” Mostly works; occasionally returns prose, or JSON wrapped in a code fence.
Show the shape. Include the exact schema in the prompt. Better.
Constrain the decoder. Supply a schema the model is restricted to satisfy at generation time. Malformed output becomes impossible rather than unlikely.

Only the third is safe to build on without a parsing fallback. If your code will break on bad JSON, level three is the one you want — and every major provider now offers some form of it.

Combining, in the right order

For a production classifier, a sensible stack:

System message — role, rules, output contract.
Few-shot examples — covering the genuinely ambiguous cases.
Schema-constrained output — so parsing cannot fail.
Chain-of-thought — only if the task genuinely has dependent steps.

Add one at a time and measure. Which is the entire subject of lesson 7.

Try this: Take a classification task you care about and run it three ways — zero-shot, few-shot with balanced examples, and few-shot with deliberately skewed examples. Use the same twenty inputs each time. The skewed run will show you exactly how much of the model’s answer came from your examples rather than the input.

What you'll be able to do