Show, don’t specify

Describing the output you want in careful prose is usually worse than showing two examples of it. Models generalise from instances far more readily than from adjectives: “concise and authoritative” means very little, while two paragraphs you would have been glad to write mean a great deal.

The useful corollary is that your own past work is the best prompt material you have — provided you kept it somewhere you can find it.

That proviso is where the advice usually breaks down. Most people have written a few things they are quietly pleased with — a project update that drew no follow-up questions, a summary a colleague forwarded unchanged, a paragraph that finally said the thing — and when a similar task comes round, they describe those qualities from memory instead of fetching the originals. The description is always thinner than the work, and the model receives only the description.

What adjectives leave open

Take a request that sounds precise: summarise these meeting notes, concisely, in a professional tone. One reader pictures three bullet points. Another pictures a short paragraph with the decisions first. A third pictures a table of actions, owners and dates. Each is a fair reading of “concise” and “professional”, and each person would find the other two slightly wrong.

The adjectives were never a specification. They compress a stack of decisions into a single word — how long, how formal, what comes first, whether to hedge, whether to name people, what to leave out — and the writer, who resolves all of them instantly from experience, assumes the word carries them. A model resolves them too, just not necessarily the same way. Left to itself it tends towards the typical, which is why loosely specified output so often reads as competent and generic at once.

An example settles those decisions without naming any of them. Brown et al. (2020) used the term in-context learning for what happens next: the model is given a few demonstrations of a task as part of its input, with no change to the model itself, and carries the pattern over to a new case. Two past summaries in the house style fix length, order, register and level of detail at once — including the choices you would never have thought to mention.

What examples actually teach

It is worth being exact about what a model takes from a demonstration, because it is not always what you meant to teach. Min et al. (2022) studied classification and multiple-choice tasks across twelve models, including GPT-3, and found that randomly replacing the correct answers in the demonstrations barely hurt performance. What drove results instead was that the demonstrations showed the range of possible answers, what typical inputs looked like and the overall format of the sequence.

The finding should be read within its scope. It concerns labelling tasks, not open-ended writing, and Yoo et al. (2022) found that the importance of correct labels varies with the experimental set-up, including the size of the model. Still, the direction is useful. Demonstrations are a strong channel for shape — format, length, register, the kind of answer that belongs here — and a weaker one for what is true or required.

That suggests a division of labour. Let the examples carry the form, and let a short instruction carry the rules that must hold: which sources to use, what not to claim, who the reader is, any constraint that two instances cannot reveal. “Use only the attached notes and flag anything unresolved” does work no example can do; two good examples do work no adjective can.

How examples go wrong

Examples transmit their accidents as faithfully as their virtues. Someone running a small online shop pastes in two product descriptions they like, both for linen tablecloths, and asks for one about a stoneware jug. The new copy borrows the sentence rhythm and the three short paragraphs, which is fine, and describes the jug as “softening beautifully with every wash”, which is not. The model did what it was shown. It could not tell which features were the point and which came with the fabric.

Over-copying is the most visible failure. The others are quieter.

• Examples that are all alike. Three summaries of the same weekly check-in teach a narrower pattern than you intended, and a two-hour planning session gets squeezed into it.
• Examples that contradict the instruction. Ask for a hundred words and show two hundred and fifty, and you have set two targets with no way to choose between them.
• Examples that are not actually good. A demonstration chosen because it was to hand, rather than because you admired it, becomes the standard the output is aiming at.

Selection and order matter as well. Zhao et al. (2021) showed that on tasks such as text classification, the prompt format, the choice of demonstrations and even their order could move accuracy from near chance to near the state of the art, and traced part of this to a bias towards answers placed near the end of the prompt. The practical point is that examples are not a neutral backdrop. If the output leans too heavily on one of them, swap or reorder them before rewriting the instruction.

Placement matters too. Models have been found to use the middle of a long context less reliably than its start or end, as discussed in Lost in the middle, so keep examples beside the instruction rather than buried among pages of pasted material.

Choosing two or three

Two or three examples are often enough to fix a form, and each extra one brings surface features of its own. What matters most is how they differ. Vary them deliberately on the things you do not care about — subject, length of the source material, who was in the room — and keep them constant on the things you do. Whatever all of them share is what the model is most likely to treat as the rule.

Each example should be one you would be glad to put your name to; if you hesitate, leave it out, because a mediocre demonstration is not neutral but a target. Then add one sentence naming what to take and what to ignore — “follow the structure and tone of these; the topics are unrelated” — since the model has no other way to separate the intended pattern from the incidental one.

Consider a student drafting the literature review for a dissertation. Asking for “a critical, well-synthesised paragraph” tends to produce the familiar procession of studies, one per sentence, each summarised in turn. Two paragraphs from published reviews the student admires — one from their own field, one from a neighbouring one, both organised around a disagreement between studies rather than a sequence of them — show what synthesis looks like far better than the word does. Add an instruction to use only the five papers supplied, to mark any sentence that needs a citation and not to borrow the examples’ phrasing, and the division of labour is complete: examples for shape, instruction for rules.

Keeping your best work findable

All of this depends on having good examples to hand, which brings back the opening proviso. The best demonstrations of how you want something done are usually things you have already done — the trip itinerary a friend asked to copy, the proposal section a reviewer singled out. They sit in sent mail, old folders and superseded drafts, and finding them takes longer than describing them badly, so people describe them badly.

The remedy is structural rather than heroic. Keep good work next to the project it came from, with the sources it drew on, and mark the pieces you would reuse. An engineer who writes an incident review every few months, or a planner who files the same kind of site report each week, accumulates a small library of instances without extra effort, provided each one lands somewhere predictable. The next prompt then becomes a matter of selecting context rather than re-describing it — part of a wider shift in where the effort goes, discussed in The bottleneck moves.

This is one reason a PlansFlow project is a canvas of blocks: an earlier draft, the PDF it drew on and a note about what worked can sit side by side, and when you generate something new you choose which blocks inform it. Two good past summaries become two blocks you select, not a paragraph of adjectives you have to write.

In practice

1. 01

   Replace each adjective in your prompt with two or three examples you would be glad to have written, and keep the instruction for rules the examples cannot show.

2. 02

   Vary your examples on everything you do not care about, so the only features they share are the ones you want repeated.

3. 03

   Add one sentence naming what to take from the examples and what to ignore, such as “match the structure and tone; the topics are unrelated”.

4. 04

   Check that the examples and the instruction agree on length, format and audience before you send the prompt. If the output leans on one example, swap or reorder them before rewriting anything else.

5. 05

   When you write something good, file it next to the project and its sources, marked as reusable, so the next prompt starts with selection rather than description.