Context Beats Wording

Try describing the taste of a lemon to someone who has never had one. Sour, bright, a little bitter at the edge — you can write a paragraph and they still won't know it. Or you can hand them a slice, and it takes a second.

Most of the effort people put into prompting is spent describing the lemon. The highest-leverage move available is almost always the other one: put the thing itself on the desk.

Three examples beat three paragraphs of description.

Why examples land harder than instructions

This isn't a style preference; it falls out of the mechanics. Continuing a pattern is the model's only native operation. When you supply two or three worked examples, you're not explaining a rule for it to interpret — you're laying down a groove and asking it to keep going in the same direction.

The effect was documented at the moment modern models arrived: the 2020 paper that introduced GPT-3 was literally titled Language Models are Few-Shot Learners (Brown et al.), and its central finding was that showing a handful of examples inside the prompt often outperformed elaborate instructions — with no retraining, purely from what was on the desk.

An instruction like "write it concisely, in a lively but professional tone" has to be decoded into a target by a system whose notion of "lively but professional" is the average of everything ever labelled that way. Two samples of your actual writing skip the decoding entirely.

What belongs on the desk

Not "everything you have". The right test is: what would you hand a competent new hire for this specific task? That's the set.

• The source material. The text being edited, the data being analysed, the code being changed, the emails being answered. Obvious, and still the most common omission — people describe their document instead of pasting it.
• Examples of the result you want. Two or three past pieces of the same kind, ideally your own.
• A counter-example. Deeply under-used. One good sample and one bad sample define an axis, and an axis is far more informative than a point: "this one works, this one doesn't, and here's the one-line reason why."
• The facts of the situation. Who the client is, what was decided last week, which constraints are non-negotiable, what's already been tried and failed.
• The vocabulary. Project terms, product names, internal shorthand, the spelling you use. Otherwise you'll spend three rounds correcting terminology.
• The acceptance criteria. The bar from the previous article, spelled out — often best as an actual checklist the model can verify against at the end.

And when the material is genuinely large — a long report, a whole codebase, a year of notes — that's fine. Holding volume is the one thing the model does better than you.

The failure mode of examples

Examples transfer more than you intended. Give three samples that all run 200 words with a question as the first line, and you'll get 200 words starting with a question — even if what you actually wanted to copy was the tone.

So say which dimension to take: "Match the register and vocabulary of these samples. Ignore their length and structure — this one needs to be a single 400-word block."

Two related traps. Examples that are all near-identical teach the model to produce a clone; vary them if you want range. And an example containing a mistake will have that mistake reproduced faithfully — it's a groove like any other, and nobody marked it as wrong.

Show your own voice

"Write in my style" does almost nothing, because your style is not a location on the map — it's a small deviation from a very crowded average, and the model has no idea which deviation is yours.

Ten paragraphs of your actual writing does a great deal. Better still, pair it with what you don't sound like, and be concrete about the difference: "I don't use exclamation marks or rhetorical questions; I start with the conclusion; I'd rather be blunt than warm."

The same applies to a whole project. Once you've assembled a good context block — audience, vocabulary, examples, constraints — you're re-pasting it constantly. That's the point at which it should stop being a message and become a permanent fixture; article 18 is about exactly that.

Enough context, not maximum context

There's a real ceiling. Everything on the desk competes for attention, the middle of a long context is the weakest position (Lost in the Middle, from article 2), and irrelevant material actively pulls answers sideways — a stray old version of a document will get cheerfully mixed into the new one.

Working rules: relevant beats voluminous; label your blocks so the model knows what each pile is ("SOURCE ARTICLE:", "CLIENT COMMENTS:", "MY NOTES:"); and if you paste something that shouldn't be used, say what it's for ("for background only — do not copy phrasing from this").

If you're not sure whether the context is right, there's a cheap probe: ask it to summarise what it now knows about your task and what it's still missing. Gaps show up immediately, and it costs one turn.

In practice

Paste, don't describe. Every time you find yourself explaining what a document contains, stop and put the document in.

Two examples and one counter-example. State the one-line reason each is good or bad — that's what carries the rule.

Name the dimension to copy. Tone, or structure, or level of detail — and say explicitly what to ignore.

Label the piles. Long context without headers is a heap; with headers it's a desk.

Probe before a big task. "Summarise what you know about this task and what's still missing." One turn, and you find out whether the desk is set right.

Check yourself

Close the article and answer in your own words:

1. Why do examples work better than descriptions — what mechanically happens?
2. What was the finding of Language Models are Few-Shot Learners, and why is it relevant to a request you write today?
3. Which six kinds of material belong on the desk, and what's the test for what to include?
4. Why is a counter-example worth more than another good example?
5. What goes wrong when all your examples look alike, and how do you prevent it?
6. Why is "write in my style" nearly useless, and what replaces it?
7. Why isn't more context always better?

In short

• Continuing a pattern is the model's only native operation, so examples act directly while instructions have to be decoded through an average.
• Language Models are Few-Shot Learners (Brown et al., 2020): a handful of in-prompt examples often beats elaborate instruction, with no retraining.
• Put on the desk what you'd hand a new hire for this task: source material, examples of the result, a counter-example, situational facts, project vocabulary, acceptance criteria.
• Examples transfer everything at once — say which dimension to copy and what to ignore, or you'll get a clone of their length and shape.
• Ten paragraphs of your writing beats "write in my style", which points at nothing.
• Relevant beats voluminous: label the piles, mark what's background only, and remember the middle of a long context is the weakest spot.
• Three examples beat three paragraphs of description.