Show, Do Not Tell

One Example Beats a Paragraph of Instruction

You can spend four sentences describing the tone you want — "professional but warm, concise, no jargon, no exclamation marks, slightly informal openings" — and still get something off. Or you can paste one message you wrote yourself last month and say "match this voice". The example carries all of it at once, including the parts you could not articulate. This is usually called few-shot prompting, and it is the highest-leverage technique in this entire course. Anywhere you have a real sample of the output you want, showing it is more reliable than describing it. This is especially true for style, formatting and structure, which are exactly the things that are hard to put into words and easy to demonstrate.

• Weak: four sentences describing the tone you want
• Strong: "Match the voice of this message I wrote: [paste]"
• Examples carry the details you cannot articulate, which is most of style
• Two examples are usually enough; twenty is rarely better than three

Show the Shape, Not Just the Vibe

Examples are just as useful for structure as for tone. If you want a specific format, give one filled-in instance rather than a description of the fields. Weak: "Write a bug report with a title, steps, expected and actual behaviour, and severity." Strong: paste a real bug report you consider good, then say "write one in exactly this format for the following issue". The model will match the field order, the level of detail, the way you abbreviate, and the conventions you never thought to mention. When you have no real example, write a short fake one — even an obviously invented sample is more precise than a list of field names.

• For formats, one filled-in example beats a list of the fields you want
• Made-up examples work too — precision matters more than authenticity here
• Include an example of an edge case if edge cases are where things usually go wrong
• Say "exactly this format" explicitly, or you may get a loose interpretation

When Examples Backfire

Two failure modes are worth knowing. The first is over-copying: if all your examples share an incidental feature — every one starts with a question, every one is exactly three sentences — the model will treat that as the rule, because it cannot tell which properties you meant. Vary the examples on the dimensions that should vary. The second is contradiction: an instruction that says "keep it under 50 words" alongside an example that runs to 200 words puts the model in an impossible position, and behaviour in that situation is unpredictable. When instruction and example disagree, fix the example — it is doing more of the work anyway.

• Examples that all share an accidental trait will teach that trait as a rule
• Vary examples on the dimensions you want varied; keep them identical only where it matters
• A contradiction between your instructions and your examples produces unpredictable output
• When the two conflict, trust the example and rewrite the instruction to match

Try It Yourself

Showing beats telling, but you only feel the difference by running both against the same task. Pick something you write often — an email, an update, a product description.

Write a [thing you need] for [audience].

Match the style of this example:
---
[paste a short example whose style you like]
---