3.5 Iterative Refinement Techniques

Claude rarely produces a perfect result on the very first try for a non-trivial task — and that's fine, because the skill isn't getting it right first time, it's iterating EFFECTIVELY toward right. Task Statement 3.5 is about the techniques for that iteration: how to communicate what you actually want so each round gets closer, instead of going in circles. The mistake most people make is reaching for the same blunt tool every time — 'let me rephrase the instructions' — when a different technique would converge far faster.

Think of it like giving directions. If someone keeps misunderstanding your verbal directions to a place, repeating the words louder doesn't help — but SHOWING them on a map, or walking the route once, instantly clicks. Different misunderstandings need different fixes. The same is true here: when Claude's output isn't matching your intent, the RIGHT refinement technique depends on WHY it's off — and choosing the matching technique is what the exam tests.

There are three core techniques, each suited to a different kind of gap, plus one decision about how to deliver feedback. Let's take them in turn and, crucially, learn which problem each one solves.

The first technique is the most broadly useful: concrete input/output examples. When you describe a transformation in prose and Claude interprets it inconsistently — formatting it one way this run, another way next run — the problem is that prose is ambiguous, and adding MORE prose rarely fixes ambiguity. What fixes it is SHOWING: give two or three concrete examples of input and the exact output you want.

This is the map-versus-verbal-directions idea made literal. A few worked examples pin down what words can't: the precise format, the edge-case handling, the level of detail. The guidance is specific — 2 to 3 concrete examples typically beat any amount of additional prose description. When the symptom is 'it keeps interpreting my description differently each time,' reach for examples, not a longer paragraph.

The second technique, test-driven iteration, shines for COMPLEX transformations where 'correct' is hard to describe but easy to CHECK. You write a test suite first — covering expected behavior, edge cases, requirements — and then iterate by sharing the TEST FAILURES with Claude. Why is this so effective? Because a failing test is unambiguous feedback: 'this input produced X but should produce Y' leaves no room for interpretation, unlike a vague 'that's not quite right.' Each failure points precisely at what to fix, and you converge round by round.

The third technique, the interview pattern, solves a different problem entirely: UNFAMILIAR domains, where YOU might not know all the considerations up front. Instead of specifying everything (and inevitably missing things), you have Claude ask YOU questions first — about cache-invalidation strategy, failure modes, edge cases you hadn't thought of — surfacing the hidden decisions before any code is written. It's the inverse of examples: examples work when you know exactly what you want but struggle to describe it; the interview pattern works when you DON'T yet know everything you want and need help discovering it.

Beyond WHICH technique, there's a decision about HOW to deliver feedback when you have several issues to fix: all at once in a single message (batch), or one at a time (sequential)? The right choice depends on whether the issues INTERACT.

If the fixes interact — fixing issue A changes how you'd fix issue B, or they touch the same logic — deliver them TOGETHER in one detailed message, so Claude can reconcile them as a coherent set rather than fixing A in a way that breaks the not-yet-mentioned B. If the issues are INDEPENDENT — unrelated bugs in different parts of the code — sequential iteration is cleaner, fixing one, confirming, then moving to the next, without the cognitive load of juggling all of them at once. The discriminator is simple: interacting → batch; independent → sequential.

The 3.5 traps test whether you'll match the technique to the gap, or default to rewriting prose. The wrong answers usually offer the blunt instrument (more instructions) or the wrong technique for the described problem.

• •More prose for inconsistent interpretation. ✗ Rewriting the description yet again when output varies run-to-run. ✓ Give 2–3 concrete input/output examples.
• •Confidence thresholds for judgment. ✗ Adding 'be confident' style instructions. ✓ Examples or tests, depending on the gap.
• •Interview pattern vs examples mix-up. ✗ Using the interview pattern when you know exactly what you want (just can't describe it). ✓ Use examples; reserve the interview pattern for unfamiliar domains where you don't yet know the considerations.
• •Wrong batch/sequential choice. ✗ Batching independent issues or sequencing interacting ones. ✓ Interacting → one message; independent → sequential.

You now have three refinement techniques and the batch-vs-sequential decision. The exercise has you deliberately apply each to its matching problem and feel how much faster the right technique converges than rewriting prose.

Refinement is how you steer Claude to the right result interactively. The final lesson of Domain 3, 3.6, takes Claude OUT of the interactive session entirely — running it non-interactively inside a CI/CD pipeline, where these same ideas (independent review, structured output) reappear in automated form.