Few-shot prompting: when examples beat instructions

You can describe the output you want in a paragraph, or you can show one. The paragraph is slower to write, slower to read, and lossy — every adjective is a decision the model has to interpret. An example is none of those things. It fixes the structure, the tone, the field names, and the edge cases in a form the model can copy directly instead of infer.

That is what "few-shot" means: putting one or more worked examples in the prompt before you ask for the real answer. Zero-shot is the plain instruction with no example. Few-shot is the same instruction with two or three demonstrations attached. The technique is old, unglamorous, and still the single highest-return thing you can add to a prompt that produces structured output.

Why an example does what an instruction cannot

Suppose you want messages sorted into categories. You can write a paragraph explaining what each category means and hope the boundaries land where you intend. Or you can show the model where the boundaries actually are:

Classify each support message below by the user's intent.

### Categories
- refund — the user wants money back
- bug — something in the product is broken
- praise — positive feedback with no request attached

### Output format
Return JSON and nothing else: {"intent": "string"}

### Examples
Message: "The export button does nothing when I click it." → {"intent": "bug"}
Message: "Please return the duplicate charge from March." → {"intent": "refund"}
Message: "Honestly, I have not enjoyed a tool this much in years." → {"intent": "praise"}

### Requirements
- Use one of the three category names exactly, and nothing else.
- When a message contains both a complaint and a request, choose the intent the user most wants acted on.

### Message
"""
I love the new dashboard, but CSV export has been failing since Tuesday.
"""

The three example lines settle questions the category definitions leave open. Is a crash a "bug" or a "refund" if the user is angry about being charged? The examples show the intended call. Should the JSON key be intent or category? The examples show it, exactly, so the model never has to guess and never drifts. A definition tells the model what the categories mean; an example tells it what you do with the awkward cases — and the awkward cases are the only ones you were worried about.

How many examples

More is not better past a surprisingly low number. The jump that matters is from zero to one: a single example resolves more ambiguity than any amount of prose. The second and third examples earn their place only when they show something the first could not — a different category, a tricky edge case, a format variation. A fourth example that just repeats the pattern of the first three is teaching the model nothing and costing you tokens and latency.

The rule of thumb: each example should exist to demonstrate a distinct case. If you cannot say what a given example teaches that the others do not, delete it. Three well-chosen examples beat ten that all look alike — and ten near-identical examples can actively hurt, by suggesting the task is narrower than it is.

Choose examples for their edges, not their typicality

The instinct is to show the model an easy, central case. That is the wrong instinct. The easy case is the one it would have got right anyway. Spend your examples on the boundaries: the message that could plausibly go in two categories, the record with a missing field, the input that looks like it should be handled one way and must be handled another.

An example is a ruling on a hard case. Use it to rule on the cases that are actually hard.

When to reach for it — and when not to

Few-shot is at its strongest when the output is structured and the format matters: classification, extraction, data transformation, anything a machine reads next. There, one example is worth a paragraph of schema description, and the format check and the examples check both reward you for including one.

It is weakest — sometimes counterproductive — for open-ended creative writing. Show a model three example blog intros and you often get a fourth that copies their cadence and vocabulary a little too faithfully, when what you wanted was range. For those tasks, describe the constraints and give the model room, rather than a pattern to trace.

And if a single strong example does the job, stop there. The goal is never to have examples; it is to remove ambiguity. Once the ambiguity is gone, another example is just weight.

The example above passed every check live in your browser. Paste your own few-shot prompt into the checker and confirm the instructions around your examples are as clean as the examples themselves.