Few-shot prompting is the architectural "sample room." It is the most powerful tool for teaching Claude complex formatting, edge-case handling, and subtle tone requirements without writing pages of instructions. In this task, we master the art of selecting, structure, and balancing examples for production reliability.
Imagine you hire a carpenter to build custom bookshelves. You can tell them "I want it to looks modern and hold heavy books" (Zero-Shot). You might get something decent, but maybe it won't be exactly what you imagined.
Now imagine you show them three photos of finishes you love (Few-Shot): 1. "Thin walnut with hidden brackets," 2. "Burnt oak with industrial piping," and 3. "Light pine with integrated LEDs."
The carpenter doesn't just "understand" the words; they "see" the construction patterns. They can now synthesize a new piece that matches your specific taste because you gave them the reference material. Few-shot prompting is providing the "photos" so Claude doesn't have to imagine your architecture.
In the Architect's view, "Few-shot" isn't always better. It consumes tokens. You must know when to pay the "token tax" for examples.
| Scenario | Best Approach | Reasoning |
|---|---|---|
| Simple classification (Positive/Negative) | Zero-Shot | Basic logic is baked into Claude; examples are token-wasting. |
| Extracting PII with nested JSON schema | Few-Shot | Ensures the JSON structure remains valid across varied inputs. |
| Creative writing in a specific brand voice | Few-Shot | Tone is hard to define in rules; it's easy to mimic from samples. |
| Handling "Edge Case" inputs (e.g. empty fields) | Few-Shot | Rules might be ignored; examples of "No Data Found" behavior are sticky. |
Production few-shot examples should be wrapped in XML to ensure Claude recognizes them as static reference rather than current instructions.
<examples> <example> <input>"User cancelled their order #123 last Tuesday."</input> <output>{"order_id": 123, "status": "CANCELLED", "date": "2024-03-26"}</output> </example> <example> <input>"Shipment for order #456 is arriving tomorrow."</input> <output>{"order_id": 456, "status": "SHIPPED", "date": "2024-03-28"}</output> </example> </examples>
In massive production systems, you can't have a static prompt that contains 50 examples. You'll run out of tokens. Instead, use **Dynamic Example Retrieval**.
// 1. Retrieve top-k most similar examples from a vector DB based on User Input examples = vector_db.search(query=user_input, top_k=3) // 2. Map and Inject into System Prompt prompt = f"Follow these patterns: {examples} \n\n Task: {user_input}"
This ensuring that Claude sees examples that are **semantically relevant**. If the user asks about a cancellation, retrieve 3 cancellation samples—not shipping samples. This maximizes the **Context-to-Token Value Ratio**.
Avoid "Example Bloat." If you pick 3 examples, Ensure they are not neighbors in vector space. 1 Success case, 1 Edge-case failure, and 1 Irrelevant input case provide much more architectural coverage than 3 Success cases.
A "Positive" example tells Claude what success looks like. A "Negative" example tells Claude which hallucinations or formatting traps to avoid. This is critical for high-stakes architectural prompts.
<negative_example> <reason>Why this is wrong: Summarizes text instead of extracting data.</reason> <bad_output>Yesterday, an order was placed by John for...</bad_output> <fixed_output>{"customer": "John", "date": "2024-03-27"}</fixed_output> </negative_example>
Providing 3 examples that all use the same string length or valid data. Problem: Claude assumes it should only handle valid data. Fix: Include one case with "N/A" or "Missing Info".
The "Recency Bias." Claude often weighs the last example slightly more than the first. Fix: Put the "Standard Case" last and complex cases first.
Mixing example tags with instruction tags. Problem: Claude treats one of the examples as the "Current Task." Fix: Always explicitly wrap the active input in <current_task> tags.
Using examples with a key names (e.g. id) that you changed in your current instructions (e.g. uuid). Fix: Examples must be perfect mirrors of current schema rules.
Scenario: You've clearly told Claude to output JSON using <format> tags. However, Claude still occasionally adds "Here is the JSON:" at the beginning.
Question: What's the most architecturally sound fix?
Correct Answer: B. Claude learns the "shape" of the output from examples. If all examples start with { and end with }, Claude will much more consistently replicate that structure than by following a text rule alone.
<example> tags to prevent Claude from mistaking them for current input.