3.5 Iterative Refinement Techniques

What You Need to Know

Working with Claude Code is iterative. The first output is rarely the final one. The exam checks that you know the specific techniques for steering Claude Code toward the right result — and which one to reach for first in each situation.

The Technique Hierarchy

Not all refinement techniques are equal. There’s a clear pecking order:

1. Concrete input/output examples (most effective for inconsistent interpretation)

When you describe a code transformation in prose and Claude Code interprets it differently each time, the fix is not more prose. The fix is concrete examples.

Provide 2-3 examples showing 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 these examples more reliably than from any prose description. Two or three concrete examples set the pattern, and the model applies it to new cases. This is the first technique to reach for when interpretation is inconsistent.

2. Test-driven iteration (most effective for complex transformations)

Write the tests first. Define the expected behaviour through test cases covering:

Happy path (the standard expected transformation)
Edge cases (null values, empty inputs, boundary conditions)
Performance requirements (if applicable)

Then share the test failures with Claude Code. The failures give concrete, unambiguous feedback about what needs fixing. There’s no room for interpretation when the test output says “Expected X, got Y.”

FAIL: testMigrationHandlesNullValues
  Expected: null preserved in output JSON
  Actual: null replaced with empty string ""

This failure message tells Claude Code exactly what to fix. No prose explanation needed.

3. Interview pattern (most effective for unfamiliar domains)

When you’re working in a domain where you lack expertise, have Claude ask questions before implementing. This surfaces considerations you’d otherwise miss.

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 policies, consistency requirements, and failure modes — considerations that an expert would know to address but that you might overlook.

Batch vs Sequential Feedback

How you deliver feedback matters. The rule:

Single message (batch) when fixes interact with each other:

If changing the error handling pattern also affects the logging format and the response structure, provide all three pieces of feedback 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 the naming convention issue and the indentation issue don’t 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"

Example-Based Communication in Practice

When prose descriptions produce inconsistent results, the switch to examples follows a clear pattern:

Observe inconsistency: You describe a transformation, 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.

It’s not about piling on more examples. Two or three well-chosen ones that cover the standard case and a key edge case are enough. The model generalises the pattern; you don’t need to hand it every possible case.

When Each Technique Applies

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

Exam Traps

Practice Scenario

A developer describes a code transformation in prose. Claude Code interprets it differently each time, producing inconsistent results. What technique should the developer try first?

A. Rewrite the prose description with more precise language and technical terminology
B. Write a comprehensive test suite and iterate by sharing test failures
C. Use the interview pattern to have Claude ask clarifying questions before implementing
D. Provide 2-3 concrete input/output examples showing the exact before and after transformation

Answer & explanation

Correct: D

A — More precise prose still relies on the model interpreting natural language. If interpretation is already inconsistent, adding more words to interpret does not fix the root cause.
B — Test-driven iteration is effective but heavier than necessary as a first step. Concrete examples are faster and directly address the interpretation inconsistency. Save test-driven iteration for complex transformations with many edge cases.
C — The interview pattern surfaces considerations the developer might miss in unfamiliar domains. Here, the developer knows the exact transformation — the problem is the model interpreting it inconsistently. Examples, not questions, are the fix.
D — Concrete examples eliminate interpretation ambiguity entirely. The model sees exactly what the input looks like and exactly what the output should look like. It generalises from examples more reliably than from descriptions. This is the documented first-line technique.

Sources

Claude Code Iterative Development Documentation — Anthropic
Claude Certified Architect Foundations Exam Guide — Task Statement 3.5 — Anthropic

Exam Simulator

Five exam-style multiple-choice questions on Iterative Refinement Techniques. Pick an answer, then open the explanation.

Question 1

A developer describes a code transformation in prose. Claude Code interprets it differently each time, producing inconsistent results. What technique should the developer try first?

A. Provide 2-3 concrete input/output examples showing the exact before and after transformation
B. Rewrite the prose description with more precise language and technical terminology
C. Use the interview pattern to have Claude ask clarifying questions before implementing
D. Write a comprehensive test suite and iterate by sharing test failures

Answer & explanation

Correct: A

A is correct: Concrete examples eliminate interpretation ambiguity entirely. The model sees exactly what the input looks like and exactly what the output should look like. It generalises from examples more reliably than from descriptions. This is the documented first-line technique.
B is wrong: More precise prose still relies on the model interpreting natural language. If interpretation is already inconsistent, adding more words to interpret does not fix the root cause.
C is wrong: The interview pattern surfaces considerations the developer might miss in unfamiliar domains. Here, the developer knows the exact transformation – the problem is the model interpreting it inconsistently. Examples, not questions, are the fix.
D is wrong: Test-driven iteration is effective but heavier than necessary as a first step. Concrete examples are faster and directly address the interpretation inconsistency.

Question 2

A developer is building a caching layer for an API but has limited experience with cache invalidation strategies. They want Claude Code to help design the solution. Which technique is most appropriate?

A. Provide concrete input/output examples of the cache behaviour you want, covering hits, misses, evictions and TTL expiry in each case
B. Write tests first and iterate on failures
C. Use the interview pattern – have Claude ask questions about requirements, edge cases, and constraints before implementing
D. Describe the desired caching behaviour in detailed prose, spelling out every rule and every edge case in writing before any code

Answer & explanation

Correct: C

A is wrong: The developer does not know enough about caching to provide meaningful input/output examples. They might miss important edge cases around invalidation.
B is wrong: Writing tests requires understanding the expected behaviour. In an unfamiliar domain, the developer may not know what to test for (e.g., cache stampede, TTL policies).
C is correct: The interview pattern is designed for unfamiliar domains. Claude asks about cache invalidation strategies, TTL policies, consistency requirements, failure modes – considerations that an expert would know but the developer might overlook.
D is wrong: In an unfamiliar domain, prose descriptions are likely to miss critical considerations. The interview pattern surfaces these before implementation begins.

Question 3

A code review reveals three issues: (1) the error response shape needs an errorCode field, (2) the logging format must include the errorCode, and (3) a variable is named using snake_case instead of camelCase. How should the developer deliver this feedback to Claude Code?

A. All three issues in one message, since they were found together
B. Issues 1 and 2 together because they interact, then issue 3 separately
C. All three in separate sequential messages to avoid overwhelming the model
D. Issue 3 first (simplest), then issues 1 and 2 together

Answer & explanation

Correct: B

A is wrong: Batching an independent issue (naming convention) with interdependent issues (error shape + logging) can confuse the model about which feedback applies to which part of the code.
B is correct: Issues 1 and 2 interact – the errorCode field in the response affects the logging format. They must be seen together for a coherent fix. Issue 3 (naming) is independent and should be fixed separately to avoid conflation.
C is wrong: Fixing issues 1 and 2 sequentially would cause the model to address the error response shape without knowing the logging format also needs to change. The second fix might undo or conflict with the first.
D is wrong: The order of simplicity does not matter. What matters is whether issues interact. Issues 1 and 2 must be batched because they share the errorCode structure.

Question 4

A developer provides two concrete input/output examples of a type transformation. Claude Code applies the pattern correctly to standard cases but mishandles null values. What should the developer do next?

A. Write a comprehensive prose description covering all edge cases including nulls
B. Rewrite the original two examples with additional comments explaining null handling
C. Switch to the interview pattern and ask Claude to identify edge cases
D. Add a third example specifically showing how null values should be handled in the transformation

Answer & explanation

Correct: D

A is wrong: If concrete examples already work for the standard case, switching to prose for edge cases reintroduces the interpretation inconsistency problem. Stay with examples.
B is wrong: The original examples correctly established the standard pattern. Adding comments to those examples does not demonstrate the null handling pattern. A separate example is needed.
C is wrong: The developer already knows the correct null handling. They do not need Claude to surface considerations – they need to demonstrate the correct edge case handling via an example.
D is correct: When the model handles the standard case correctly but misses an edge case, add an example specifically showing that edge case. The model generalises patterns from examples – a null-handling example teaches it the edge case pattern.

Question 5

Which of the following correctly describes the relationship between the interview pattern and concrete examples?

A. They are interchangeable techniques for the same problem
B. Interview for unknown domains, examples for known ones
C. Concrete examples should always be tried before the interview pattern
D. The interview pattern is more effective and should be the default choice

Answer & explanation

Correct: B

A is wrong: They solve different problems. Using examples when you lack domain expertise means you might miss edge cases. Using the interview pattern when interpretation is inconsistent delays the fix.
B is correct: Different problems require different techniques. Unfamiliar domain with hidden considerations = interview pattern. Known transformation with inconsistent interpretation = concrete examples.
C is wrong: There is no fixed ordering. The choice depends on the situation: do you know the transformation (use examples) or are you in unfamiliar territory (use interview pattern)?
D is wrong: Neither technique is universally better. Effectiveness depends on whether the problem is inconsistent interpretation or missing domain knowledge.