Most prompting guides introduce zero-shot and few-shot as if they're academic concepts. "Here's the definition, here's a formal example, moving on."
That framing misses why these actually matter in practice. So let me try differently: I'll explain what they are, show you exactly when each one works better, and tell you the situations where you probably want to combine them.
The Shortest Possible Explanation
Zero-shot: You describe the task and ask for output. No examples.
Few-shot: You describe the task and show the model one or more examples of what you want before asking it to do the same thing.
That's it. The difference is examples.
The name comes from the number of "shots" — demonstrations — you give the model before it has to perform. Zero shots means you're asking it to figure it out entirely from your description. Few shots means you're showing it the pattern first.
Zero-Shot: What It Is and When It Works
Zero-shot is what most people do most of the time, usually without realizing there's a name for it.
Classify the sentiment of the following review as Positive, Negative, or Neutral.
Review: "The shipping was fast but the product broke after two days."
No examples given. You just described the task and expected the model to know how to do it.
And for a lot of tasks, it works fine. Modern models have been trained on enormous amounts of text, including a huge variety of tasks. They can often infer what you want from a clear description alone.
Zero-shot is the right choice when:
-
The task is clear and common. Summarization, translation, basic classification, editing, Q&A — these are well-understood tasks the model has seen many variations of. You don't need to show it how.
-
Speed matters more than precision. Zero-shot is faster to write. If you're iterating quickly and the output is "good enough," don't over-engineer it.
-
Format doesn't matter much. If you care deeply about exact output structure, you'll need examples. If you're flexible, description alone usually works.
The Problem With Zero-Shot
Zero-shot struggles when your task is non-standard, has specific formatting requirements, or depends on nuance that's hard to put into words.
Here's a real example. Say you're classifying customer support tickets into categories, but your categories are specific to your business and don't follow an obvious logic:
Classify this support ticket:
Categories: Billing Dispute, Technical Integration, Account Access, Feature Request, Data Export, Other
Ticket: "Hi, I tried to download my transaction history but the export button isn't showing up on my dashboard."
The model might classify that as "Data Export" or "Technical Integration" — both seem plausible. If there's a specific reason you'd choose one over the other (maybe at your company, export issues always go to the data team), the model has no way to know that from the description alone.
That's where few-shot earns its keep.
Few-Shot: What It Is and When It Works
Few-shot means showing the model examples of the pattern you want before asking it to follow that pattern.
Same support ticket example, with examples:
Classify each support ticket into one of these categories:
Billing Dispute, Technical Integration, Account Access, Feature Request, Data Export, Other
Here are some examples:
Ticket: "My invoice from last month is wrong, I was charged twice."
Category: Billing Dispute
Ticket: "Your API isn't returning the right response format for our webhook."
Category: Technical Integration
Ticket: "I can't log in — it says my account doesn't exist but I definitely have one."
Category: Account Access
Ticket: "The export button isn't showing on my dashboard when I try to download my transaction history."
Category:
Now the model has seen what each category looks like in practice. The last "Category:" with no answer is where you want it to fill in.
It's going to say "Data Export" — or whatever your examples trained it to say. If your examples consistently show that export issues go to a certain bucket, the model picks that up.
When Few-Shot Wins Over Zero-Shot
Custom output formats. If you need output in a specific structure — a table, a particular JSON schema, a formatted report with specific headings — it's often faster to show one example than to describe it in words.
Format:
| Feature | Status | Owner | ETA |
| -------- | ------ | ----- | --- |
| Dark mode | In progress | Design team | Q2 |
Now format the following features in the same table:
[feature list]
Much cleaner than trying to describe every column and its expected values.
Tone and style calibration. When you want output that matches a very specific voice, one or two examples are worth a thousand words of style description.
Write a product update in the following style:
Example:
"We've been quiet for a few weeks. Here's why: we ripped out our entire notification system and rebuilt it from scratch. Annoying? Yes. Worth it? You'll see."
Now write a similar update announcing the new search feature we shipped last week.
The model gets the voice immediately. Blunt, punchy, self-aware. No lengthy style guide needed.
Reducing ambiguity. When a task has multiple valid interpretations and you care which one the model picks, examples constrain the output in ways that descriptions often can't.
The "N-Shot" Question: How Many Examples Do You Actually Need?
People sometimes overthink this. The honest answer: usually 3–5 examples is the sweet spot.
1 example (one-shot): Better than zero for format tasks. May not be enough if there's meaningful variation across your examples.
3–5 examples: Usually enough to establish a clear pattern. Enough variety to prevent over-fitting to one example's quirks.
More than 10: Rarely necessary. If you're finding you need 15 examples, the task might be ambiguous in a way that more examples won't fix. Or you might be approaching a task that needs fine-tuning rather than prompting.
The examples should be diverse enough to cover the range of inputs the model will encounter. If all your examples are easy cases, the model may struggle on hard ones.
Combining Zero-Shot and Few-Shot
You don't have to choose. A lot of effective prompts are hybrid: they describe the task (zero-shot-style) and provide examples (few-shot-style).
The classic structure:
[Task description]
Examples:
Input: [example input 1]
Output: [example output 1]
Input: [example input 2]
Output: [example output 2]
Now apply this to:
Input: [your actual input]
Output:
The description sets the rules. The examples demonstrate the rules in practice. This is often more reliable than either alone.
A Few Gotchas
Bad examples produce bad outputs. This sounds obvious but it's easy to miss in practice. If your examples are inconsistent or mediocre, the model will replicate that. The quality of your examples sets a ceiling on the quality of output.
Label order can bias results in classification. There's some evidence that whatever category appears first in your examples tends to get over-selected. If you're noticing a bias, shuffle the order of your examples.
For very long context, examples cost tokens. If you're working with API calls and watching token costs, know that few-shot prompts can get expensive when the examples are long. For high-volume tasks, it's worth benchmarking whether the few-shot gain is worth the token cost.
The Honest Summary
Zero-shot is good enough more often than you'd think. Most everyday tasks — writing, editing, summarization, Q&A — don't need examples because the models have seen every version of them already.
Reach for few-shot when:
- Your output format is specific and hard to describe
- You want to calibrate tone or style
- You're seeing inconsistent results from a zero-shot prompt
- The task has meaningful nuance that examples can convey better than words
And experiment. Whether zero-shot or few-shot works better for your specific task is something you often just have to test.
The Intermediate Track has a full lesson dedicated to few-shot prompting that goes deeper into selecting good examples and structuring multi-shot prompts effectively.