Two intimidating terms for one ordinary question: are you going to describe what you want, or show it?
Someone I work with spent twenty minutes writing tone-of-voice instructions for a set of product descriptions. Warm but not casual. Confident without overselling. Specific, concrete, never breathless. Three careful paragraphs, and the output still didn't sound like the brand.
Then she deleted all of it and pasted in two descriptions she'd written herself, with one line: "match the voice of these." The next attempt was close enough to edit.
That's the whole subject. Zero-shot means you asked without examples. Few-shot means you included a handful. The names come from research papers and they make a simple choice sound like a technique you have to learn, which it isn't.
What's worth learning is when each one wins — and what examples quietly teach that you didn't intend.
The test: can you name it, or only recognize it?
Description works when the thing you want has a name. Under 100 words. Formal. A table with four columns. Second person. These are all nameable constraints, and once named they're precise — no example needed, and an example would only take up space.
Examples work when you can recognize the thing instantly but can't say what it is. House style. The difference between your writing and writing that sounds like you. The particular way your team formats a bug report. You know it when you see it, and every attempt to write the rule down loses something.
So the question isn't which technique is better. It's whether you're dealing with something nameable. If you catch yourself writing a third paragraph of description, stop — that's the signal that description isn't the right tool, not that you need more of it.
Two or three examples, not eight
The returns fall off fast. The first example does most of the work: it establishes the shape. The second shows what varies between instances, which is the part a single example can't convey. The third confirms the pattern.
Beyond that you're mostly spending space and adding risk. A long chain of examples starts to dilute the actual instruction — the same problem that makes long prompts fail — and it makes the model more likely to copy surface features you didn't care about.
Two well-chosen examples beat six lazy ones. If you're reaching for a seventh, the problem usually isn't quantity: your examples are too similar to each other to show what actually varies.
What your examples teach without meaning to
This is the part nobody warns you about, and it's where few-shot prompting actually goes wrong.
A model takes the whole example as the pattern, not just the dimension you had in mind. Show three product descriptions that all happen to be four sentences long, and you have taught it a length. Show three that all open with a question, and you have taught it an opening. Show three from your best-selling products, and you may have taught it a price bracket.
The practical rule is to vary everything except the thing you're demonstrating. If the examples are there to show voice, make them different lengths, different structures, different subjects. Anything they share, the model will read as deliberate.
A related trap: examples of the wrong difficulty. Three easy cases teach the model that the task is easy, and it will handle your hard case with the same light touch. Include one awkward example on purpose.
The third option nobody names: show a bad one
Everyone shows examples of what they want. Almost nobody shows an example of what they don't — and it is frequently the faster correction.
If the output keeps drifting somewhere specific, paste the drifted version and label it: "this is what I don't want, and here's why." One near-miss annotated with the reason usually does more than three good examples, because it isolates the exact dimension that's going wrong instead of hoping the model infers it from what's present.
It works especially well for failures that are hard to describe — the version that's technically correct and somehow lifeless, the one that reads like a press release. You can't reliably name those. You can point at one.
One caution: label it, and keep it adjacent. An unlabeled bad example sitting among good ones is just another example, and the model will average the lot. "Do not write like this, because it does X" has to be explicit, or you've taught the opposite of what you meant.
Before and after
Description doing a job it can't do:
Write a product description in our brand voice: warm but not casual, confident without overselling, specific and concrete, never breathless. Around 60 words.
The same request with two examples instead:
Here are two descriptions we've published. Match their voice — not their structure or length, which vary on purpose. Write a third for the product described below, around 60 words.
[example 1]
[example 2]
Note what stayed: "around 60 words" is still a description, because length is nameable and an example is a poor way to teach it. The parenthesis about structure and length is doing real work too — it tells the model which shared features to ignore.
Mixing the two is normal. Name what's nameable, show what isn't.
When examples hurt
Three situations where the honest answer is to leave the examples out entirely, even though showing usually wins.
You want range and you've shown a groove. Asking for ten ideas after three examples gets you ten variations on those three. If the goal is breadth, describe the territory and leave the examples out.
The examples are stale. A template with examples from last year keeps producing last year's work long after the house style moved on. Description ages more gracefully than demonstration.
They're carrying something you can't see. If your examples came from one writer, one product line or one quarter, that's what gets learned — including the assumptions nobody wrote down. Worth checking before a template gets shared with a team.
The short version
Describe what has a name; show what doesn't. Two or three examples is the whole range — and vary everything about them except the one dimension you're trying to demonstrate.
And when you find yourself on a third paragraph of tone-of-voice instructions, that's the signal. Paste two things you'd be happy to receive and write one line instead.