Zero shot, few shot and chain of thought are usually taught as three separate techniques, but each of them is an arrangement of the same two raw materials. A prompt can state a rule in words, or it can supply a worked case with the answer already attached. Everything a team puts in front of a model on one call is one of those two things, plus a statement of what the reply should look like.
The distinction between a rule and a worked case is old enough to predate the field. A rule states what is true in every case and then leaves the reader to apply it, while a worked example settles one case and leaves the reader to generalise from it. Teaching has used both for as long as it has existed, and a language model responds to them differently for a reason that comes straight from the mechanism.
Choosing between the two becomes urgent the moment a prompt stops working on the awkward third of the traffic. Adding another sentence of instruction is the cheaper move and so it is the one most teams make, but adding a demonstration is more often the move that works.
The sections below separate what a written rule does well from what a worked case does well, and give a pair of prompts where the difference is visible. They then cover how many examples earn their tokens, how to specify the shape of a reply so a program can parse it, and the order the assembled parts go in.
What an instruction states and what a demonstration shows
An instruction is a rule stated in words, while a demonstration is an input with the wanted output attached to it, and the two carry different things well.
| The job | A rule written in words | A worked demonstration |
|---|---|---|
| Stating something true of every case | Strong, one line covers all of them | Weak, one case at a time |
| Settling an awkward boundary | Weak, the wording gets argued with | Strong, the label is the ruling |
| Fixing the output format | Partial, the model paraphrases the shape | Strong, the shape gets copied |
| Cost on every call | A few dozen tokens | A few hundred tokens each |
| Changing it six months later | Edit one line | Rebalance the whole set |
| Carrying a rule nobody has ever written down | Impossible until somebody writes it | Strong, the cases carry it |
The last row is the one that decides most arguments. Plenty of real tasks run on a judgement the team can recognise and has never managed to state. Date extraction from customer messages is one of them.
WEAK. Every rule stated in words, and the rules keep arriving.
Extract the delivery date from the message and return it as YYYY-MM-DD.
If the message names a weekday, resolve it against the order date. If
the message gives a range, take the later end. If the message gives a
relative date, resolve that against the order date too. If no delivery
date is present, return null. Do not guess. Use the order date as the
reference point and never as the answer.
STRONG. One sentence of instruction and four demonstrations that carry
the awkward cases.
Extract the delivery date from the message and return it as YYYY-MM-DD,
resolved against the order date. Return null when the message names no
delivery date.
Order date: 2026-03-02
Message: Can you get it here by Friday?
Answer: 2026-03-06
Order date: 2026-03-02
Message: Anywhere between the 10th and the 14th is fine.
Answer: 2026-03-14
Order date: 2026-03-02
Message: I will be in on Tuesday, though the invoice is still wrong.
Answer: 2026-03-03
Order date: 2026-03-02
Message: Please cancel the whole order.
Answer: null
The order date of 2 March 2026 is a Monday, so the first demonstration resolves Friday to the sixth and the third resolves Tuesday to the third. The weak prompt states six rules and still leaves the model to decide what counts as a delivery date in the third message, where a weekday appears next to a complaint about an invoice. The strong prompt states one rule and then rules on four cases, including that one. It also fixes the output format for free. The literal token null, the capital A on Answer and the absence of any explanation are all copied from what the model can see.
A demonstration set has one failure mode that a rule does not. The model imitates the distribution of the examples as well as their logic, so four demonstrations of which three return a date produce a model that reaches for a date. A set that covers the awkward cases has to cover the empty case in proportion too.
How many examples earn their place
An answer arrived with the technique itself. Few shot prompting was introduced in 2020 on a 175 billion parameter model, using between ten and a hundred demonstrations, bounded by a context window of 2,048 tokens in total. That ceiling was arithmetic. Examples, input and answer shared one window, and a hundred examples of any length did not fit inside it.
Windows grew by three orders of magnitude and the question came back in a different form. A paper submitted on 17 April 2024 used a million token window to push in hundreds and then thousands of demonstrations. It reported gains over the few shot setting across a wide range of tasks, and the largest of those gains came from cases where the model carried a pretraining bias the examples could override. A paper submitted on 16 September 2025 reported the opposite failure, finding that performance fell once a prompt carried too many examples and that the turning point sat in a different place for every model tested.
Those two findings are consistent, and together they say that the count is a setting with no default. The working procedure is to start at three demonstrations, chosen because the team disagreed about those three cases, then add one at a time and measure. What the measurement has to be is the subject of module five, and running this loop without one is how a prompt acquires twelve examples nobody can justify.
Specifying the shape of the answer
An answer a person reads can arrive in any shape. An answer a program parses has to arrive in one shape, and the prompt is where the shape gets stated.
WEAK
Summarise the call and return it as JSON.
STRONG
Return one JSON object and nothing else. No prose before it, no
explanation after it and no code fence around it.
Fields, all of them required.
outcome one of "resolved", "escalated", "callback_booked"
minutes integer, the call length in whole minutes
products array of product codes mentioned, uppercase, may be empty
follow_up ISO date, or null when no follow up was agreed
summary one sentence, 30 words or fewer, no personal names
A valid reply looks exactly like this.
{"outcome":"callback_booked","minutes":7,"products":["TRN200"],
"follow_up":"2026-03-09","summary":"Caller could not open the training
pack and a callback was agreed for the following Monday."}
Four separate things changed between the two.
- Enumerated values remove the case where the model invents a plausible fourth outcome such as escalated_to_billing.
- Stated types remove the case where minutes arrives as the string "seven" and the parser raises on it.
- An explicit instruction about code fences removes the single most common parse failure in production.
- A worked reply settles quoting, key order and the exact spelling of null, because a demonstration of the output is still a demonstration.
Only the first two of those four would survive a reviewer asking what the prompt is for. The other two exist because a program on the far side of the call has to parse the reply without a person in the loop.
That prompt makes valid output very likely. It does not make it certain, and the failures are silent, since a reply with an extra sentence in front of the brace is a parse error at the boundary and never a wrong answer the model apologises for. Asking in the prompt is the weakest of the three ways to get structure out of a model, and the two stronger ones have a page of their own later in the course.
Where the examples sit in the window
Position inside the window changes how well material gets used. Research submitted on 6 July 2023 found performance highest when the relevant information sat at the start or the end of a long input. Performance fell measurably when that same information sat in the middle, and the effect held on models built for long contexts as firmly as on ordinary ones.
That finding, plus the ordinary economics of a call, settles the layout.
# The order the parts go in, and the reason for each position.
def build_prompt(policy, examples, ticket):
parts = [
SYSTEM_RULES, # stable across every call
policy, # changes with the policy version
FORMAT_SPEC, # stable
render(examples), # stable for this prompt version
f"<ticket>\n{ticket}\n</ticket>", # the only part that varies
"Answer:",
]
return "\n\n".join(parts)
Three reasons put the varying input last. It is the thing the answer is about, so it belongs in the strongest position, which is the end. It is also the thing a stranger wrote, and keeping it in one clearly fenced place at the bottom gives every downstream control something to point at. The third reason is money and shows up on page 16, since a prompt whose long prefix is byte identical from call to call can be cached, and a prompt that interleaves the customer's text with the policy cannot.
The demonstrations sit above the input and below the policy. They are stable enough to cache, they are the last thing the model reads before the real case arrives, and the case then sits in the position the 2023 finding says gets used best.
Order, instructions, examples and format are all settled by the time the call goes out. Sending that same prompt twice will still produce two different answers, which is the next thing to account for.