What You Need to Know
A prompt engineering technique changes a prompt so that the model does a task better. Zero-shot prompting gives instructions only. Few-shot prompting adds worked examples. Chain-of-thought (CoT) tells the model to reason before it answers. The three techniques cost more in that order. This order of rising cost is the escalation ladder.
This lesson uses one made-up example throughout: a retail bank that uses Claude to convert customer emails into case records. Four things go wrong:
- The record layout changes from week to week.
- Claude files an email that questions a card fee as a complaint one day and as a general question the next day.
- The refund totals for fee complaints are wrong. These refunds cover several months of fees and subtract an earlier partial refund.
- The replies promise refund dates, although the prompt forbids promises of refund dates.
The Escalation Ladder
- Zero-shot with clear instructions is the baseline for capable models, and it handles most production tasks. If the instructions define the task, audience, format and constraints, nothing more is needed. The first fix is to improve the quality of the instructions, and this fix costs nothing.
- Few-shot examples come second. The examples are sent with every request and make the request larger. So they must be worth including.
- Chain-of-thought comes last among single-call techniques. It adds reasoning tokens and latency, so it is reserved for failures that are genuinely about multi-step reasoning.
Diagnose the failure before you add anything. A system that ignores stated rules needs clearer instructions and structure first (tags, ordering, emphasis). Any technique added to ambiguous instructions keeps the ambiguity. The bank restates the refund-date rule plainly, in its own tag.
Few-Shot: Teaching What Prose Cannot
Anthropic's guidance calls examples "one of the most reliable ways to steer Claude's output format, tone, and structure". The guidance recommends 3 to 5 examples for best results. A set of examples works when it has three properties:
- Relevant: the examples match the actual use case, not a generic version of it.
- Diverse: the examples cover edge cases. Five examples that repeat the happy path (the ordinary case, with no edge cases) teach the model an unintended pattern. Near-miss examples (inputs that look like one class but are another) and boundary examples teach the distinctions that prose cannot define.
- Structured: the examples are wrapped in example tags, so that the model can distinguish them from instructions.
Few-shot is the standard fix for format-compliance failures and for failures at classification boundaries. An exact example fixes a layout that prose does not define. A boundary example shows on which side of a boundary a case belongs. The bank adds one record in the exact layout and one correctly filed fee email. Examples make every request larger unless they are in the cached static prefix (the unchanging opening part of the prompt) (objective 2.5).
Chain-of-Thought and Built-In Thinking
CoT uses step-by-step instructions or a thinking-then-answer format. Tags separate the reasoning from the final output, so parsing in later steps still works. CoT improves accuracy on multi-step reasoning, such as calculations, multi-criteria decisions and contract analysis. CoT adds latency and output tokens, so it is wrong for trivial tasks where latency is critical. Visible reasoning also shows faulty logic, so that the logic can be audited.
The bank's refund totals have several steps: the monthly fee times the number of months for each account, then minus the earlier refund. Examples of finished totals show the results without teaching the steps. When the reasoning is in its own tags, staff can check each sum.
Current Claude models have built-in thinking (checked 13 November 2026). On Claude 4.6-generation and later models, adaptive thinking decides dynamically when and how much to think. Adaptive thinking is always on for Fable 5.2 and Opus 5.5, and on by default for Sonnet 5.5 and Haiku 5.5. The older Haiku 4.5 uses configured extended thinking. Thinking tokens are billed as output and count towards max_tokens (the request's limit on output tokens) and the context window.
Prompted CoT remains the portable, named form of the technique. Prompted CoT stays the right tool where reasoning must be visible and auditable in the response body. It is also the right tool where thinking is unavailable or disabled for cost. The architect decides where reasoning happens and whether it must be auditable. CoT and thinking do not exclude each other.
Current state (checked 14 November 2026): the prompting docs now say to rely on thinking on Claude Fable 5.2, Fable 5.1, Fable 5, Opus 5.5, Opus 5 and Sonnet 5.5. On those models, as of that check, the model may decline a prompt that asks for written-out reasoning (for example in <thinking> tags).
Matching the Technique to the Failure
| Failure symptom | Cheapest effective fix | Why not the others |
|---|---|---|
| Output format wrong or drifting | Few-shot with an exact-format example | CoT adds reasoning the task does not need; emphasis alone underdetermines the format |
| Inconsistent classification at category boundaries | Few-shot with boundary examples | Prose cannot pin down the distinction; reasoning shows the path but not the boundary |
| Wrong answers on multi-step reasoning | CoT or built-in thinking | Examples show outcomes without teaching the path |
| Stated rules ignored | Instruction clarity and structure first | Techniques added on top of ambiguity inherit the ambiguity |
| Any of the above | Never a model upgrade first | Fixes none of these failures, at maximum recurring cost |
If you add examples to fix a reasoning failure, or add reasoning to fix a format failure, you spend tokens on the wrong problem. Every example and reasoning instruction is a recurring cost. It is also one more thing to maintain and to cover in evals (Domain 4). CoT on a high-volume trivial endpoint, such as the bank's message-received reply, is over-engineering. It adds reasoning tokens and slower responses for zero gain in quality.
In the exam
Questions on this objective pair a failure symptom with four plausible fixes. The skill they test is diagnosis. The right answer is the cheapest technique that fixes the observed failure. For the bank, the fixes are examples for the layout and the fee emails, CoT for the refund totals, and a clearer refund-date rule. On the exam, prompted CoT is still the right answer for a multi-step reasoning failure, even where the docs now recommend thinking.
Where 2.3 Ends
This objective covers reasoning inside one call. Prompt chaining splits the task into a pipeline of calls with validation gates. Prompt chaining is a Domain 1 architecture decision. A question that crosses that boundary asks an architecture question, not a technique question.
Exam Traps
Responding to a prompt-shaped failure, such as format drift or boundary confusion, by moving to a larger model
The same prompt causes the same failure on the new model, and the premium is paid on every request. Examples or clearer instructions fix it cheaply, so try those first.
Offering chain-of-thought for a format-compliance failure
Reasoning does not teach format; examples do. An exact-format few-shot example is the canonical fix, and CoT adds latency and output tokens the task cannot use.
Offering few-shot examples for a multi-step reasoning failure
Examples show outcomes without teaching the path. Reasoning instructions or built-in thinking teach the path. Match the technique to the failure class, not to familiarity.
Enabling CoT without separating reasoning from the final answer
Downstream parsers receive prose mixed with the data they expect. With thinking off, answer tags keep the final answer separate from the reasoning. Current docs (October 2026) say to rely on thinking on newer models, where a prompt for written-out reasoning may be declined.
Practice Scenario
A support-ticket triage system misroutes tickets that mention two products at once, and its JSON output intermittently gains a prose preamble that breaks the parser. The team proposes upgrading to the largest model, but finance will not fund a more expensive model tier. What is the best fix?
Build Exercise
Build a Technique-to-Failure Decision Table
What you'll learn
- How to classify production failures as format, boundary, reasoning, or rule-following
- How to select the cheapest fix on the ladder for each failure class
- How to design a diverse few-shot set with edge coverage
- How to write a CoT variant with parseable reasoning, and judge when built-in thinking replaces it
- How to price each technique at volume and decide what belongs in the cached prefix
- Pick a production Claude call and log ten real or synthesised failures; classify each as format, boundary, reasoning, or rule-following
Why: Technique selection is diagnosis. The classification step is the one teams skip, and it is what the exam questions test.
You should see: A ten-row table: failure description, failure class, one line of evidence for the classification.
- For each class present, write the cheapest fix on the ladder — instruction change, example set, or reasoning instruction — with one sentence of justification
Why: The ladder is ordered by cost. Naming the justification keeps you from defaulting to the technique you like.
You should see: One fix per failure class, each justified by the mapping between failure and mechanism.
- Design the few-shot set for the boundary failures: 3-5 examples chosen for diversity and edge coverage, wrapped in example tags
Why: Happy-path examples teach the pattern, not the boundaries. The quality of the set depends on its hardest example.
You should see: A tagged example block where at least two examples sit near the decision boundary.
- For the reasoning failures, write the CoT variant with reasoning and answer separated by tags, for a model where thinking is off. Note that on Claude Fable 5.2, Fable 5.1, Fable 5, Opus 5.5, Opus 5 and Sonnet 5.5 the docs say to rely on built-in thinking instead. A prompt asking for written-out reasoning may be declined. Also note what auditability you would lose
Why: If the reasoning cannot be parsed, the accuracy gain is lost to an integration failure, and the thinking-versus-CoT judgement is a current exam nuance.
You should see: A prompt with a reasoning tag and an answer tag, plus two sentences on the thinking trade-off.
- Price each fix at your monthly volume — added input and output tokens x price x requests — and record which fixes belong in the cacheable prefix
Why: Every technique is a recurring cost line. Pricing it shows whether the technique is worth its cost.
You should see: A cost per fix per month, and a cached/uncached annotation on each.
Sources
- Prompting best practices — Anthropic
- Thinking — Anthropic
- Prompt engineering overview — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic