Why 2-4 Examples Work
Enough to set a pattern, few enough to stay general.
Why 2-4 Examples Work is a free Claude Architect lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The Core Idea
Few-shot prompting works because Claude generalizes from examples — it doesn't just memorize and repeat them. The exam fact sheet is precise about the dose: use 2-4 targeted examples per ambiguity.
That range is not arbitrary. It is enough to set a pattern, yet few enough to keep the model general. This lesson explains why that sweet spot holds for production work.
Examples Teach a Rule, Not a Lookup Table
When you show Claude 2-4 examples, you are demonstrating a rule: this input shape maps to that output shape. The model infers the underlying pattern and applies it to new, unseen inputs.
This is why few-shot is the go-to tool for consistency, edge cases, output format, and reducing hallucination — all areas where a vague instruction leaves too much room for drift.
system = (
"Classify each support message as: billing, technical, or other.\n"
"Examples:\n"
"Message: 'My card was charged twice' -> billing\n"
"Message: 'The app crashes on login' -> technical\n"
"Message: 'Do you have a dark mode?' -> other"
)
# 3 examples set the mapping rule; Claude generalizes to new messages.Why Not Zero Examples?
Zero-shot relies entirely on your instruction wording. For genuinely ambiguous tasks, words alone under-specify the boundary. The fact sheet stresses that explicit criteria beat vague guidance — but even sharp criteria sometimes need a concrete demonstration to lock in.
A single well-chosen example resolves ambiguity that a paragraph of prose cannot. That is the floor of the 2-4 range: at least a couple of demonstrations per ambiguous decision.
Why Not One Example?
One example is risky: the model can over-fit to its surface features — a specific phrasing, length, or coincidental detail — and treat that accident as part of the rule.
A second and third example let Claude triangulate what actually varies versus what stays constant. The shared structure becomes the signal; the incidental differences become noise to ignore.
# One example: model may copy the exact tone/length.
# Two+ examples reveal what is INVARIANT (the JSON shape)
# versus INCIDENTAL (the specific values).
examples = [
{"review": "Loved it, fast shipping!", "out": {"sentiment": "positive"}},
{"review": "Broke after a day.", "out": {"sentiment": "negative"}},
]
# The constant is the {"sentiment": ...} schema, not the wording.Why Not 20 Examples?
If a few examples are good, why not flood the prompt? Two reasons.
- Over-specialization: with too many examples, Claude can start mirroring their exact style and stop generalizing — it narrows to the training set instead of the rule.
- Context cost: long example blocks eat the context window and worsen lost-in-the-middle, where the model attends less to content buried in the middle.
2-4 keeps the demonstration sharp and the prompt lean.
Stay General: Cover the Decision, Not Every Case
The goal of few-shot is to set a pattern, not to enumerate the world. If you find yourself adding a 10th example to handle one more case, that is a signal: the task probably needs clearer criteria or a structured output schema, not more examples.
Examples that disagree with each other or pile up only confuse the rule and dilute attention. Keep each demonstration earning its place.
One Set Per Ambiguity
Read the fact sheet phrasing carefully: 2-4 examples per ambiguity. The budget is scoped to each distinct point of confusion, not the whole prompt.
If a task has two separate ambiguous decisions — say, how to classify and how to format the date — give a small targeted set for each. You are not capped at four examples total; you are capped at a focused few per decision you are disambiguating.
# Ambiguity 1: category boundary (3 examples)
# Ambiguity 2: date normalization (2 examples)
# Each ambiguity gets its own small, targeted set.
prompt = f"""
Category examples:
'refund my order' -> billing
'page is blank' -> technical
'how do I export' -> other
Date examples:
'next Tuesday' -> 2026-06-16
'06/10' -> 2026-06-10
Now process: {user_message}
"""Choose Examples That Mark the Boundary
Quality beats quantity. Two examples that sit right on the decision boundary teach more than ten obvious ones. Pick cases that are easy to get wrong: the near-miss, the edge case, the input that looks like one category but belongs to another.
This is exactly why the fact sheet ties few-shot to edge cases — a couple of well-placed contrast pairs define the rule far better than a heap of central, unambiguous samples.
Few-Shot Plus Structured Output
For output shape, pair a couple of examples with a JSON Schema via tool_use. The schema enforces required fields and eliminates syntax errors; the 2-4 examples teach the judgment the schema can't express — which value belongs in which field on a tricky input.
Remember the schema rule: mark a field required only if it is always present. Never require a possibly-absent field, or the model will fabricate one.
tools = [{
"name": "record_ticket",
"description": "Save a classified support ticket.",
"input_schema": {
"type": "object",
"properties": {
"category": {"enum": ["billing", "technical", "other"]},
"priority": {"enum": ["low", "high"]},
},
"required": ["category"], # priority may be absent -> not required
},
}]
# tool_choice="any" guarantees a structured call; examples teach the judgment.Few-Shot vs. Retry-With-Feedback
Don't confuse the two. Few-shot sets the pattern up front so the first response is right. Retry-with-feedback fixes a specific bad response after the fact by resending the original input, the wrong output, and the exact validation error.
Adding more examples won't fix a missing-information failure — retry can't recover info that is simply absent from the source either. Use examples to shape behavior; use retry to repair format/arithmetic slips.
A Practical Recipe
For any ambiguous prompt:
- Write explicit criteria first (vague instructions are the weak baseline).
- Add 2-4 examples per remaining ambiguity, chosen on the decision boundary.
- Reach for a schema when the gap is output shape, not judgment.
- If you keep adding examples, stop — fix the criteria or the schema instead.
Enough to set a pattern; few enough to stay general.
system = """Flag a code comment ONLY when it contradicts the code.
Examples:
Code: x = a + b Comment: 'subtract b' -> FLAG (contradicts)
Code: x = a + b Comment: 'sum a and b' -> OK
Code: retry(3) Comment: 'retry twice' -> FLAG (count wrong)
"""
# Explicit criterion + 3 boundary examples = consistent, general behavior.Checkpoint: Choosing the Example Count
Scenario question — pick the best answer.
Recap
Key takeaways:
- 2-4 examples per ambiguity is the sweet spot — Claude generalizes from them, it doesn't just repeat them.
- Too few (0-1) under-specifies or over-fits to surface detail; too many over-specializes and wastes context, hurting attention to the middle.
- Pick examples on the decision boundary; quality beats quantity.
- Pair examples with explicit criteria and, for output shape, a JSON Schema — and never require a possibly-absent field.
- If you keep adding examples, fix the criteria or schema instead.
Frequently asked questions
Is the “Why 2-4 Examples Work” lesson free?
Yes — the full text of “Why 2-4 Examples Work” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.
What will I learn in “Why 2-4 Examples Work”?
Enough to set a pattern, few enough to stay general. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Claude Architect?
No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Why 2-4 Examples Work” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Claude Architect lesson?
Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.