Topic 06

Instructions the Model Can Follow

Concept

Tessa needs promotional copy and asks the chat box for "something about our Lakeland tours." She gets five paragraphs — grammatical, pleasant, and useless. Generic brochure filler that could describe any lake on any continent. Her first instinct is that the model had an off day. The truer diagnosis: the model did exactly what she asked, and she asked for almost nothing. This chapter is about asking well, and it starts with the most fixable failure in everyday use.

A request you send a model has a name — a prompt — and writing one is a craft with learnable rules, not a talent. The first rule comes straight from Chapter 1: the model produces text that fits your request. Leave the request vague, and many things fit — so the model fills every gap you left with the most average choice. Unspecified audience? Prose addressed to everyone and no one. Unspecified length? Whatever length such texts usually are. The blandness of Tessa's five paragraphs was not a malfunction. It was vagueness, faithfully rendered.

Vague in, average out
The vague ask
Audience unspecified, length unspecified, shape unspecified. Five grammatical, pleasant paragraphs addressed to everyone and no one.
The specified ask
Three short paragraphs for past customers in their fifties, no prices, at most three bullet points. The gaps are closed, so the average has nothing to fill.

The Four Specifics That Do the Most Work

Think of briefing a capable temp on their first morning: talented, fast, and knowing nothing about your office that you do not say out loud. You would never say "do something about the invoices." You would say what, for whom, how much, in what form. The same four specifics carry most of the craft of prompting. What exactly to produce — not "something about Lakeland" but "three short paragraphs for the spring email newsletter, selling the Lakeland walking tour." For whom — "readers are past customers in their fifties and sixties who have already been on one tour with us." How long — "under 150 words total." In what shape — "a headline, then two paragraphs, then a one-line call to action."

Tessa rewrites her request with all four, and the difference is night and day: the draft mentions walking distances, gentle pacing, small groups — because "past customers in their fifties" told the model which patterns to reach for. Nothing about the model improved between the two attempts. The request stopped leaving gaps for the average to fill.

Constraints Are Welcome

Beginners often hold back conditions, feeling that a long request is an imposition. The opposite is true: the model handles restrictions well — but only stated ones. "Do not mention prices." "British spelling." "At most three bullet points." "Never promise specific weather." Each constraint closes off a family of wrong outputs before they happen. A professional's prompt often reads like a small brief: what, for whom, how long, what shape, plus three or four things not to do. That is not fussiness. That is the request carrying the information the answer needs.

One caution, so the lesson does not overshoot: specific beats long. Padding a prompt with pleasantries and repetition buries the instruction and spends window (Chapter 1's whiteboard is always filling). Every sentence in a good prompt earns its place by narrowing what fits.

One Task at a Time

A last habit, cheap and constantly useful. Tessa's colleague sends the box a single message asking it to summarize a complaint, draft a reply, and suggest three service improvements — and gets a muddle: a thin summary, a reply that half-answers, improvements copied from the summary. Three tasks tangled in one message get uneven attention, because the model is assembling one continuous text that tries to fit everything at once.

The fix takes ten seconds: split the tasks into separate messages, or — when they genuinely belong together — number them explicitly and say "answer each part separately." Numbered parts give the model a shape to fill, and each part gets its own full attention. You will recognize this as the first appearance of a theme this chapter keeps returning to: the model does its best work when your request has visible structure.

Common Confusions
  • "It should know what I mean." It knows what you wrote. Unstated intent does not exist for the model — every gap you leave is filled with the most average choice, which is where generic answers come from.
  • "Longer prompts are always better." Specific beats long. Padding buries the instruction and spends window; a good prompt is as long as its specifics require and no longer.
  • "Politeness words improve the answer." "Please" is harmless but idle — the specifics do the work. Spend your words on what, for whom, how long, what shape, and what to avoid.
  • "Asking for several things at once saves time." Tangled tasks get uneven attention. Split them, or number them and ask for separate answers — the ten extra seconds pay for themselves immediately.
Why It Matters
  • This single habit — specify the task, audience, length, and shape — upgrades most people's results more than anything else in this book. It is the 20% that delivers the 80%.
  • Every skill in the rest of the chapter — context, examples, formats, iteration — builds on a request that is already clear. Clarity is the foundation the craft stands on.

Knowledge Check

Why did "something about our Lakeland tours" produce generic filler?

  • The model's servers were overloaded and it produced a low-effort answer
  • The request left gaps, and the model filled each one with the most average choice
  • The model knows too little about small regional travel firms to write specifically
  • Short prompts are penalized by the model with lower-quality answers

Which four specifics does this page say carry most of the craft?

  • What to produce, for whom, how long, and in what shape
  • Politeness, tone, deadline, and the reason you need the text
  • Which model to use, its settings, its cost, and its speed
  • Examples, context, formatting, and repetition of key points

What does this page say about adding constraints like "do not mention prices"?

  • Avoid them — too many conditions confuse the model and it drops some
  • They are unnecessary once your main request is clear and specific enough
  • State them freely — each one prevents a family of wrong outputs before it happens
  • Save them for after the first draft, as corrections to what came back

A colleague needs a summary, a reply, and three improvement ideas from one complaint. Best approach?

  • Ask for all three in one flowing message so the complaint's context stays together
  • Split into separate messages, or number the parts and ask for separate answers
  • Ask for all three at once but tell the model to be extra careful
  • Do the summary and the three ideas yourself, and ask the model only for the reply

You got correct