3.5 Apply iterative refinement techniques for progressive improvement

Key points

1. 1

   When a prose description is interpreted inconsistently (three runs, three formats), give 2-3 concrete input/output examples. Examples pin down the exact transformation and edge cases far better than adjectives such as "consistent" or words such as MUST.

2. 2

   Test-driven iteration: have Claude write the test suite first, covering expected behaviour, edge cases and performance requirements, then implement and iterate by sharing the failing tests. Tests written after implementation tend to confirm its assumptions instead of the requirements.

3. 3

   Give Claude a check it can run (tests, build, linter, a fixture diff, a screenshot comparison) and ask for evidence; otherwise you become the verification loop and "looks done" is the only signal.

4. 4

   The interview pattern: for larger features or unfamiliar domains, start with a minimal prompt and ask Claude to interview you (for example with the AskUserQuestion tool) about implementation, edge cases, failure modes and trade-offs, then write a spec. It surfaces considerations the developer did not know to ask about, such as cache invalidation, stampedes or idempotency windows.

5. 5

   Ordering matters in an unfamiliar domain: interview and spec first, tests from the spec second, implementation and test-failure feedback last. Implementing or writing tests from vague requirements builds rework in.

6. 6

   Fixing edge cases: provide the specific failing inputs as test cases with the exact expected output (a row with a null field, a value stored as the wrong type). Repeating "handle edge cases better", wrapping loops in blanket exception handling that skips rows, or switching models does not supply the missing specification.

7. 7

   Batch interacting issues in one detailed message so Claude designs a single coherent fix (for example a query, its pagination cursor and the sort order that all touch the same path). Address independent issues sequentially, verifying each, so changes stay small and reviewable.

8. 8

   Course-correct early: stop Claude with Escape, use /rewind or checkpoints, and after two failed corrections on the same issue /clear and restart with a better prompt that incorporates what you learned, instead of piling corrections into a cluttered context.

9. 9

   Be specific: name files, scenarios and constraints, reference existing patterns in the codebase, describe symptoms with the likely location and what "fixed" looks like.

Read the source

• Best practices: verification, specificity, interviewing, course-correcting
• Common workflows