Anatomy of a Prompt That Works

The gap between a prompt that works and one that almost works

Everyone who uses AI models regularly has had the same experience: you ask for something, get a response that is fluent, confident, plausible, and not quite what you wanted. You rephrase. It gets slightly better. You rephrase again. Twenty minutes later you have something usable, and no idea which of your changes actually helped.

That loop is avoidable. The difference between a prompt that works first time and one that needs five rounds is rarely cleverness or a magic phrase — it is structure. This article covers the techniques that reliably matter, why they work, and which popular advice does not survive contact with evidence.

Be specific about the output, not just the task

The single most common failure is underspecification. A model asked a vague question will produce a reasonable answer to some interpretation of it — just not necessarily yours.

Compare:

Write about remote work.

with:

Write a 400-word section for a manager-facing internal handbook explaining how to run effective one-to-ones with remote reports. Assume the reader already manages people in person. Focus on what changes when the report is remote. Use second person. No bullet points.

The second specifies audience, length, format, register, prior knowledge, angle, and an explicit constraint. Every one of those is a decision the model would otherwise make on your behalf — and the reason the vague version needs five rounds of correction is that you are discovering those decisions one at a time and reversing them.

Front-load the specification. The things worth stating explicitly:

• Who it is for — expertise level, role, what they already know.
• What form it takes — length, structure, format, whether lists are wanted.
• What register — formal, conversational, technical.
• What to leave out — negative constraints are surprisingly effective.
• What the output is for — a draft to edit reads differently from something to be published unchanged.

Examples outperform descriptions

If you want a specific style, format, or tone, showing one or two examples is far more effective than describing what you want in adjectives. This is called few-shot prompting, and it works because an example is unambiguous where a description is not.

"Write in a friendly but professional tone" means something different to everyone. Two examples of the tone you mean settle it instantly.

This is especially powerful for structured output. Rather than describing a format in prose, show it:

Extract the product name, price, and availability from each description.

Input:  "The Aurora desk lamp, £45, currently in stock"
Output: {"name": "Aurora desk lamp", "price": 45, "currency": "GBP", "in_stock": true}

Input:  "Nimbus chair — sold out — was 120 euros"
Output: {"name": "Nimbus chair", "price": 120, "currency": "EUR", "in_stock": false}

Input:  "Zephyr bookshelf, 89 dollars, ships in 3 days"
Output:

Notice the second example deliberately includes an edge case — an out-of-stock item with a price expressed in the past tense. Choose examples that cover the boundaries of your task, not three variations of the easy case. Two to five well-chosen examples is usually the sweet spot; beyond that you get diminishing returns and a longer prompt.

Give the model room to think

For anything involving reasoning — maths, logic, multi-step analysis, debugging — asking for the answer directly performs measurably worse than asking for the reasoning first.

The mechanism is not mysterious. A model generates one token at a time, and each token is a fixed amount of computation. Demanding an answer immediately forces the entire problem to be resolved in a handful of tokens. Allowing intermediate reasoning gives the model more computation to spend, and each step conditions the next.

The practical instruction is simply to ask for it:

Work through this step by step before giving your answer.

Better still, specify what the steps are. If you know the shape of the reasoning, prescribe it:

For this bug report: (1) restate what the user expected and what happened, (2) list every component in the path between them, (3) for each, state what would have to be true for it to be the cause, (4) rank by likelihood, (5) give the single cheapest test that would distinguish the top two.

This turns an open-ended request into a procedure, which is far more reproducible across different inputs.

One caveat: for simple factual retrieval or straightforward formatting, forced step-by-step reasoning adds length without adding accuracy. Use it where the task genuinely has steps.

Assign a role — but the useful kind

"You are an expert" prompts are widely recommended and mostly overrated. Telling a model it is a world-class expert does not grant it knowledge it lacks.

What role assignment does usefully change is perspective, vocabulary, and what the model considers worth mentioning. That is genuinely valuable when it is specific:

• Weak: "You are an expert writer."
• Useful: "You are a technical editor whose job is to cut length without losing precision. You are suspicious of adverbs and of sentences that could be two sentences."

The second gives the model a concrete stance and a set of priorities. The first is flattery.

The same applies to audience framing, which is often more useful than role framing: "explain this to a competent developer who has never used this framework" shapes the output more reliably than any claim about the speaker's expertise.

Constrain the format explicitly

If you need output in a particular structure, say so precisely and show the structure. Models are good at following format instructions and bad at guessing them.

Respond only with valid JSON matching this schema, with no surrounding prose, no markdown code fences, and no explanation:
{"summary": string, "risks": string[], "confidence": "low" | "medium" | "high"}

The negative constraints matter as much as the positive one. Left unstated, a model will often wrap JSON in a code fence and add a friendly sentence before it — both of which break a parser.

For anything programmatic, also specify what to do when the task cannot be completed. Otherwise the model will improvise, and improvisation is exactly what you do not want in a pipeline:

If the input does not contain a price, set "price": null. Do not estimate or infer one.

Iterate on one variable at a time

The habit that separates people who get good at this from people who stay frustrated is treating prompting as an experiment rather than a negotiation.

When output is wrong, the instinct is to rewrite the whole prompt. Then it works, and you have learned nothing transferable — you do not know which change was responsible.

Instead:

1. Identify the specific defect. Not "it's bad" but "it used bullet points when I wanted prose" or "it invented a statistic".
2. Change one thing that addresses that defect.
3. Test on the same input.
4. Keep the change if it helped, revert it if not.

Keep the prompts that work. A prompt you have refined over six iterations is a genuine asset, and rewriting it from memory next month wastes that work. This is the reasoning behind our AI Prompts Explorer — a library of prompts written and structured for real use, each with an explanation of why it is built the way it is, so you can adapt the structure rather than copying text blindly.

Advice worth ignoring

Emotional pressure. "This is very important to my career", "I'll tip you $200", "my grandmother will die if you get this wrong". These circulated widely and produce, at best, marginal and inconsistent effects. They are not a substitute for saying what you want.

Excessive politeness or rudeness. Neither reliably improves output. Write clearly; that is the whole trick.

Magic phrases. "Take a deep breath", "you are a genius", "think outside the box". Any effect is small and unreliable compared to simply specifying the task properly.

Enormous preambles. A 500-word persona description before a two-line request buries the actual instruction. Models attend to the whole prompt, but signal-to-noise still matters — and long preambles cost tokens and latency on every single call.

A structure that generalises

For a non-trivial task, this ordering works well:

1. ROLE / STANCE      — the perspective and priorities to adopt
2. CONTEXT            — background the model needs and cannot infer
3. TASK               — what to do, stated in one clear sentence
4. CONSTRAINTS        — length, format, what to avoid, edge-case handling
5. EXAMPLES           — one or two, covering the boundaries
6. INPUT              — the actual material, clearly delimited
7. OUTPUT INSTRUCTION — restate the required format last

Two details in that ordering are deliberate. Delimiting the input clearly — with triple quotes, XML-style tags, or an obvious marker — prevents the model from confusing your instructions with the material it is meant to process, which also happens to be the main defence against prompt injection when the input comes from an untrusted source. And restating the output format at the end works because the instruction closest to the point of generation tends to have the strongest effect.

The underlying principle

Almost every technique here reduces to the same thing: a model cannot read your mind, and will fill any gap you leave with a reasonable guess.

Every unstated assumption is a decision made for you. Prompting well is mostly the discipline of noticing your own assumptions and writing them down — which is, not coincidentally, also what separates a good brief to a human colleague from a bad one.