- In short
- Switching refinement techniques means reading the failure signal in front of you and choosing the technique that matches it: inconsistent formatting despite detailed instructions calls for concrete examples, an unfamiliar domain calls for the interview pattern, and complex logic calls for test-driven iteration with failing test cases. The meta-skill is recognising that persisting with a technique that keeps producing poor results is itself the signal to change.
Knowing when to switch refinement techniques
Knowing when to switch refinement techniques is the judgement that turns a kit of techniques into a workflow. You already know the techniques, concrete examples, test-driven iteration, the interview pattern, and you know they are ranked by leverage. What this knowledge point adds is the harder, evaluate-level question: faced with a particular failure, which technique should you reach for, and when should you abandon the one you are using? The Claude Certified Architect exam places this at the top of the refinement strand because it requires you to weigh signals and justify a switch, not merely recall a definition.
The mental model is diagnostic. Each common failure has a tell, and each tell maps to a technique. Inconsistent formatting that persists despite a detailed, clearly written instruction is the tell for switching to examples, the description is being read loosely and a demonstration will pin it down. Working in a domain you barely understand, where you cannot say what good even looks like, is the tell for the interview pattern, you need Claude to surface the considerations you have not thought of. Complex logic, where correct behaviour is too intricate to capture in a sentence or two, is the tell for test-driven iteration, a failing test states the requirement unambiguously and machine-verifiably. Read the tell, pick the technique.
- Switching refinement techniques
- Choosing or changing the refinement technique to match the failure signal: inconsistent format despite clear instructions to examples, unfamiliar domain to the interview pattern, and complex logic to test-driven iteration. The overarching cue is that repeated poor results from one technique are themselves a signal to switch rather than to retry harder.
The three signal-to-technique mappings
Take the three mappings one at a time, because the exam tests each. The first is inconsistent formatting despite detailed instructions to examples. The diagnostic word is despite: your instruction is not vague, yet the structure still varies. That rules out "write it more clearly" and points to the show-versus-tell gap, which example based communication closes by demonstrating the target rather than describing it.
The second is unfamiliar domain to the interview pattern. Here the failure is not miscommunication but under-specification. You have not pinned down what you want because you do not yet know. Examples cannot help, since you cannot demonstrate a target you have not defined. Asking Claude to interview you, surfacing technical choices, edge cases, and tradeoffs, produces the missing specification. The third is complex logic to test-driven iteration. When the behaviour is intricate enough that no short demonstration captures it, you encode the requirement as tests and feed Claude the failures, the technique covered in test-driven iteration with failing tests. Each mapping pairs a distinct kind of failure with the technique built to fix it.
The meta-signal: repetition
Underneath the three specific mappings sits one signal that overrides them all: if a technique keeps producing poor results, that repetition is the cue to switch. The most common refinement failure is not picking the wrong technique once; it is picking a technique and then, when it underperforms, applying it harder, more prose on top of prose, another vague correction on top of the last. Anthropic's own guidance is explicit that after a couple of failed corrections the productive move is to change approach rather than to keep grinding, because a loop polluted with failed attempts rarely recovers by adding one more.
Recognising this in yourself is the real skill. Persisting feels like diligence, but past two or three failed iterations it is usually a sign that the technique does not fit the problem. The evaluate-level question on the exam often hides exactly here: a developer has corrected Claude the same way several times with no improvement, and the right answer is not a fourth correction of the same kind but a switch to a different technique, chosen by the symptom. Reading repetition as a signal, not as a reason to try once more, is what separates a workflow from a rut.
Why this is an evaluate-level skill
Applying a single technique is an apply-level act; choosing between techniques under uncertainty is an evaluate-level one, and the difference matters for how the exam phrases its questions. An apply question hands you the technique and asks you to use it. An evaluate question hands you an ambiguous situation with more than one plausible response and asks which is best and why. To answer, you have to compare the candidate techniques against the specific signal and rule out the ones that do not fit, recognising, for instance, that an interview would be wasted effort on a pure formatting problem, or that examples cannot rescue a task whose requirements you have not yet defined.
That comparative judgement is why this knowledge point depends on having internalised the others first. You cannot evaluate a switch to test-driven iteration without understanding what test-driven iteration does, nor weigh examples against the interview pattern without knowing the failure each addresses. It is the capstone of task statement 3.5, and it links outward to the other scenario-analysis knowledge points across Domain 3, command and skill design scenarios, convention application scenario analysis, and mode selection scenario classification, all of which share the same shape: read the situation, justify the choice.
Worked example
Over one afternoon, a developer hits three different walls with Claude Code. (A) A data-formatting task returns inconsistent JSON even though the instruction is detailed and clear. (B) They are asked to design an unfamiliar billing-proration feature and keep getting plausible but wrong implementations. (C) A date-range overlap function has subtle edge cases that Claude keeps getting almost right.
Each wall is a different failure, so each demands a different switch, and the skill is matching them rather than reaching for one favourite technique three times.
For (A), the tell is inconsistent format despite a clear instruction. The description is not the problem, so writing it again will not help. The right switch is to concrete examples: two or three input/output pairs of the exact JSON shape, which pin down the structure the prose was failing to convey.
For (B), the tell is an unfamiliar domain. The developer cannot give good examples because they cannot yet say what correct proration even is, which rounding rule, which boundary conditions, which refund policy. Examples and tests both assume a defined target, so the right switch is the interview pattern: have Claude interview them to surface the billing decisions they have not made, then build from the resulting spec.
For (C), the tell is complex logic with subtle edge cases. The behaviour is well-defined but intricate, and a couple of examples will not cover every boundary. The right switch is test-driven iteration: write failing tests for the tricky overlaps, adjacent ranges, zero-length ranges, identical bounds, and feed Claude the failures until they all pass. Three walls, three different switches, each justified by reading the signal rather than by preference. Had the developer simply added more prose at every wall, all three would have stayed stuck.
What switching looks like in practice
Switching technique is a decision, but in Claude Code it is also a set of concrete moves, and knowing them keeps the switch cheap. The lightest is interruption: press Esc to stop Claude mid-action with the context preserved, then redirect toward the technique the symptom actually calls for. When an approach has already produced a tangled half-result, /rewind, or a double Esc, restores an earlier conversation-and-code checkpoint, so you can branch to a different technique from clean ground instead of building on top of the failed attempt.
The most important move is the one architects under-use. Anthropic's guidance is specific: if you have corrected Claude more than twice on the same issue in one session, the context is now cluttered with failed approaches, and the productive step is to run /clear and start fresh with a more specific prompt that incorporates what you learned. A clean session with a better prompt almost always outperforms a long session with accumulated corrections. This is why switching technique sometimes means switching the session as well: repetition does not only signal the wrong technique, it leaves residue in the context that drags down whatever you try next. The evaluate-level judgement is therefore two-layered, change the technique to fit the signal, and, once failed attempts have piled up, reset the context so the newly chosen technique starts from a clean slate rather than inheriting the wreckage of the last three tries.
Common misreadings to avoid
Misconception
A longer session carries more context, so staying in it gives Claude the best chance to finally get a stubborn task right.
What's actually true
Misconception
If a refinement technique is not working, the disciplined response is to keep applying it more carefully until it does.
What's actually true
Misconception
The interview pattern is the most thorough technique, so it is the safest default when refinement is going badly.
What's actually true
Where this sits in the refinement strand
This is the evaluate-level capstone of task statement 3.5. It sits directly above batch versus sequential feedback and example based communication, both of which it treats as candidate moves to choose between, and it presupposes the ranking established in the technique hierarchy for refinement. Its forward links reach into the CI-oriented workflows of CI/CD pipeline design with Claude Code, where choosing the right refinement technique under automation pressure has real consequences.
How it shows up on the exam
Tested at the evaluate level, this knowledge point appears in Scenario 2 (code generation with Claude Code) and Scenario 5 (Claude Code for continuous integration) as the question that gives you an ambiguous failure and asks for the best next move. Expect a developer who has tried something repeatedly without success, with distractors that suggest doing more of the same. The reliable approach is to name the failure type and map it: inconsistent format to examples, unfamiliar domain to the interview pattern, complex logic to test-driven iteration, and any sign of repeated failure to a switch rather than a retry. The correct option is almost always the one that changes technique to fit the signal, and the trap is the one that simply tries the current technique harder.
A developer has spent several rounds adding ever more detailed prose to a Claude Code prompt for a data-cleaning task, yet the output format is still inconsistent. They are about to write a fifth, even longer instruction. As an architect reviewing their approach, what is the best recommendation?
People also ask
How do I know when to change my approach with Claude Code?
What signal means I should switch to examples?
When should I use the interview pattern instead of examples?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Zero to Claude Certified Architect: Complete Beginner's Guide | Part 18: Iterative Refinement
Why watch: Exam-aligned walkthrough of the refinement technique hierarchy and the signals that tell you when to switch from prose to examples, the interview pattern, or test-driven iteration.
More videos for this concept
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.