Zero-shot, few-shot and showing your work
Examples in a prompt beat adjectives. Learn when to switch from describing a task to demonstrating it, and how many examples actually help.
is asking for a task with no examples. is showing the model two to five worked examples first. Examples make answers far more consistent, especially their format, by more than most people expect.
Why examples beat adjectives
"Classify the sentiment" leaves many decisions open. Which labels? Upper or lower case? What about mixed or sarcastic reviews? Each open question is a chance for the model to answer differently next time. Examples settle all of them at once, including ones you didn't think of.
✗ zero-shot
"Classify the sentiment of this review: 'It arrived late but works fine.'"
→ "The sentiment is mixed — mildly negative about delivery, positive about…"
✓ few-shot
"Review: The battery died in a week.
Sentiment: negative
Review: Exactly what I needed, arrived early.
Sentiment: positive
Review: It works.
Sentiment: neutral
Review: It arrived late but works fine.
Sentiment:"
→ "neutral"The second version isn't smarter; it's more constrained. The model has seen the pattern three times, so continuing it is by far the most likely next move. That is next-token prediction, from the first lesson, working in your favor.
Under the hood — Why do examples work without any training happening?
It looks like teaching, so people assume the model is learning. It is not — no weight changes, and the examples are gone the moment the request ends.
What is happening is called . Your examples are just tokens in the input, and the model is doing what it always does: continuing the most likely pattern. In a block of text where every Review: is followed by a Sentiment: label, the obvious next thing to write is another label.
The practical consequence is that you are paying for the examples in tokens on every single call. Few-shot isn't free. Once a task is stable and runs at high volume, (which really does change the model) can work out cheaper.
Choosing examples
- Two to five is the sweet spot. Going from zero to two examples helps a lot. Going from five to twenty usually just adds cost.
- Cover the edges. Include the ambiguous case and the boring case, not three easy ones.
- Balance them. Three positive examples and one negative push the model towards "positive". Order matters too, so mix it up.
- Keep the format identical. Same labels, same separators, same casing, every time. Inconsistency in your examples becomes inconsistency in the output.
When to ask for reasoning instead
Few-shot fixes format. It doesn't fix reasoning. For multi-step problems like arithmetic or logic puzzles, ask the model to work through it step by step before answering. This is called . It helps because each step the model writes becomes input for the next one.
The cost is more tokens and a slower reply. The catch is that your code then has to dig the final answer out of a long block of reasoning. The structured output lesson shows how to solve that.
Key takeaways
- Two to five examples fix format and consistency far better than describing what you want.
- Keep examples balanced and identically formatted, and end the prompt where the answer should go.
- Examples fix format, not reasoning. For multi-step problems, ask the model to work step by step.
Sign in to run the exercise
Reading is free. Writing code here needs an account so we have somewhere to keep your Gemini key and the +25 XP you are about to earn.