CCA Prep
CCAR-FUA

Lesson 3.5Lesson 17 of 30

Iterative refinement

Apply iterative refinement techniques for progressive improvement

Iterative refinementThe output is not right yet. Why?prose is readinconsistently2–3 input →output examplesbehaviour or edgecases are wrongTests first,share thefailuresinput + expectedoutputunfamiliar domainInterview first,then implementClaude asks youquestionsseveral issues atonceInteracting →one messageindependent → oneat a timeLouder prose, "be careful" or a bigger model rarely fix any of these

Key points

  1. 1When a prose instruction is interpreted differently from run to run, show 2–3 concrete input → output examples. Examples communicate a transformation better than a more emphatic rewrite of the same prose.
  2. 2Test-driven iteration: write tests for behaviour, edge cases and performance before the implementation, then paste the actual failures back to Claude. "Still broken, be more careful" gives it nothing to work with.
  3. 3Fixing an edge case? Give a specific test case with the input and the expected output (a row with middle_name = null must stay NULL, not become the string "None").
  4. 4In an unfamiliar domain (cache invalidation, retries, failure modes), use the interview pattern: have Claude ask you questions first, so it surfaces considerations you hadn't anticipated before any code is written.
  5. 5Issues whose fixes interact go into one detailed message, so Claude can solve them together. Independent issues are fixed one at a time, each checked before the next.
What the exam guide checks here

Objective wording from the exam guide (English).

  • 3.5.K1Concrete input/output examples communicate transformations best when prose is misread
  • 3.5.K2Test-driven iteration: tests first, iterate on failures
  • 3.5.K3Interview pattern: Claude asks questions to surface unconsidered issues
  • 3.5.K4One message for interacting problems vs sequential fixes for independent ones
  • 3.5.S1Give 2–3 input/output examples when descriptions give inconsistent results
  • 3.5.S2Write tests for behaviour, edge cases, performance before implementation; share failures
  • 3.5.S3Use the interview pattern in unfamiliar domains (cache invalidation, failure modes)
  • 3.5.S4Give specific test cases with input and expected output to fix edge cases (nulls in migrations)
  • 3.5.S5Address interacting issues together, independent issues sequentially

Lock it in

Answer scenario questions on this topic. Every option comes with an explanation.

Practise 3.5 · 23 questions