Examples beat explanations

Few-shot prompting is easy to state: two to five examples, include a hard one, keep them consistent. That is the right advice and it is where most people stop. This lesson covers the part that decides whether it works: which examples you pick. It also covers when to leave them out.

1.One example settles four things at once

Prose describing an output leaves gaps. You cannot see them, because you know what you meant. The model fills each gap with whatever is most likely, and "most likely" varies run to run.

A paragraph describes the target. An example is the target. Format, length, tone and edge-case handling get pinned together. It is also the cheapest way to transfer taste: you can spend six sentences failing to describe your house style, or show three lines of it.

Treat that as a default for shape, not a law. Section 3 covers where it flips, and the safe habit is to test it on your model.

2.Choosing them like test cases

The common mistake is picking examples the way you would pick a demo: five clean cases that show the thing working. That teaches the model that the clean case is the whole job, and it will be confidently wrong on everything else. Pick for coverage instead:

• One boring middle. The modal input, the one you see a hundred times a day. It anchors the default behaviour.
• One example per rule you care about. The empty input. The one where the honest answer is unknown. The one where the right move is to refuse. A rule with no example behind it is a suggestion.
• One near-miss. An input that looks like class A and is really class B. The boundary lives here, and nothing else teaches one as fast.

The vendor's guide (as of October 2026) asks for three to five examples, relevant and varied, wrapped in <example> tags inside an <examples> block so the model can tell them from the instructions. It also suggests asking the model to critique your set and name the gaps. That costs one call and no tokens in production.

Two more things matter more than the count. Use real inputs. Invented ones have correct punctuation, one topic and no rambling preamble, and real traffic has none of that, so pull yours from your logs. Keep them identical in format.

Every example is a vote. Five in one format is a rule; four plus one is a suggestion.

Wrong examples cost more than odd ones, because the model copies the pattern faithfully: a typo in an example output becomes a typo in production. Min et al. (2022) found that on classification tasks, swapping the correct labels in the demonstrations for random ones hurt far less than expected. The examples were mostly teaching the label space and the format, not the mapping. Read that as "get the format and the allowed answers exactly right", not as "labels do not matter".

Here is a worked example. The task is to turn a raw commit message into one release-note line. Three examples, each with a job: the boring middle, the SKIP edge, and a near-miss that reads as internal but is user-visible.

from anthropic import Anthropic

client = Anthropic()
MODEL = "claude-sonnet-5-5"   # as of October 2026

def text_of(resp) -> str:
    return "".join(b.text for b in resp.content if b.type == "text")

SYSTEM = """Rewrite a raw commit message as one release-note line.
Plain past tense. No ticket ids. No trailing full stop.
If the commit has no user-visible effect, output exactly: SKIP

The examples show the format only. Never reuse their wording or numbers.

<examples>
<example>
<commit>fix(auth): correct token expiry check (PROJ-412)</commit>
<note>Fixed expired sessions not logging users out</note>
</example>
<example>
<commit>chore: bump eslint to 9.2.0</commit>
<note>SKIP</note>
</example>
<example>
<commit>refactor(api): move rate limiter, raise limit to 200/min</commit>
<note>Raised the API rate limit to 200 requests a minute</note>
</example>
</examples>"""

def note(commit: str) -> str:
    resp = client.messages.create(
        model=MODEL,
        max_tokens=1000,   # thinking is on by default and counts against this
        system=SYSTEM,     # stable on every call; cacheable once it is long enough
        messages=[{"role": "user", "content": f"<commit>{commit}</commit>"}],
    )
    if resp.stop_reason != "end_turn":
        raise RuntimeError(f"no usable answer: {resp.stop_reason}")
    return text_of(resp).strip()

print(note("feat(export): add CSV option to the export dialog"))

The parameter spellings are copied from the vendor docs as of October 2026. This sample was not run here, so try it before you rely on it. The other form is hand-written user and assistant turns placed before the real one. This lesson checked only the tag form against the vendor's guide, so test the turn form on your model before you switch.

"fix(auth): correct token expiry check (PROJ-412)" → "Fixed expired sessions not logging users out"1

"chore: bump eslint to 9.2.0" → "SKIP"2

"refactor(api): move rate limiter, raise limit to 200/min" → "Raised the API rate limit to 200 requests a minute"3

3.When examples hurt, and when to skip them

The failure you will meet first is copying content instead of form. Examples are context like everything else, so the model can lift a name, a number or a fact straight out of one. Suppose the real commit says the limit is now 500 a minute and the note comes back saying 200. That is the shape of the failure, shown here as an illustration, not a run result. The tell is a detail from an example turning up in a real output. The fixes, in order: keep examples short and obviously synthetic, vary them so no one detail dominates, and say outright that they show format only, as the sample's prompt does.

The second failure is newer. In July 2026, two members of Anthropic's Claude Code team said they had taken examples out of their agent's system prompt for the newest models, because examples pulled the output toward the sample and narrowed what the agent tried. The claim is theirs, about their own product, with no published evaluation, and it came through an informal conversation, so weigh it that way. Simon Willison's "no longer best practice" framing was his gloss, not theirs. They did not test format tasks.

The vendor's own guide, as of October 2026, still recommends three to five examples. Both can be true: examples are strong for fixing a shape and weak when you want the model to explore. Do not settle it by argument. Run your twenty cases with the examples and without, per model, and let the harness decide (Versioning and testing prompts). Also, a different paper (GEPA, a February 2026 revision) reported that its instruction-only optimiser matched or beat an optimiser that also tuned examples, on its six tasks. That is a claim about those optimisers, not a rule that examples are bad.

Cost. Examples are input tokens on every call, which sounds worse than it is. Stable examples in the system prompt sit in the cached prefix, and cache reads cost a small fraction of normal input (as of October 2026, see Prompt layout and the cache). Two catches: the prefix must pass the model's minimum length to be cached at all, and examples you retrieve per request land in the volatile part, where you pay in full.

Next: that is Part 1, and all of it assumed one prompt doing one job. Part 2 starts with what happens when it is doing five.