Stop Describing the Output — Show It Examples Instead

You described exactly what you wanted — the tone, the length, the structure — and it still came back wrong. The problem usually isn't that your description was unclear. It's that you were describing when you should have been showing. Give the model two or three concrete examples of input paired with the output you want, and it picks up the pattern faster and more reliably than any paragraph of instructions can convey it. This is few-shot prompting, and it's one of the highest-leverage, lowest-effort techniques in prompting.

Why examples beat descriptions

A written description of a format is an abstraction one step removed from the thing itself. "Keep it concise, professional, and action-oriented" is a reasonable instruction, but it leaves the model to interpret "concise" and "action-oriented" against its own defaults, which may not match yours. An example sidesteps the interpretation problem entirely — it shows the exact shape, tone, and level of detail you want, and the model matches the pattern instead of guessing at your adjectives.

This shows up clearly in tasks the model genuinely can't do from a bare instruction. Asked something like "what restaurant should I take Ania to in Dubai," a model with no information about Ania simply can't answer. Feed it a short example first — "Ania's favorite food includes burgers, fries, and pizza" — and the question becomes answerable, because the example supplied the missing data the instruction alone couldn't.

The pattern-matching case: format and tone

The clearest everyday use case is turning messy input into a consistent output format. Feed the model three examples of messy bug reports paired with the clean, one-line titles you'd write for each. The pattern — how much detail to keep, what to cut, the exact phrasing style — transfers immediately. The next messy report you hand it comes back in the same clean format automatically, without you writing a single sentence describing what "clean" means. The examples did that work.

How many examples you need

Two or three input/output pairs is usually enough for the model to lock onto a pattern for straightforward formatting or tone tasks. Reach for more examples when the task is trickier or has real edge cases — the harder the judgment call, the more examples it takes to pin down where the boundary is.

A practical trick: make at least one of your examples a tricky or edge case, not just the easy, obvious ones. Three clean examples teach the model the happy path; one example that shows how to handle the messy exception teaches it where the pattern bends. That single edge-case example often prevents more downstream corrections than an extra two ordinary ones.

How to run it

1. Pick two or three representative real inputs — not invented toy examples, actual samples of what you'll be feeding it repeatedly.
2. Write the exact output you'd want for each, in the real format and tone you're after.
3. Present them as clear pairs (input → output) before the new input you actually want handled.
4. Include one edge case if the task has any ambiguity.

Where this pays off

Anywhere tone or format matters more than raw content, few-shot examples outperform verbal instructions: support ticket triage, product descriptions, code review comments, meeting notes turned into action items. Any task where you find yourself writing "make it sound like X" or "format it the way Y does" is a task where two or three real examples of X or Y will do more work than the sentence describing them.

Power tricks

• Include one tricky edge case. It teaches the model where the pattern bends, not just the happy path.
• Pull examples from real data. Made-up examples can miss the actual quirks of your real inputs.
• Keep example formatting internally consistent. Mismatched formatting across your examples teaches an inconsistent pattern.