- In short
- Technique selection by task complexity means choosing the lightest prompt technique that meets the task requirements and adding scaffolding only when the task demands it. The progression is deliberate: start zero-shot, add few-shot examples only if the task needs them, and add chain-of-thought only if the reasoning path itself matters to the answer. Every added layer costs tokens and latency on every call, so the correct technique is chosen by task complexity, not by habit or by defaulting to the most elaborate option.
Match the technique to the task, not to the habit
Knowing the three techniques is not the same as knowing when to use each. The Claude Certified Architect - Professional (CCAR-P) exam frames technique selection at the understand level around a single rule: choose the lightest technique that meets the task's requirements, and add scaffolding only when the task demands it. The correct technique is chosen by task complexity, not by habit and not by reflexively reaching for the most elaborate option. This mirrors the model-tier discipline of the Sonnet-first default heuristic: start light, add weight only on demonstrated need.
The reason this matters is economic and compounding. Every technique layer you add costs tokens and latency on every single call, forever. A heavier technique that does not improve the answer is not neutral; it is a recurring tax paid on all traffic.
- Technique selection by task complexity
- The discipline of choosing the lightest prompt technique that meets a task's requirements and adding scaffolding only when the task needs it. The deliberate progression is zero-shot first, few-shot only if the task's format or judgment is hard to describe, and chain-of-thought only if the reasoning path itself matters to the answer. Each added layer costs tokens and latency on every call.
The deliberate progression
The progression from the prompt technique taxonomy is meant to be walked deliberately, one step at a time, stopping as soon as the task is met.
Start zero-shot. Instructions only. For a well-specified task the model already handles reliably, this is the whole answer, and anything more is waste. Add few-shot examples only if the task needs them, specifically when the desired format or judgment is easier to show than to describe. The trigger is difficulty of description, not a general belief that examples help. Add chain-of-thought only if the reasoning path itself matters to the answer, such as a multi-step judgment where getting the steps right is what makes the answer right. The trigger is that the reasoning, not just the output, is where the difficulty lives.
At each step you ask whether the current technique meets the requirement. If it does, you stop. If it does not, you add the next layer, targeting the specific difficulty the task presents.
Every layer is a recurring cost
The discipline is enforced by cost. Few-shot examples add their tokens to every call and become content you must maintain as the task evolves; stale examples quietly steer the model wrong. Chain-of-thought generates reasoning tokens and latency on every request. These are not one-time costs paid at design; they are paid per call at production volume. So a technique that does not earn its place is a tax on all future traffic. That framing is what turns "which technique" from a stylistic choice into an architectural one.
Chain-of-thought, the prompt instruction, should also not be confused with the extended-thinking feature; both add reasoning, but they are separate decisions with separate cost profiles, as extended thinking as a cost-latency tradeoff sets out.
What the exam trips candidates on
The two traps are the two habitual over-reaches. The first is reaching for chain-of-thought on a simple, well-specified classification task that zero-shot already handles reliably. A scenario will apply step-by-step reasoning to a trivial task; the credited reading strips it back to zero-shot. The second is adding few-shot examples as a default habit rather than because the task's format or judgment is hard to describe in words. A scenario will include examples reflexively; the credited reading removes them unless the task genuinely needs demonstration.
Worked example
A team's prompt for classifying tickets into five fixed categories uses ten few-shot examples and a 'think step by step' instruction. It works, but it is slow and costs more than expected per call. An engineer says 'it's accurate, so leave it.' How should the architect respond?
The prompt works, but working is not the bar; the bar is meeting the task with the lightest technique. This task, classifying into a small fixed set of well-specified categories, is exactly the kind zero-shot handles reliably. Both extra layers here are over-reaches that the exam's two traps name directly.
The chain-of-thought instruction applies step-by-step reasoning to a task whose answer does not depend on a reasoning path; a category assignment is not a multi-step judgment. It generates reasoning tokens and latency on every classification for no accuracy gain, which is precisely the recurring tax the discipline warns against, and it explains much of the slowness and cost. The ten few-shot examples were likely added out of habit rather than because the categories are hard to describe; five clearly named categories can be specified in instructions, so the examples add tokens to every call and become content to maintain without earning their place.
The architect's response is to test the lighter version rather than accept "it's accurate, so leave it." Strip to zero-shot with the categories clearly described, and evaluate it against the same graded set. If zero-shot holds the accuracy, and for a task like this it very likely will, the team keeps the accuracy while removing the per-call cost and latency the heavier techniques were charging. "It works" was hiding the fact that a lighter technique works just as well for less.
Common misreadings to avoid
Misconception
Chain-of-thought improves any task, so it's safe to add everywhere.
What's actually true
Misconception
Adding a few examples never hurts, so include them by default.
What's actually true
How this shows up on the exam
Understand-level questions present a task, sometimes with an over-scaffolded prompt, and ask which technique is appropriate. The reliable answer chooses the lightest technique that meets the task, starting zero-shot and adding few-shot or chain-of-thought only on a demonstrated need, and treats every added layer as a recurring per-call cost.
This knowledge point builds on the prompt technique taxonomy, applies concretely in matching technique to scenario-based tasks, and connects to prompt portability across model tiers, where a more capable model may need less scaffolding to reach the same quality.
A prompt classifying tickets into five fixed categories uses ten few-shot examples plus a 'think step by step' instruction. It is accurate but slow and costly per call. What should the architect do?
People also ask
How do you choose a prompt technique?
When should you add few-shot examples?
When is chain-of-thought worth the cost?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.