Cover for the post “Few-Shot Templates and Counter-Example Patterns”

Packs

Few-Shot Templates and Counter-Example Patterns

Copyable templates for showing a model what you want, and how to show it what you don't. Free, no sign-up.

Showing a model an example of what you want is usually faster, and more reliable, than describing it. This is the copyable version of that technique: three templates for showing what you want, two patterns for showing what you don't, and the honest limits of both.

Everything here comes from the Few-Shot Examples lesson, which has the reasoning and the worked demonstrations. This page is the part you paste.

Before the templates: how many examples

Two to three is the sweet spot for most coding tasks. The reason is worth knowing, because it changes what you do when you only have one:

Examples What happens
1 May be treated as a single case rather than a pattern — the model can follow it exactly instead of generalising
2 Establishes a pattern. The model can see what varies and what stays constant
3 Confirms the pattern and shows an edge case. Diminishing returns begin here
4+ Rarely helps, and spends context on examples instead of on the actual task

One example is enough when the pattern is simple and obvious (a naming convention, a file structure), when you are showing format rather than logic, or when the single example is genuinely comprehensive.

A single excellent example beats five mediocre ones. A good example is representative of the pattern you actually want repeated, complete (imports, error handling, edge cases), and clean — no hacks, no workarounds, no TODOs. A bad one is outdated, exceptional rather than typical, incomplete, or messy. The model has no way to know which parts of a messy example you meant.

Template 1 — Pattern match

For when you want new code to follow an established shape in your codebase.

Follow the pattern in these examples exactly.

Example 1:
<paste a complete, clean instance>

Example 2:
<paste a second instance that varies in the way you want varied>

Now write the same thing for: <your new case>

Match the structure, the naming and the error handling. If something in my
examples looks wrong, say so rather than copying it.

That last line matters. Without it you will get your own mistakes back, multiplied — the model is matching your pattern, including the parts of it you would have fixed.

Template 2 — Format lock

For when the shape of the output is the thing you care about, and the content varies.

Return your answer in exactly this format. No preamble, no summary, no
commentary.

Format:
<paste one filled-in example of the exact output you want>

Input: <your input>

Use this when you are going to parse the output, paste it into a file, or compare several runs. "No preamble" is doing real work here: a format that is correct but wrapped in two sentences of introduction still breaks whatever reads it next.

Template 3 — Transformation pair

For when you want a consistent change applied, rather than something new written.

Apply the same transformation.

Before: <paste the original>
After:  <paste the result you wanted>

Before: <a second original, different in a way that matters>
After:  <its result>

Now apply it to:
<your target>

The second pair is what stops the model over-fitting to an incidental detail of the first. Choose a second pair that differs in a way you care about.

Counter-example patterns — showing what you don't want

Positive examples tell a model what to aim at. They do not tell it what to avoid, and a model that has never seen your failure mode will happily produce it.

Be straight about the evidence here. These are patterns that practitioners use and that are cheap to try. We are not claiming a measured improvement, and you should be suspicious of anyone who does — the published research on negative exemplars is thinner than the confident advice about them, and a specific multiplier ("one negative example is worth three positive ones") is the sort of number that circulates without a source behind it.

Pattern A — Contrast pair

Put the wrong version next to the right one and label both.

DON'T do this:
<the version you keep getting, or the one you found in review>

DO this instead:
<the version you want>

Why: <one line — the actual reason, not "best practice">

Now write: <your task>

The "Why" line is the part people skip and the part that does the work. Without it you have shown two variants and left the model to guess which difference mattered.

Pattern B — Named failure mode

When the thing you want avoided is a behaviour rather than a shape.

<your task>

Avoid these specific failure modes:
- <failure mode 1, described concretely>
- <failure mode 2>

If you are about to do one of these because the alternative looks worse, stop
and tell me instead.

Keep the list short and concrete. "Don't write bad code" is not a failure mode; "don't swallow the exception and return an empty array" is.

When not to bother

Few-shot has a cost: the examples take context space, and they take your time to choose well. Skip it when the task is genuinely simple and conventional, when you have no clean example to give — a bad example is worse than none — or when you are exploring rather than producing, and constraining the output early would cut off the answer you were hoping for.

Where to go next