Iterative refinement techniques
Apply iterative refinement techniques for progressive improvement.
This subtopic (3.5) sits in Claude Code Configuration & Workflows (D3) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 18 practice questions here — 3 easy, 10 medium, and 5 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- single message for interacting issues vs sequential for independent issues
- concrete input/output examples vs prose descriptions for transformation tasks
- interview pattern — Claude asks questions before implementing
- test-driven iteration — write tests first, share failures to guide improvement
Free practice questions: Iterative refinement techniques
You are using Claude Code to rename process_order to handle_order in orders.py, and the three call sites in checkout.py, refund.py, and api.py must be updated to use the new name. How should you prompt Claude Code?
Show answer & explanation
Correct answer: C. Send the rename and all three call-site updates in a single message, since the call sites must be edited to match the new name the rename introduces.
The rename and the call-site updates interact: any call site that still uses the old name after the rename is broken code, and any call-site edit that runs before the rename is editing against a function that has not yet been renamed. Issues that interact should be submitted together so Claude can reason about the whole change as one consistent edit. Sending the rename first and then sequential follow-ups treats call sites as independent issues, which they are not — the code is broken between messages. Sending rename then batched call-sites still splits interacting edits across turns and leaves the codebase broken between them. Letting Claude infer the rename from a pattern of call-site edits inverts the dependency entirely.
Your team's /normalize-changelog slash command in .claude/commands/ converts free-form release notes into a strict markdown structure. Initial output keeps formatting headings inconsistently across releases. The release-notes inputs vary wildly in length and tone. Iterative-refinement guidance points at examples, but space in the command file is tight. Which refinement to the command file most directly improves transformation consistency?
Show answer & explanation
Correct answer: C. Append two before/after pairs to the command body — each showing a raw release note and the exact normalized markdown output.
Two before/after pairs in the command file teach the exact transformation shape — what raw input maps to which normalized markdown — far more reliably than rule prose for variable inputs. A numbered checklist describes the target abstractly and tends to drift on novel inputs. Moving rules to CLAUDE.md changes scope but not the prose-vs-example problem. Plan mode forces a planning round-trip on every invocation and addresses approval, not transformation consistency.
Your team's CLAUDE.md instructs Claude Code to reformat log entries into a structured JSON schema. Initial results are inconsistent. To apply iterative refinement, what is the most effective next step?
Show answer & explanation
Correct answer: D. Add concrete before/after examples showing raw log input and the exact expected JSON output directly in CLAUDE.md.
Concrete input/output examples eliminate ambiguity for transformation tasks by showing the exact mapping, not describing it. 'Expand the prose description' adds more text but still relies on interpretation, not demonstration. 'Create a slash command that re-runs...' addresses iteration mechanics, not the specification quality. 'Switch to plan mode' delays execution but does not improve the transformation definition.
2 more free questions on this subtopic in the practice stream, plus 13 in the full bank. Keep practicing →