Few-Shot vs Zero-Shot: When Examples Actually Help
Examples are a precision tool, not a default. When few-shot prompting sharpens results, when it quietly backfires on reasoning models, and a simple rule for choosing.
Just give it an example
is the most-repeated piece of prompting advice, and it's genuinely good — right up until it isn't. Knowing when to show examples and when to hold back is one of the sharper distinctions in modern prompting, and in 2026 the answer flipped for a whole class of models. Let's clear it up.
The two approaches, defined
Zero-shot means you ask for the task with no examples. Just the instruction: Classify this review as positive, negative, or neutral.
You're relying on the model's built-in knowledge to know what you mean.
Few-shot (and its little sibling, one-shot) means you include a handful of worked examples before the real input:
Review: "Loved it, works perfectly." → positive
Review: "Broke after a day." → negative
Review: "It's fine, nothing special." → neutral
Review: "Honestly exceeded my expectations." → ?
You're teaching by demonstration instead of description. That's the whole distinction — but the interesting part is when each one wins.
When few-shot earns its keep
Examples shine when the thing you want is easier to show than to explain:
- Specific output formats. If you need a precise structure — a particular JSON shape, a custom citation style, a very specific tone — one clear example communicates it faster and more reliably than a paragraph of description. Models pay close attention to the details in examples, right down to formatting.
- Fuzzy or subjective categories. When your labels don't have crisp definitions (
on-brand
vsoff-brand,
urgent
vscan wait
), examples anchor the boundary in a way words struggle to. - Consistency across many calls. If you're running the same task thousands of times and need every output to look identical, examples lock in the pattern.
- Unusual tasks the model hasn't obviously seen. A niche transformation or a made-up format benefits from being shown once.
The rule of thumb: start with one example. Add more only if the first doesn't get you there. And make sure every example models exactly the behavior you want — the model will faithfully copy their patterns, including mistakes and quirks you didn't intend.
When examples backfire
Here's the part that surprises people. Examples aren't free, and on certain tasks they actively hurt:
- Reasoning-heavy problems on reasoning models. This is the big one. Modern reasoning models do step-by-step thinking internally. Feed them few-shot examples on a math or logic problem and you can bias them toward copying the surface steps in your examples instead of reasoning the problem through themselves — producing worse answers, not better. For these models on these tasks, less is more: state the problem clearly and let them think. (More on this in How to Prompt Reasoning Models.)
- When your examples are subtly biased. Three examples that all happen to be short, or all positive, or all in one style, quietly teach the model a pattern you didn't mean to teach. It will overfit to whatever your examples have in common.
- When they cost more than they're worth. Examples are tokens — sometimes a lot of them — added to every single call. On high-volume workloads that's real money and latency for a benefit a clear instruction might have delivered for free. (If your examples are large and static, prompt caching can blunt the cost.)
A simple decision rule
Ask one question: is this task about matching a form, or about doing reasoning?
- Matching a form — a format, a style, a fuzzy category → few-shot helps. Show the form.
- Doing reasoning — math, logic, analysis, multi-step problem-solving, especially on a reasoning model → lean zero-shot. State the problem and get out of the way.
And when you're unsure, test both. It takes five minutes to run the same task zero-shot and few-shot and compare — and the result is often not what you'd have guessed.
The takeaway
Few-shot prompting is a precision tool, not a default setting. Reach for it when you need to pin down a form the model can't infer from words alone. Skip it — or you'll pay for it — when the task is really about reasoning, where examples can crowd out the very thinking you want. The old instinct to always add examples
was built for an earlier generation of models; in 2026, the skill is knowing which situation you're in.
For where this fits in the bigger craft, see Anatomy of a Great Prompt and the full Guide to Prompt Engineering in 2026. Ready-made prompts — with examples already dialed in where they help — live in the prompt library.