Show, Don't Tell: Few-Shot Prompting

Two examples communicate more than three paragraphs of instruction. Why in-context learning works and how to build examples that carry their weight.

Describing a format is hard. Showing one is easy.

Compare a paragraph explaining how you want dates normalized against this:

Input: "next Tuesday"        → Output: RELATIVE
Input: "March 3rd"           → Output: ABSOLUTE_PARTIAL
Input: "2026-03-03"          → Output: ABSOLUTE_FULL
Input: "sometime in spring"  → Output: VAGUE

Four lines, and every ambiguity you would have had to anticipate in prose is resolved. This is few-shot prompting, and it is the highest-leverage single technique in practical prompting.

Why it works

The model is predicting what comes next. Your examples establish a pattern, and the most plausible continuation is another instance of that pattern.

You are not teaching the model anything — no parameters change, nothing persists past this request. You are constructing a context where the desired output is the obvious next thing. This is called in-context learning, and the “learning” is a metaphor: it is pattern completion within a single forward pass.

Part of the mechanism appears to involve attention heads that locate earlier occurrences of the current pattern and predict what followed last time. Your examples give those heads something to find.

The counts

Zero-shot — instructions only. Fine for common tasks with obvious output.

One-shot — a single example. Often a large jump over zero, because it pins down format completely.

Few-shot — typically two to five. The sweet spot for most work.

Many-shot — dozens. Worth it when the task has genuine edge cases, and now practical given large context windows. Returns diminish, and every example costs tokens on every request.

Going from zero to one usually helps more than going from four to eight.

Building examples that work

Cover the boundaries, not the middle. Examples should be the cases you would get wrong, not the obvious ones. If distinguishing two categories is the hard part, include the pair that sits closest to the line.

Keep format rigid. Identical structure, identical delimiters, identical spacing across every example. Inconsistency in your examples licenses inconsistency in the output.

Balance the categories. Four positive examples and one negative will skew predictions positive. Order matters too — a run of the same label at the end biases what follows.

Include the awkward cases. If input is sometimes empty, show an empty input and what to do with it. If some inputs have no valid answer, show one and show the refusal.

Match your real distribution. Examples drawn from actual data outperform invented ones, which tend to be cleaner and more uniform than reality.

Where it beats the alternatives

Format specification. Anything with a specific shape — JSON, classification labels, a particular tone.

Tasks that resist description. “Rewrite this in our house style” is nearly impossible in prose and straightforward with three before-and-after pairs.

Edge case handling. Rather than enumerating rules, show the tricky inputs and their correct treatment.

Consistency across calls. Fixed examples make output far more uniform, which matters when downstream code parses it.

Where it does not help

Adding knowledge. Examples demonstrate form, not facts. If the model does not know your product’s pricing, examples will not supply it — that needs retrieval.

Genuinely hard reasoning. For multi-step problems, examples of reasoning help — but that is chain-of-thought, where the example includes the working, not just the answer.

Very long outputs. Few-shot works best when examples are short enough to include several. For long-form generation, one example plus instructions is usually the practical limit.

Cost

Examples are tokens, on every single request. Twenty examples at 50 tokens each is 1,000 tokens of overhead per call.

Two mitigations. Put examples in a stable position at the start of the prompt so prefix caching applies. And if you have hundreds of examples and a high-volume task, that is the point where fine-tuning starts to make economic sense — it moves the pattern into the weights and removes the per-request cost.

What to remember

• Examples establish a pattern the model continues; nothing is learned or retained.
• Zero to one is the biggest jump; two to five covers most cases.
• Choose boundary cases, keep format rigid, balance labels, and include the awkward inputs.
• Excellent for format and hard-to-describe tasks; useless for supplying missing knowledge.
• Examples cost tokens per request — cache the prefix, and consider fine-tuning at high volume.

Next: Making a Model Think Step by Step