Iterative Refinement
Match the refinement technique to the problem: examples, tests, or interviews — and know when to batch feedback versus sequence it.
Good output rarely arrives on the first try; you refine. The exam does not test *that* you iterate but *which technique* fits the situation. Three approaches dominate, each tied to a specific failure signal.
Concrete examples — for inconsistent interpretation
When prose descriptions yield different results across runs, stop polishing the wording and give 2-3 concrete before/after pairs. The model generalizes from examples more reliably than from interpretive prose. Cover the standard cases plus one key edge case.
Input: getUserData(userId: string): Promise<UserData>
Output: getUserData(userId: string): Promise<Result<UserData, ApiError>>Runs interpret your prose differently, so you reword the description a third time — interpretive prose keeps producing varied results.
"Wrap the return type in a result type for error handling."Give 2-3 concrete before/after pairs. The model generalizes the exact transformation far more reliably than from prose.
Input: Promise<UserData>
Output: Promise<Result<UserData, ApiError>>Test-driven iteration — for complex transformations
For intricate changes, write tests first — happy path, edge cases like null and empty input, and any performance bounds — then share the failures. A message like "Expected X, got Y" removes interpretation ambiguity entirely and gives Claude an unambiguous target.
Interview pattern — for unfamiliar domains
In a domain you don't know well, ask Claude to pose clarifying questions *before* implementing. This surfaces considerations you might miss — cache invalidation, TTL policy, consistency guarantees, failure modes — instead of you prescribing a solution you can't fully specify.
Use the interview pattern for unfamiliar domains where you might miss considerations. Use concrete examples when you know the exact transformation but the model interprets it inconsistently. Swapping them is a classic wrong answer.
Batch vs sequential feedback
- Batch several notes into one message when the issues *interact* — for example, changing error handling also affects logging format and response shape, so the model needs all constraints at once.
- Sequence feedback when the issues are *independent* — fix naming separately from indentation so it stays clear which correction addresses which concern.
Inconsistent output -> concrete examples. Complex transformation -> test-driven iteration. Unfamiliar domain -> interview pattern. Interacting issues -> batch; independent issues -> sequence.
If two runs interpret the same prose differently, adding a third rewrite rarely helps. Two or three examples pin the pattern faster than more description.
How the exam will try to trick you
The distractors below look right under time pressure — learn the tell.
- The trap
Runs interpret your prose differently, so rewrite the description with more precise, technical wording.
Correct answerGive 2-3 concrete input/output examples showing the exact before/after transformation.
Why: More precise prose still relies on interpretation; examples remove the ambiguity entirely.
- The trap
The model interprets a transformation inconsistently, so use the interview pattern to draw it out.
Correct answerUse concrete examples for inconsistent interpretation; reserve the interview pattern for unfamiliar domains.
Why: Examples fix a known transformation the model misreads; interviews surface blind spots you can't yet specify.
- The trap
Always give feedback one item at a time so each fix stays isolated.
Correct answerBatch interacting issues into one message; sequence only independent ones.
Why: When changing error handling also shifts logging and response shape, the model needs all constraints at once to stay coherent.
Key takeaways
- Concrete before/after examples fix inconsistent interpretation.
- Test-driven iteration turns complex transforms into unambiguous targets.
- The interview pattern surfaces blind spots in unfamiliar domains.
- Batch feedback when issues interact; sequence it when they are independent.
- Switch to examples rather than endlessly rewording prose.
Frequently asked questions
How do I make Claude Code output more consistent?+
When prose yields varying results across runs, provide two or three concrete before/after examples instead of refining the wording. The model generalizes the pattern from examples far more reliably than from interpretive descriptions.
When should I batch feedback versus give it one item at a time?+
Batch feedback into a single message when the issues interact, so Claude sees all constraints together. Give feedback sequentially when the issues are independent, which keeps it clear which correction addresses which component.