Generalización frente a repetición
El modelo aplica el patrón a casos nuevos.
Generalización frente a repetición es una lección gratuita de Claude Architect en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Claude Architect, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Claude Architect incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
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.mdor 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 > 0Quick 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.
Preguntas frecuentes
¿La lección «Generalización frente a repetición» es gratis?
Sí — el texto completo de «Generalización frente a repetición» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Claude Architect, actualiza a CoddyKit PRO. El curso de Claude Architect incluye 4 lecciones en total.
¿Qué aprenderé en «Generalización frente a repetición»?
El modelo aplica el patrón a casos nuevos. Practicas Claude Architect con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Claude Architect?
No se requiere experiencia previa. Claude Architect en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Generalización frente a repetición»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Claude Architect?
Sí. Cada lección de Claude Architect incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Por qué funcionan 2-4 ejemplos
- Ejemplos de formato y casos límite
- Generalización frente a repetición
- Few-shot para reducir las alucinaciones