Examples Beat Explanations

How few-shot examples work and their traps: how many to give, which ones, and when they hurt.

One of the highest-leverage moves in prompting: instead of describing what you want with adjectives, hand over a sample that says "make it like this." In the trade it's called few-shot prompting. OpenAI's prompt engineering docs list a few input-output examples in the prompt as one of the most effective techniques. openai-prompt

Signs you'll recognize:

• You write "professional, concise, friendly" and the output still misses the mark.
• Your prompt keeps growing as you try to describe the style, and the results get vaguer.
• You can tell at a glance which output is right, but you can't put the standard into words.

Why examples work so well

Because adjectives are compressed information, and everyone decompresses them differently.

What does "professional" mean? Industry jargon or not? Long or short sentences? Address the customer by name? Apologize when something goes wrong? When you say "professional," you have a specific picture in your head—but that picture never travels. The model falls back on whatever phrasing usually surrounds the word "professional" in its corpus. It takes the average.

One example is different. An input-output pair carries sentence length, how to address the reader, leading with a conclusion or with empathy, the wording of an apology, whether to promise a timeline—every implicit requirement, delivered at once, with no ambiguity.

There's a mechanism-level reason too. The model's job is to continue existing text. Seeing "input A → output A', input B → output B'" and then "input C →," the natural continuation is an output aligned with that pattern. You're not teaching it; you're handing it a pattern to fill in. Anthropic's docs put clear examples among the most basic techniques as well. anthropic-prompt

How many, and which ones

Two to five examples is the sweet spot for most tasks.

One example is usually not enough—the model can't tell which features are mandatory and which are coincidences. After two or three the pattern emerges. Beyond that, returns drop fast, and every example is resent on every request, so the cost is real.

Which examples you pick matters more than how many. Three rules:

One: cover different cases, not one type. If every example is simple, the model freezes on complex input. Pick one typical, one moderately hard, one edge case.

Two: include how to handle "I don't know." This pays off disproportionately. An example mapping "no relevant info → output: not mentioned in the material" beats writing "don't fabricate" ten times. It's the most practical anti-hallucination move there is.

Three: examples must be correct. Sounds obvious, but many teams scribble examples by hand with inconsistent formatting or outright errors. The model faithfully learns the error.

For formatting, separate examples from instructions structurally and mark each input-output pair, so the model never guesses which lines are examples.

Three traps

Trap one: example bias gets amplified. The most common mistake. If all three of your examples are two sentences long, it will never write three again, even when the input clearly needs more room. If all your examples are negative feedback, it may answer positive feedback in the same negative tone. The model can't tell which features you chose deliberately and which are accidents, so keep diversity on purpose—in length, tone, and where the conclusion lands.

Trap two: order and ratio effects in classification. Four class-A examples and one class-B example make the model quietly lean toward A. Order matters too, especially the last one. Balance the counts and shuffle; don't group similar ones together.

Trap three: examples harden into a block nobody dares touch. More examples, longer prompt. Six months later a rule change contradicts an example, and no one remembers why it exists. Annotate each example with the issue it was added to prevent.

When not to give examples

Examples are great, but not every situation wants them.

One: the task is already standard. Translation and grammar correction are tasks the model has seen more samples of than you could ever provide. Examples won't help; they just burn tokens.

Two: you want variety. For creative divergence and brainstorming, examples box the model in—it drifts toward your samples. Give fewer examples and raise the temperature instead.

Three: the format can be hard-constrained. For a fixed JSON structure, schema-enforced output is more reliable and cheaper than stuffing examples. Use examples for style and judgment, not format.

One last rule: examples should come from real data, not something you invent. Pull actual user inputs and pair them with answers you'd stand behind. That guarantees authenticity and doubles as your iteration test set—the two should be the same thing.