Examples, and asking for the steps

This lesson teaches the last two techniques in the course. Both have published results behind them, and both get misunderstood in the same direction, which is that people take them to be doing more than they do.

Showing beats describing, for anything with a shape

Lesson 4 said the request is the specification. This is the part of the specification you cannot write in sentences.

Try describing the difference between two house styles of writing, or the tone of a particular kind of internal email, or what makes one colleague's meeting notes usable and another's not. You can get somewhere. You can't get all the way, because what you are describing is a form, and a description of a form is second-hand.

So put the form itself in front of the system. Three or four real examples of what you want, and the description you were struggling with becomes unnecessary.

This is the practical face of the finding lesson 4 opened with. The GPT-3 paper established that a task can be specified in the text of the request, with "tasks and few-shot demonstrations specified purely via text interaction with the model" and no training of any kind.¹ Tasks and demonstrations: both are things you supply as text, and the demonstrations are what this lesson is about.

Anthropic's guidance for its own models, which lesson 4 introduced and named as a vendor document, gives a working shape.² The count is in a tip: "Include 3-5 examples for best results." The criteria are a list of three, and two of them apply to anybody:

Relevant. "Mirror your actual use case closely."

Diverse. "Cover edge cases and vary enough that Claude doesn't pick up unintended patterns."

The third is about wrapping examples in XML tags, which is a thing an application developer does and a chat user does not.² The principle underneath it survives the translation: your examples have to be distinguishable from your instructions, so put them under a heading, or in quotation marks, or after a line saying "examples follow".

If your examples run straight on from your instruction with nothing separating them, some of what you meant as a sample reads as part of the brief.

Worked: a charity's volunteering descriptions

A charity has six role descriptions on its website and wants six more in the same style. Here are two of the existing six.

Befriending visitor. You'll visit one person at home for an hour a week, usually the same person for at least six months. Most of our visitors are matched with someone within a mile of where they live. You'd be working alongside Priya, who has coordinated the scheme since 2019.

Minibus driver, Thursdays. You will collect six people from home and bring them to the lunch club, then take them back at two. A D1 entitlement is needed and we will pay for it if you don't have one. You'd be driving with Tom, who has done the Thursday run for eleven years.

Now the two attempts.

Described. "Write it in a warm, practical style, about forty words, focusing on what the volunteer actually does rather than on how worthy it is." What comes back is usually decent and reads like a charity website rather than like this charity's website.

Shown. The same request with four of the existing six pasted in, marked off as examples, chosen so they cover four different kinds of role rather than four similar ones. Now look at what the two examples above actually share, because it is what the second attempt will pick up: both open with "You'll" and a concrete action; both give a time commitment in the first two lines; both end by naming the person the volunteer would be working alongside, with how long that person has been there.

Nobody would have written that third one as an instruction, because nobody had noticed it. It was in the examples anyway, and that is what this technique is for.

Asking for the steps

In 2022 a team published a result that surprised people. They put a handful of worked examples into a request, each showing not only an answer but the intermediate steps that reached it, and measured what happened on problems requiring several stages of work. Their headline sentence: "prompting a 540B-parameter language model with just eight chain of thought exemplars achieves state of the art accuracy on the GSM8K benchmark of math word problems, surpassing even finetuned GPT-3 with a verifier".³

That is a real, measured result and it deserves its reputation. It also deserves its scope, which the paper states and most summaries drop. It is a 2022 measurement. It is one model, identified in the abstract by its size and not by its name, so this course cannot tell you which model it was. It is grade-school maths word problems. And the paper's own framing is that these abilities "emerge naturally in sufficiently large language models", which makes it a result about scale as much as about wording.³

So the claim you can carry is this one, with its scope attached: on problems with several stages, asking for the steps changed the measured answer rather than only its presentation. Whether that holds for your task on your product in this year is a question nobody has answered for you, and lesson 3's advice applies: one run tells you very little.

What the steps actually are

The standards body's profile says it, and it is worth having from there rather than from a critic or a vendor.

Answers "may also include confabulated logic or citations that purport to justify or explain the system's answer", and models "sometimes provide logical steps for how they arrived at an answer even when the answer itself is incorrect".⁴ The emphasis on that last clause is mine; the words are theirs.

The steps are output. They are produced the same way the answer is, by the same process, from the same model, and they aren't a transcript of something that happened elsewhere and was then written down.

That has two consequences, pointing in opposite directions.

The uncomfortable one. Printed steps are not proof. A neat chain of five stages, each phrased confidently, is five more pieces of produced text, and the conclusion at the bottom can fail to follow from any of them.

The useful one, and it is the reason to ask anyway. Steps you can read are steps you can check. An answer with no working gives you one thing to take or leave. An answer with five steps gives you six places to look, and finding the one that does not follow is far easier than producing the whole thing yourself.

So the steps aren't evidence. They're a handle.

Worked: the costing with the correct steps

A finance officer asks for the total cost of a three-year contract. The base year is £14,400 and there is a 3% uplift each year from year two.

What comes back:

Year 1: £14,400 Year 2: £14,400 × 1.03 = £14,832 Year 3: £14,832 × 1.03 = £15,277 Total: £58,909

She checks the arithmetic in each line. Year two is right. Year three is right, to the pound. The uplift has been applied in the right years and compounded rather than repeated, which is the thing she was most worried about.

The total is wrong. The three years come to £44,509. The figure given is that plus another £14,400: year one has been counted twice.

Nothing in checking the steps catches that, because the error is not inside a step. It's at the seam, between the steps and the conclusion, and a column of correct arithmetic is persuasive enough that most readers stop before they reach it.

Three checks, in the order that costs least

The costing case needs three separate readings, and they are not the same reading done three times.

One. Do the steps agree with the question? Three years, 3%, applied from year two. If a step has misread the brief, everything after it answers a different question correctly, and no amount of checking the arithmetic will show it.

Two. Is each step right in itself? This is the one the finance officer did. It is worth doing and it is not sufficient.

Three. Does the conclusion follow from the steps? Add them up yourself. Ten seconds, and it is the check that catches her case, and it is almost never done, because by the time you have read three correct steps you have decided the thing is careful.

Lesson 8 makes this into a procedure for cases where you could not have produced the answer at all. Here the point is narrower: the steps and the conclusion are separate claims, and they want separate readings.

What people get wrong

"The steps are the reasoning." They're output that describes reasoning. The standards body's sentence is the one to remember: steps appear even when the answer itself is incorrect.⁴

"If it shows its working, it is right." The finance officer's total was wrong under three correct lines. A worked answer is easier to check and is not thereby checked.

"Chain-of-thought is a magic phrase." It's a name for putting worked examples in a request, from a 2022 paper measuring 2022 models.³ What products do now is a separate question with a separate answer, and this course has read no measurement of it, so go and see whether yours produces steps unasked rather than take anybody's word for it.

"Examples are for when you cannot describe what you want." Examples beat description for anything with a form, including things you could describe. Description is second-hand.

"More examples are better." Three to five, varied.² Past that you are adding length rather than context, which lesson 4 is about, and a dozen near-identical examples teaches the wrong regularity twelve times over.

"Asking for steps always helps." It helps where there are stages to get wrong, which is what the 2022 result measured. On a rewriting job there aren't any intermediate stages, and asking for working produces a commentary on a task that did not need one.

"Examples can make an answer true." They can't, and this is the limit worth stating plainly because it is where the two halves of this lesson meet. Four perfect examples of a well-formed citation teach a system to produce well-formed citations. They teach it nothing about whether any particular one is real, which is lesson 7.

Practice

Connections

Back. Lesson 4 gave you the three things a request supplies, and examples are how you supply the form when the form will not go into words. Lesson 2 explains why the steps can be wrong while the answer's right: both are produced by the same process, and neither is a report on the other. Lesson 3 explains why one run is one draw, which is worth remembering before you conclude that steps helped or did not.

Forward. Lesson 6 takes the observation you will make in the second exercise, about which kinds of task go wrong, and turns it into a test you can apply before you start. Lesson 7 is where invented citations and confident false answers get taken properly, and where the limit at the end of the misconception list above is the whole subject. And lesson 8 turns "find the seam" into one step of a checking procedure for answers you could not have produced yourself.

Go deeper

• Wei and colleagues, "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" (2022). This course has read the abstract and not the paper, so read the abstract: four sentences, and its own statement of scope is more modest than the reputation the result has acquired.
• NIST AI 600-1, section 2.2. The passage on confabulated logic is the best short statement of why printed working is not proof.
• The Prompt Report (2024), if you want the full catalogue rather than the two techniques that follow from the mechanism. It names fifty-eight for text and forty more for other kinds of output, which is what a field looks like before it knows which of them matter. A reference, not a curriculum.

Sources

1. Tom B. Brown and colleagues, "Language Models are Few-Shot Learners", arXiv 2005.14165, 2020. Abstract read; the paper was not opened. Supports: the quoted phrase about tasks and few-shot demonstrations being specified purely via text interaction with the model.
2. Anthropic, "Prompting best practices", read on 18 September 2026, the general principles section. Read in part. A vendor's guidance for its own models, named in the body here and discussed at more length in lesson 4. Supports: the quoted count of three to five examples, the quoted Relevant and Diverse criteria, and the description of the third criterion as being about XML tags. The principle drawn from that third criterion, that examples must be distinguishable from instructions, is this course's translation of a developer instruction into something a chat user can do.
3. Jason Wei and colleagues, "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", arXiv 2201.11903, 2022. Abstract read; the paper was not opened. Supports: the quoted GSM8K result and the authors' own framing that the ability emerges in sufficiently large models. The abstract gives the model's size and not its name, which is why this lesson says the model cannot be named from this source, and the scope is 2022 models on grade-school maths word problems.
4. NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024, section 2.2. Read in part. Supports: the quoted sentences about confabulated logic and about logical steps appearing even when the answer is incorrect. Emphasis on the second is this lesson's and is marked as such in the body.