Claude Architect · Lesson

Generalization vs Repetition

The model applies the pattern to new cases.

Generalization vs Repetition is a free Claude Architect lesson on CoddyKit — lesson 3 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 means putting a handful of worked examples directly in the prompt. But here is the key insight architects must internalize:

The model does not memorize and replay your examples. It generalizes the underlying pattern and applies it to brand-new inputs it has never seen.

Good examples are teachers, not a lookup table. This single distinction drives every design choice in this lesson.

Repetition vs Generalization

Imagine you give Claude two examples that classify support tickets as billing or technical.

Repetition (the wrong mental model): the model only handles inputs nearly identical to your examples.
Generalization (what actually happens): the model infers the rule behind the labels and classifies a totally new ticket correctly.

Your job is to write examples that make the rule obvious, not to cover every possible input.

Why Few-Shot Works

The fact sheet is explicit: few-shot prompting uses 2-4 targeted examples per ambiguity, and the model generalizes, it does not just repeat.

It is the strongest tool for four jobs:

Consistency across many calls
Edge cases that words alone fail to pin down
Output format you want every time
Reducing hallucination by anchoring behavior

You teach the shape; the model fills in the rest.

Examples Live in messages

Few-shot examples are passed as prior turns in the messages array. Remember: the model keeps no state, so you send the FULL history (including examples) every request.

Each example is a user turn followed by the ideal assistant turn. The new, unseen input becomes the final user turn the model must generalize to.

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=256,
    system="Classify each ticket as 'billing' or 'technical'. Reply with one word.",
    messages=[
        {"role": "user", "content": "My card was charged twice."},
        {"role": "assistant", "content": "billing"},
        {"role": "user", "content": "The app crashes on launch."},
        {"role": "assistant", "content": "technical"},
        # NEW, unseen case — the model generalizes the pattern:
        {"role": "user", "content": "I was promised a refund but never received it."},
    ],
)
print(resp.content[0].text)

Cover the Decision Boundary

To make the model generalize well, your 2-4 examples should map the decision boundary, not pile up near-duplicates.

Three near-identical billing tickets teach almost nothing extra. Instead, pick examples that sit on either side of the line and one tricky case that clarifies where the line is.

Diverse, boundary-defining examples generalize. Redundant examples just invite repetition.

Explicit Criteria Beat More Examples

Few-shot is powerful, but it pairs best with explicit criteria. The fact sheet contrasts a precise rule like "flag a comment only when it contradicts the code" against vague guidance like "be more precise".

Combine a sharp rule in the system prompt with a few examples that demonstrate it on hard cases. The rule states the intent; the examples calibrate the judgment.

system = (
    "You review code comments. "
    "Flag a comment ONLY when it contradicts the code it describes. "
    "Do not flag style, tone, or outdated-but-harmless notes."
)

messages = [
    {"role": "user", "content": "# returns the sum\ndef f(a,b): return a*b"},
    {"role": "assistant", "content": "FLAG: comment says sum, code multiplies."},
    {"role": "user", "content": "# legacy helper\ndef g(x): return x+1"},
    {"role": "assistant", "content": "OK: comment does not contradict the code."},
]

Generalizing Output Format

One of the most reliable uses of few-shot is teaching an exact output format. Show the structure two or three times and the model reproduces it for any new input.

But when the contract must be guaranteed, escalate from examples to enforcement: tool_use with a JSON Schema eliminates syntax errors and enforces required fields. Few-shot shapes the content; structured output guarantees the shell.

tools = [{
    "name": "record_ticket",
    "description": "Store a classified support ticket.",
    "input_schema": {
        "type": "object",
        "properties": {
            "category": {"type": "string", "enum": ["billing", "technical", "other"]},
            "priority": {"type": "string", "enum": ["low", "high"]},
        },
        "required": ["category", "priority"],
    },
}]

# tool_choice='any' guarantees the model emits structured output, not prose.
# Few-shot examples still teach HOW to choose the category.

Don't Over-Constrain the Schema

When you combine few-shot with structured output, respect one hard rule from the fact sheet: mark a field required ONLY if it is always present.

If you require a field that may be absent, the model will fabricate a value to satisfy the schema — the opposite of good generalization. For extensible fields, use an enum with an "other" value plus a free-text detail field.

"input_schema": {
    "type": "object",
    "properties": {
        "category": {"type": "string",
                     "enum": ["billing", "technical", "other"]},
        # captured only when category == 'other' — NOT required
        "other_detail": {"type": "string"},
    },
    # require only what is ALWAYS present
    "required": ["category"],
}

More Examples Are Not Always Better

The guidance is 2-4 examples per ambiguity — not twenty. Why the cap?

Long example blocks bloat context and trigger lost-in-the-middle: the model attends to the start and end more than the middle, so examples buried in the middle lose influence.
Twenty redundant examples push toward repetition and waste tokens.

If a few good examples plus a clear rule are not enough, the fix is usually a sharper rule or a better-chosen example — not more of them.

When Few-Shot Cannot Help

Generalization has limits. If the needed information is simply absent from the source, no example will conjure it — just as retry-with-feedback fixes format errors but cannot recover facts that were never there.

Few-shot calibrates judgment and form on information the model has. It does not invent missing data. Asking it to do so produces confident hallucination, which is exactly what we use few-shot to reduce.

Examples as Reusable Assets

Because examples generalize, a small, well-curated set becomes a durable asset. In Claude Code, capture them where the team will reuse them:

Project ./CLAUDE.md or a .claude/rules/ file (shared via VCS) so teammates inherit the same calibrated behavior.
A path-scoped rule file loads examples only when editing matching files — saving context versus a monolithic prompt.

Curate once; the pattern generalizes across every future input.

---
paths: ["**/*.sql"]
---
# SQL review examples (loaded only when editing SQL)

Flag a query ONLY when it can return wrong rows.

Example — FLAG:
  SELECT * FROM orders WHERE status = 'paid' OR amount > 0
  (OR widens the filter; likely a bug)

Example — OK:
  SELECT id FROM orders WHERE status = 'paid' AND amount > 0

Quick Check

An architect is building a ticket classifier and worries the model only handles inputs that look exactly like the few-shot examples. Which design choice best produces correct generalization to new, unseen tickets?

Recap

Key takeaways:

Few-shot examples make the model generalize the pattern, not memorize and repeat.
Use 2-4 targeted, boundary-defining examples per ambiguity — diversity beats volume.
Pair examples with explicit criteria; sharp rules beat vague instructions and beat piling on more examples.
For guaranteed structure, escalate to tool_use + JSON Schema — but require a field only if it is always present, or the model will fabricate.
Few-shot reduces hallucination and enforces format/consistency; it cannot recover information absent from the source.
Curate examples once in shared, path-scoped config so the calibrated behavior generalizes across every future input.

Frequently asked questions

Is the “Generalization vs Repetition” lesson free?

Yes — the full text of “Generalization vs Repetition” 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 “Generalization vs Repetition”?

The model applies the pattern to new cases. 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 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Generalization vs Repetition” 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.

All lessons in this course

← Back to Claude Architect