Iterative Refinement Techniques

Official Exam Guide Objectives

Knowledge of

• Concrete input/output examples as the most effective way to communicate expected transformations when prose descriptions are interpreted inconsistently
• Test-driven iteration: writing test suites first, then iterating by sharing test failures to guide progressive improvement
• The interview pattern: having Claude ask questions to surface considerations the developer may not have anticipated before implementing
• When to provide all issues in a single message (interacting problems) versus fixing them sequentially (independent problems)

Skills in

• Providing 2-3 concrete input/output examples to clarify transformation requirements when natural language descriptions produce inconsistent results
• Writing test suites covering expected behavior, edge cases, and performance requirements before implementation, then iterating by sharing test failures
• Using the interview pattern to surface design considerations (e.g., cache invalidation strategies, failure modes) before implementing solutions in unfamiliar domains
• Providing specific test cases with example input and expected output to fix edge case handling (e.g., null values in migration scripts)
• Addressing multiple interacting issues in a single detailed message when fixes interact, versus sequential iteration for independent issues

What You Need to Know

Nobody gets the output they wanted on the first attempt, and the exam is less interested in that fact than in what you do next. There are named techniques for steering Claude Code, they suit different failure modes, and the testable skill is picking the right one rather than trying all three.

The Technique Hierarchy

They are not equivalent, and there is an order to reach for them in:

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

Where a transformation described in prose comes back done differently each time, the instinct is to describe it more carefully. That does not work, because the problem is not that the description was unclear — it is that any description leaves room to interpret.

Show two or three transformations instead, input beside 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>>

A pattern demonstrated twice generalises more reliably than a pattern described at any length, because there is nothing left to infer about intent. Two or three cases are enough to establish it. This is where to start whenever the complaint is inconsistency.

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

Write the tests before the change and let them state the requirement:

• The ordinary case, transformed the way you actually want it
• The awkward ones — nulls, empty collections, values sitting exactly on a boundary
• Anything with a timing or throughput requirement attached

Then hand over the failures. A failing assertion is feedback with no interpretive surface at all — it names what was expected and what arrived, and nothing about that can be read two ways.

FAIL: preservesNullsThroughMigration
  Expected: {"middleName": null}
  Actual:   {"middleName": ""}

Nothing needs adding to that. The gap is stated in the output.

3. Interview pattern (most effective for unfamiliar domains)

When the domain is unfamiliar, the risk is not that Claude will misunderstand you — it is that you will forget to ask for something you did not know mattered. Inverting who asks the questions surfaces it.

Instead of prescribing a solution:

"Add a caching layer in front of the orders API"

Use the interview pattern:

"I want to put a caching layer in front of the orders API. Before you write anything, ask me what you need to know — requirements, edge cases, constraints I may not have thought about."

What comes back tends to be the things experience would have prompted: how invalidation works, what TTL suits the data, how much staleness is tolerable, what happens when the cache is unavailable.

Batch vs Sequential Feedback

Delivery matters as much as content, and the deciding question is whether the fixes touch each other.

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

Where changing the error handling also changes the logging format and the response shape, all three belong in one message. Sent separately, each fix is made without sight of the others, so the second contradicts the first and the third has to undo both.

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:

Where the naming convention and the indentation have nothing to do with each other, send them one at a time. Bundled, they compete for attention and it becomes ambiguous which instruction governs which part of the file.

First message:  "Rename the exported functions to camelCase"
[let it finish]
Second message: "Now switch indentation to two spaces"

Example-Based Communication in Practice

Moving from prose to examples follows a repeatable sequence:

1. Observe inconsistency: the same instruction produces a different result on each run.
2. Switch to examples: supply two or three before/after pairs that pin the transformation exactly.
3. Verify generalisation: try a case the examples did not cover, to confirm the pattern transferred rather than the instances being copied.
4. Add edge case examples if needed: where the ordinary case is right and an unusual one is not, demonstrate the unusual one specifically.

Volume adds nothing here. A pair covering the normal case plus one that pins down a genuinely awkward variant is sufficient; beyond that you are mostly re-demonstrating a pattern already established, at the cost of the context it occupies.

When Each Technique Applies

Deep Dive

The technique hierarchy above is about what to say when refining Claude Code's output. Claude Code also has session-level mechanics that support the same iterative loop — focusing context, branching to compare approaches, and undoing an iteration that went the wrong way.

/compact with custom instructions to focus an iteration session

/compact [instructions] replaces conversation history with a summary, optionally focused on what you specify. For more control during a long refinement session, run /compact <instructions> — for example, /compact Focus on the API changes — so the summary that survives compaction is the part still relevant to the current iteration, not a generic recap.

Sources: https://code.claude.com/docs/en/sessions (/compact [instructions]) · https://code.claude.com/docs/en/best-practices (using it mid-session) (fetched 2026-07-30)

Session forking to compare divergent fixes

Branching creates a copy of the conversation so far and switches you into it, leaving the original intact. From the CLI, combine --continue or --resume with --fork-session to create a new session ID rather than reusing the original — useful when you want to try two different fixes for the same interacting-issues batch without losing the baseline conversation.

Sourcecode.claude.com › sessionsfetched 2026-07-30

Checkpoints and /rewind for reverting a bad iteration

Every user prompt creates a new checkpoint automatically. Run /rewind, or press Esc twice on an empty prompt, to open the rewind menu, which offers restoring code and conversation together, conversation only, or code only. This is "local undo" that complements — but doesn't replace — git, and checkpointing does not track changes made by Bash commands, only edits made through Claude's own file-editing tools.

Sourcecode.claude.com › checkpointingfetched 2026-07-30

Writer/Reviewer pattern as a check on self-correction

A fresh context improves code review because Claude won't be biased toward code it just wrote. The documented Writer/Reviewer pattern has one session implement while a second, independent session reviews the implementation and the first session then addresses that feedback — the same split works for tests, with one Claude writing tests and another writing code to pass them. This is a useful cross-check after several rounds of self-driven iteration, when you want an opinion untainted by the reasoning that produced the current draft.

Sourcecode.claude.com › best-practicesfetched 2026-07-30

The Explore-Plan-Implement-Commit workflow as the iteration scaffold

The recommended four-phase workflow — Explore, Plan, Implement, Commit — gives iterative refinement a shape: explore and plan happen before the first draft, so the early rounds of refinement (examples, tests, the interview pattern) apply during Implement, against a plan that already accounted for edge cases and constraints.

Sourcecode.claude.com › best-practicesfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Practice Iterative Refinement Techniques

Difficulty: Beginner (1/4)

30 minutes

1. 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 makes the case for switching 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.

2. 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-line technique 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.

3. 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" leaves no room for interpretation. 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.

4. Use the interview pattern for a task outside your expertise — ask Claude to pose questions before implementing and note what considerations surface

Why: The interview pattern is for unfamiliar domains where you might miss important requirements. It surfaces 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.

5. 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.

Sources

• Claude Code Iterative Development Documentation — Anthropic
• Claude Code Sessions Documentation (forking and branching) — Anthropic
• Claude Code Checkpointing Documentation (/rewind) — Anthropic
• Claude Certified Architect Foundations Exam Guide — Task Statement 3.5 — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. 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 makes the case for switching 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.

Use this prompt three times:
"Refactor getUserData to wrap the return type in a Result type for error handling."
Compare: Does each run produce the same Result shape? The same error type? The same parameter handling?

Step 2. 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-line technique 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.

Provide examples like:
Input: getUserData(userId: string): Promise<UserData>
Output: getUserData(userId: string): Promise<Result<UserData, ApiError>>

Input: fetchOrders(customerId: string): Promise<Order[]>
Output: fetchOrders(customerId: string): Promise<Result<Order[], ApiError>>

Now apply this pattern to: deleteAccount(accountId: string): Promise<void>
Run three times — the outputs should be consistent.

Step 3. 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" leaves no room for interpretation. 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.

Write tests like:
test("formats date correctly", () => {
  expect(formatDate("2024-01-15")).toBe("15 January 2024");
});
test("handles null input", () => {
  expect(formatDate(null)).toBe("Unknown date");
});
test("rejects invalid date", () => {
  expect(() => formatDate("not-a-date")).toThrow("Invalid date format");
});
Share any FAIL output directly with Claude Code for targeted fixes.

Step 4. Use the interview pattern for a task outside your expertise — ask Claude to pose questions before implementing and note what considerations surface

Why: The interview pattern is for unfamiliar domains where you might miss important requirements. It surfaces 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.

Try: "I need a caching layer for the API. Before implementing, ask me questions about the requirements, edge cases, and constraints I should consider."
Expected questions might include:
- What is the cache invalidation strategy?
- What consistency model is required?
- What happens on cache failure — fail open or fail closed?
- What is the TTL policy?

Step 5. 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.

Provide in one message:
Three changes needed (they interact):
1. Error responses must include an errorCode field
2. Logging must include errorCode in structured JSON format
3. The client SDK TypeScript types must reflect the new errorCode field

All three share the same error structure, so they must be fixed together.

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the work you produced for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Prompt Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the work you actually produced.