What You Need to Know
A prompt engineering technique shapes a prompt so the model does a task better. Zero-shot prompting gives instructions only. Few-shot adds worked examples. Chain-of-thought (CoT) tells the model to reason before it answers. They rise in cost in that order: the escalation ladder.
A butcher's shop uses Claude to turn order emails into order sheets. Four things go wrong:
- The sheet layout drifts from week to week.
- Marinated chicken thighs are filed as fresh meat one day and prepared food the next.
- Totals for mixed orders, priced by weight with a bulk discount, come out wrong.
- Replies promise collection times, although the prompt forbids it.
The Escalation Ladder
- Zero-shot with clear instructions is the baseline for capable models, and it covers most production tasks. If the instructions pin down task, audience, format and constraints, nothing more is needed. Instruction quality is the first fix, and it costs nothing.
- Few-shot examples come second. They go out with every request and inflate it, so they must earn their place.
- 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 before adding anything. A system that ignores stated rules needs clearer instructions and structure first (tags, ordering, emphasis). Any technique added on top inherits the ambiguity. The butcher restates the collection 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", recommending 3 to 5 for best results. Three properties make a set work:
- Relevant: mirroring the actual use case, not a generic version of it.
- Diverse: covering edge cases. Five restatements of the happy path teach the model an unintended pattern; near-miss and boundary examples teach the distinctions prose cannot pin down.
- Structured: wrapped in example tags so the model can tell them apart from instructions.
Few-shot is the standard fix for format-compliance failures and classification boundaries. An exact example fixes a layout that prose leaves open. A boundary example shows which side a case falls on. The butcher adds one sheet in the exact layout and one correctly filed thigh order. Examples inflate every request unless they sit in the cached static prefix (objective 2.5).
Chain-of-Thought and Built-In Thinking
CoT works through step-by-step instructions or a thinking-then-answer format. Tags separate the reasoning from the final output, so downstream parsing still works. CoT buys accuracy on multi-step reasoning: calculations, multi-criteria decisions, contract analysis. Its latency and output tokens make it wrong for latency-critical trivial tasks. Visible reasoning also exposes faulty logic for audit.
The butcher's totals are multi-step: weight times price per kilo, across cuts, then the discount. Examples of finished totals show outcomes without teaching the path. Reasoning in its own tags lets staff check each sum.
Current Claude models have built-in thinking (checked 14 October 2026). On Claude 4.6-generation and later models, adaptive thinking decides dynamically when and how much to think. It is always on for Fable 5.1 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 and the context window.
Prompted CoT remains the portable, named form of the technique. It stays the right tool where reasoning must be visible and auditable in the response body, or where thinking is unavailable or disabled for cost. Current state (checked 6 October 2026): the prompting docs now say to rely on thinking on Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5 and Sonnet 5.5. There, as of that check, a prompt asking for written-out reasoning (for example in <thinking> tags) may be declined. The architect decides where reasoning happens and whether it must be auditable; CoT and thinking are not rivals.
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 |
Adding examples to fix a reasoning failure, or reasoning to fix a format failure, spends tokens on the wrong problem. Every example and reasoning instruction is a recurring cost and one more thing to maintain and cover in evals (Domain 4). CoT on a high-volume trivial endpoint, such as the butcher's order-received reply, is over-engineering: reasoning tokens and slower responses for zero quality gain.
In the exam
Items on this objective pair a failure symptom with four plausible fixes; the skill tested is diagnosis. The keyed answer is the cheapest technique that fixes the observed failure. For the butcher: examples for the layout and the thighs, CoT for the totals, a clearer collection rule. Prompted CoT is still the keyed answer, even where the docs now point to thinking.
Where 2.3 Ends
Reasoning inside one call is this objective. Decomposing the task into a pipeline of calls with validation gates is prompt chaining, a Domain 1 architecture decision. A stem crossing that boundary asks an architecture question, not a technique question.
Exam Traps
Responding to a prompt-shaped failure — format drift, boundary confusion — by moving to a larger model
The failure follows the prompt to the new model, and the premium is paid on every request. The cheap targeted fix (examples, instruction clarity) was never tried. Model upgrades address measured capability gaps, nothing else.
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 payload. Structure the output so reasoning sits in its own tags and the answer stays machine-readable — otherwise the accuracy gain becomes an integration failure.
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 where the exam items live.
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 set is only as good as 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.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), and note what auditability you would lose
Why: Unparseable reasoning turns an accuracy gain into 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 is what separates engineering from decoration.
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