What you’ll be able to do
- Recognize when few-shot examples, not longer instructions, are the right fix for inconsistent output
- Write 2–4 targeted examples for ambiguous cases that explain why one action beat the plausible alternatives
- Use examples to fix an output format and to separate acceptable patterns from genuine issues
- Use examples of varied document structures to reduce hallucinated and empty extractions
What you need to know
When instructions plateau, show instead of tell
There's a point where adding more instruction stops helping. A review prompt can specify "include the file and line, describe the issue, assign a severity, and suggest a fix" in careful prose and still get output that varies: sometimes a paragraph, sometimes bullets, sometimes the fix is missing. Few-shot examples are the most effective technique for getting consistently formatted, actionable output once detailed instructions alone have produced inconsistent results. A model copies a demonstrated shape far more reliably than it reconstructs one from a description.
Every example uses the same four fields in the same order. That consistency is what the model picks up.
Target the ambiguous cases, and show the reasoning
Examples are worth most where the right answer isn't obvious. Clear-cut cases already go right, so demonstrating them adds tokens without changing behavior. Spend the examples on the cases where the model currently wavers:
- Ambiguous tool selection: a request like "what's going on with my account?" could route to an order lookup or a customer lookup. An example shows which tool was chosen and why.
- Branch-level test coverage gaps: a function with tests for the happy path but none for its error branch. Is that a gap worth reporting? An example settles where the line is.
The skill the exam tests: write 2–4 targeted examples that each show the reasoning for why one action was chosen over plausible alternatives, not just the final answer. "Chose lookup_order rather than get_customer because the message contains an order number and asks about delivery status" teaches a decision rule. A bare answer only teaches that one input.
Examples sit alongside good tool descriptions and clear criteria; they don't replace them. If a tool's description doesn't say what it's for, fix that first. Use examples for the residual ambiguity once the basics are right.
Examples teach judgment that generalizes
A well-chosen example does more than cover its own case. Because it shows why, the model can apply the same judgment to patterns no example mentions. This is the advantage over enumerating rules: a list of pre-specified cases only matches those cases, while examples with reasoning let the model generalize to novel ones.
The same mechanism can backfire. A model learns whatever is consistent across the examples, including things you didn't mean to teach. If every example is short, or every example comes from one module, the model may treat that as part of the rule. Vary the dimensions that shouldn't matter (length, subject, phrasing) and keep constant the thing you're teaching.
Separate acceptable patterns from genuine issues
False positives often come from code that looks suspicious but is fine: a broad except that logs and re-raises, a mutable default that is never mutated, a deliberate retry loop. Pair examples so the contrast is explicit:
REPORT: except Exception: pass Reason: the failure is silently swallowed; callers can’t detect it.
Contrast pairs reduce false positives without reducing recall, and because each carries its reason, the model can generalize to other "looks risky, is fine" patterns.
Few-shot for extraction: varied structures, fewer hallucinations
In extraction (Scenario 6), few-shot examples are an effective way to reduce hallucination and empty fields. Two failure modes are common:
- Varied document structures. A paper may cite sources inline or in a bibliography; it may have a methodology section, or bury method details in the results text. If the prompt only ever shows one layout, the model looks for that layout and either invents a value or returns nothing when it isn't there. Examples that demonstrate each structure (one extraction from an inline-citation paper, one from a bibliography paper) show where to look.
- Informal or non-standard values. "About two and a half inches," "a couple of kg." An example showing how such values are recorded keeps the model from inventing precision or skipping the field.
When a required field keeps coming back empty or null for documents that do contain the information, the usual cause is a format the model hasn't seen. Add an example showing correct extraction from that format.
Key concept
When detailed instructions still give inconsistent results, add 2–4 targeted examples: they fix the output format, show the reasoning on ambiguous cases, contrast acceptable patterns with real issues, and cover the document structures you actually see.
When a scenario describes output that varies in shape, a reviewer that flags safe idioms, or an extractor that misses fields on certain document layouts, the fix is usually examples aimed at exactly those cases, not more instruction text.
Practice scenario
Work it through, then open this
The instructions are already explicit, so more instructions are unlikely to help. The model has only seen the conventional layout and doesn’t recognize the alternative one. Add a few examples that demonstrate extraction from each structure the corpus contains: one where the sample size is in a methodology section, one where it’s embedded in the results text, one where funding is in a footnote. Each example should show where the value was found. This addresses both the empty fields and the fabricated values, since the model now knows where to look.
Build exercise — Replace instructions with targeted examples
Intermediate · 30 min
What you’ll learn
- Finding the ambiguous cases worth spending examples on
- Writing examples that carry reasoning, not just answers
- Covering varied document structures in an extraction prompt
-
Run an existing prompt on 20 inputs and sort the outputs into consistent, inconsistent format, and wrong judgment.
- Why: Examples should target where the model wavers, not the cases it already handles.
- You should see: A handful of ambiguous input types that account for most of the inconsistency.
-
Write 2–4 examples covering those ambiguous types, each in the exact output format you want and each stating why the chosen action beat the plausible alternative. Include at least one acceptable-versus-issue contrast pair.
- Why: The reasoning is what lets the model generalize; the shared format is what makes output consistent.
- You should see: Re-run output in a uniform format, with the ambiguous cases decided the same way as your examples.
-
For an extraction prompt, add one example per document structure in your corpus (for example, inline citations versus a bibliography), then re-run on documents that previously produced empty fields.
- Why: Empty or invented values on unfamiliar layouts are a coverage gap that examples fill directly.
- You should see: Fewer null required fields and no values that don’t appear in the source.
Exam traps
Adding more paragraphs of instructions when output format keeps varying
Once instructions have plateaued, few-shot examples are the most effective way to get consistent, actionable output.
Choosing examples of easy, clear-cut cases instead of the ambiguous ones
Clear cases already go right. Spend examples on ambiguous tool choices, borderline coverage gaps, and other cases where the model wavers.
Showing only the answer in an example, without the reasoning for rejecting alternatives
The reason one action beat the plausible alternative is what the model generalizes from. A bare answer teaches one case.
Expecting examples to work only as a lookup table of pre-specified cases
Examples with reasoning let the model apply the same judgment to novel patterns. That generalization is the point.
Using examples that all share one document layout when production documents vary
The model looks for the layout it was shown, then fabricates or returns null when it’s absent. Demonstrate each structure you expect.
Adding dozens of examples where 2–4 targeted ones would do
A few well-chosen examples aimed at ambiguity do the work. More examples add cost and can teach incidental patterns.
Sources
- Claude Developer Platform Docs
- Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)