What You Need to Know
Iterative refinement is the practice of guiding Claude Code to the right result over several rounds, because the first output is rarely the final one. It uses five techniques:
- Concrete input/output examples show the exact input and the exact expected output.
- Test-driven iteration shares test failures with Claude Code.
- The interview pattern has Claude ask questions before implementing.
- Batch feedback sends several fixes in one message.
- Sequential feedback sends fixes one at a time.
This lesson uses one made-up example throughout: a guest house. Its developer uses Claude Code on its booking website. Each situation below happens there.
The Technique Hierarchy
The techniques are not equal. They have a clear order of priority.
1. Concrete input/output examples (most effective for inconsistent interpretation). They are the most effective way to communicate an expected transformation when a prose description is interpreted inconsistently. The guest house developer describes a code change in prose, and Claude Code applies it differently each time. More precise prose still relies on interpretation, so more prose will not fix this problem. Provide 2-3 examples that show the exact input and the exact expected output:
Input: getUserData(userId: string): Promise<UserData> Expected output: getUserData(userId: string): Promise<Result<UserData, ApiError>>
Input: fetchOrders(customerId: string): Promise<Order[]> Expected output: fetchOrders(customerId: string): Promise<Result<Order[], ApiError>>
The model generalises from examples more reliably than from any prose description. Two or three examples set the pattern, and the model applies the pattern to new cases. It is the first technique to use when interpretation is inconsistent.
2. Test-driven iteration (most effective for complex transformations). Write the tests first. The tests define the expected behaviour. They cover:
- Happy path (the standard expected transformation)
- Edge cases (null values, empty inputs, boundary conditions)
- Performance requirements (if applicable)
The guest house developer writes the tests before migrating old booking records. Then the developer shares the failures with Claude Code. Each failure is concrete, unambiguous feedback: "Expected X, got Y" has a single meaning. The failure below tells Claude Code exactly what to fix, with no prose explanation:
FAIL: testMigrationHandlesNullValues Expected: null preserved in output JSON Actual: null replaced with empty string ""
3. Interview pattern (most effective for unfamiliar domains). In a domain where you lack expertise, have Claude ask questions before implementing. The questions reveal considerations that you would otherwise miss. The guest house developer has never built a cache, and the booking site needs one. Instead of prescribing a solution:
"Build me a caching layer for the API"
Use the interview pattern:
"I need a caching layer for the API. Before implementing, ask me questions about the requirements, edge cases, and constraints I should consider."
Claude might ask about cache invalidation strategies, TTL (time to live) policies, consistency requirements and failure modes. An expert would know to address these topics, and the developer might overlook them.
Key Concept
The interview pattern is for unfamiliar domains, where the developer might miss considerations. Concrete input/output examples are for when the developer knows the exact transformation but the model interprets it inconsistently. Do not confuse the two techniques. They solve different problems.
Batch vs Sequential Feedback
How you deliver feedback depends on whether the fixes interact.
Single message (batch) when fixes interact with each other. Suppose changing the booking site's error handling pattern also affects its logging format and response structure. Send all three changes in one message. The model needs to see all the interacting constraints at once to produce a coherent fix:
Three changes needed (they interact with each other): 1. Error responses must include an error code field 2. Logging must include the error code in structured format 3. The client SDK type definitions must reflect the new error code field
Sequential iteration when issues are independent. If a naming convention issue and an indentation issue do not affect each other, fix them one at a time. Batching independent issues can confuse the model about which feedback applies to which part of the code.
First iteration: "Fix the function naming — use camelCase throughout" [Wait for result] Second iteration: "Now update the indentation to use 2 spaces"
Switching From Prose to Examples
When prose descriptions produce inconsistent results, switch to examples in four steps:
- Observe inconsistency: the guest house developer describes a transformation, and Claude Code does it differently each time.
- Switch to examples: provide 2-3 concrete before/after pairs showing the exact transformation.
- Verify generalisation: test on a new case to confirm the model generalises the pattern correctly.
- Add edge case examples if needed: if the model handles the standard case but misses edge cases, add examples specifically showing edge case handling.
Two or three well-chosen examples that cover the standard case and the main edge case are enough. The model generalises the pattern, so it does not need every possible case.
In the exam
The exam checks which technique you use first in each situation. The answer that the exam marks as correct follows this table:
| Situation | Technique |
|---|---|
| Prose description interpreted differently each time | Concrete input/output examples |
| Complex transformation with many edge cases | Test-driven iteration |
| Working in an unfamiliar domain | Interview pattern |
| Multiple issues that affect each other | Batch feedback (one message) |
| Multiple independent issues | Sequential feedback |
These techniques belong to Domain 3, Claude Code Configuration & Workflows. The Claude Code certification explainer compares how heavily each of Anthropic's four exams tests Claude Code.
Exam Traps
Choosing to refine prose descriptions when the model interprets them inconsistently
More precise prose still relies on interpretation, so the inconsistent results continue. When Claude Code misreads a known transformation, 2-3 concrete input/output examples show the pattern directly.
Sending interacting fixes to Claude one message at a time
Fixes that interact need to be seen together. If you send them apart, one fix targets a state that the next fix changes. Put interacting problems in a single detailed message, and fix independent ones sequentially.
Using the interview pattern when the developer already knows the exact transformation
Interview questions reveal considerations the developer has not anticipated, and here there are none to reveal. Concrete input/output examples fix a known transformation that is being misread.
Practice Scenario
A developer describes a code transformation in prose. Claude Code interprets it differently each time, producing inconsistent results. The developer knows precisely what the finished code should look like and wants the quickest fix. What technique should the developer try first?
Build Exercise
Practice Iterative Refinement Techniques
What you'll learn
- Apply the technique hierarchy: concrete examples over prose for inconsistent interpretation
- Use test-driven iteration to provide unambiguous feedback via test failures
- Use the interview pattern for unfamiliar domains to reveal hidden requirements
- Distinguish when to batch feedback vs iterate sequentially based on issue interdependence
- Recognise that 2-3 well-chosen examples are sufficient for pattern generalisation
- Describe a code transformation in prose and run it three times, noting how interpretation varies across runs
Why: This demonstrates the core problem that concrete examples solve. Prose descriptions rely on interpretation, and interpretation varies across runs. Observing this inconsistency firsthand shows why you should switch to examples.
You should see: Three different outputs from the same prose description. The variations may be subtle (different naming choices, different edge case handling) or significant (different structural approaches). This proves that prose alone produces inconsistent results.
- Provide 2-3 concrete input/output examples of the same transformation and run it three times — compare the consistency
Why: Concrete examples are the documented first technique to try for inconsistent interpretation. The model generalises from examples more reliably than from prose. This step proves the effectiveness difference experimentally.
You should see: Three outputs that are consistent with each other and match the pattern established by the examples. The variation observed in the prose-only step is eliminated or drastically reduced.
- Write a test suite for a function with happy path, edge cases, and error cases, then iterate by sharing test failures with Claude Code
Why: Test-driven iteration is the most effective technique for complex transformations. Test failures provide unambiguous feedback — "Expected X, got Y" has a single meaning. This technique complements examples for more complex scenarios.
You should see: After sharing test failures, Claude Code makes targeted fixes that address the specific failing assertions. Each iteration reduces the number of failing tests. The feedback loop is faster and more precise than prose-based corrections.
- Use the interview pattern for a task outside your expertise — ask Claude to pose questions before implementing and note what considerations appear
Why: The interview pattern is for unfamiliar domains where you might miss important requirements. It reveals considerations an expert would know to address. The exam tests whether you can distinguish this from the examples technique — they solve different problems.
You should see: Claude asks 5-10 targeted questions about requirements, edge cases, and constraints you had not considered. The questions reveal considerations like cache invalidation strategies, consistency requirements, failure modes, or security implications that would have been missed.
- Practice batching: give Claude three interdependent issues in one message and observe whether the fix is coherent across all three
Why: When issues interact, batching them in one message lets the model see all constraints simultaneously. Sequential fixing of interdependent issues causes the model to fix one issue in a way that conflicts with the others. The exam tests this distinction.
You should see: A single coherent fix that addresses all three interdependent issues consistently. The error response shape, the logging format, and the type definitions all align with each other. Compare this to fixing them sequentially, where each fix might conflict with the next.