Refining step by step: examples, tests and the interview

The first version is almost never the final one. What sets apart people who work well with Claude Code is how they give feedback: which technique they choose for each kind of problem. The exam poses four situations, and each has its tool.

Which technique for which problem

Situation	Technique
You know exactly which transformation you want, but the prose is interpreted differently each time	2 or 3 input/output examples
Every fix breaks a case that used to work	Test-driven iteration
You don’t know the domain and don’t know what to ask	The interview pattern
There are several problems to fix	Group the ones that interact, separate the independent ones

Concrete examples

If you described in prose how to reformat a record and Claude does it differently on every run, more prose won’t fix it. Show it the before and after with 2 or 3 examples: the model generalizes better from examples than from descriptions. If it then handles the standard cases well and fails on nulls, add one example showing exactly that case; don’t go back to explaining it in prose.

Tests first

When every change to a shipping-rate parser breaks another bracket that used to work, the problem is that there’s nothing to check all the cases at once. Test-driven iteration means:

1. write the suite first, from the requirements: expected behavior, edge cases such as empty files or blank amounts, and performance requirements (a realistic file that must be processed in under 5 minutes);
2. implement;
3. on each round, give Claude the concrete failures: which test failed, what it expected and what it got.

“Some tests fail” tells it nothing. And the tests have to come from the requirements: written afterwards by looking at the code, they verify what the code does, bug included.

The interview

If you’ve never designed a caching layer, you won’t be able to give useful examples or write invalidation tests, because you don’t know what can go wrong. With the interview pattern, you ask Claude to question you before implementing: invalidation strategy, time to live, consistency, what happens when many requests arrive at once. It surfaces considerations an expert would raise and you wouldn’t.

The rule for choosing: unknown domain, interview; known transformation with inconsistent interpretation, examples.

Several problems at once

If two problems are interacting issues, such as a response errorCode field that changes the log format, they go together in one detailed message so the fix is coherent. Fixing them separately makes the second fix clash with the first. An independent problem (a variable name) goes separately. Ordering by simplicity doesn’t matter.

The usual traps

• Answering inconsistency with a longer description.
• Using the interview when you already know what you want.
• Taking the first output as the tests’ expected value: it freezes its errors.
• Tests tied to internal details, which break with every refactor.
• Changing the tests so they pass.
• Rewriting everything when 3 of 24 tests fail.

In the exam

Ask yourself what’s missing: clarity about the result (examples), a net that catches regressions (tests) or knowledge of the domain (interview)? And if there are several problems, do they affect each other?