Reasoning prompts: making the model show its work

"Let's think step by step" is the most famous sentence in prompting. It went round the world because on the models of a few years ago it produced a real, measurable jump in accuracy on multi-step problems. It is also, on the models most people use today, frequently redundant — and occasionally a way to make an answer slower and no better. Both things are true, and knowing which situation you are in is the whole skill.

What chain-of-thought actually does

A model produces its answer one token at a time, and each token it has already produced becomes context for the next. When you force it to write out intermediate steps before the final answer, those steps become part of the context the answer is generated from. The model is, in effect, allowed to do the arithmetic on paper instead of in its head.

For a problem that genuinely has intermediate steps — a calculation, a chain of logic, a case analysis — this helps, because a wrong final answer often traces to a step that was skipped. Writing the steps out makes skipping harder. For a problem with no intermediate steps — "what is the sentiment of this sentence" — there is nothing to show, and "think step by step" just produces a paragraph of throat-clearing before the one-word answer you wanted.

Ask for the structure, not the ritual

The weak version of this technique is the bare incantation: appending "think step by step" and hoping. The strong version names the steps you actually want, in the order you want them, and puts the verdict last:

Work out whether the discount logic below is correct, then give a verdict.

### Context
This runs at checkout. Correct means the final price is never negative, and the single largest eligible discount is applied rather than the first one matched.

### Requirements
- First, list each discount rule and the condition under which it applies.
- Then trace one worked example: a 40-unit cart where both a 50%-off and a 30-off coupon are eligible.
- Only after the trace, state a one-line verdict — correct, or the exact case that breaks it.
- Output format: Three sections, in this order — Rules, Worked example, Verdict.

### Code
"""
price = cart - max(cart * 0.5, 30)
"""

Two things make this work. First, the verdict comes after the reasoning, not before. If you ask for the answer first and the justification second, the model commits to an answer and then rationalises it — the reasoning is decorative, and a wrong answer stays wrong. Order matters because generation is sequential: the model can only use reasoning that already exists when it writes the verdict.

Second, the steps are named. "List the rules, then trace one worked example, then rule" is a structure the model can follow and you can check. A vague "explain your reasoning" gets you an unstructured ramble you then have to read in full to trust. Naming the steps is the same discipline as naming a success criterion: it gives both of you something concrete to check the work against.

Reasoning models change the calculus

The newer reasoning models — the ones that deliberate before answering — already do this internally. Telling one to "think step by step" is redundant at best; at worst you are asking it to also emit its scratch work into your output, where you now have to parse past it. With those models the useful instruction is usually the opposite: say what the final answer should look like, and let the model handle the thinking on its own.

So the question is not "should I add chain-of-thought" in the abstract. It is:

• Does the task have real intermediate steps? If not, skip it — there is nothing to show.
• Am I on a reasoning model? If so, it is likely thinking already; spend your prompt on the output shape instead.
• Do I need to see the reasoning, or just benefit from it? If you need to audit the logic — a financial check, a policy decision — ask for the steps explicitly and put the verdict last. If you only need the answer to be right, a reasoning model gets you there without cluttering the output.

When showing the work is the point

Sometimes the reasoning is not a means to a better answer — it is the deliverable. A code review that says only "this is buggy" is useless; you need the line, the input, and the failure. A verdict on a contract clause is worthless without the clause it turns on. In those cases you are not using chain-of-thought to boost accuracy, you are asking for an auditable argument, and the structure — evidence first, conclusion last — is what makes it auditable.

The example above passed every check live in your browser. Paste your own reasoning prompt into the checker and make sure the instructions around the steps are as clear as the steps you are asking for.