Examples, Tests First and the Interview Pattern

1.Show the transformation with concrete examples

Iterative refinement is cheapest when the first attempt is already close. The most common reason it isn't: a transformation described in prose. "Normalise the phone numbers" or "clean up the dates" can be read several reasonable ways. Each run may pick a different reading, so the output changes from one run to the next. Adding more adjectives to the prose doesn't fix this. Showing the transformation does.

Anthropic's prompting guidance calls examples one of the most reliable ways to steer output. It also says a few well-crafted ones "improve accuracy and consistency." The Claude Code best-practices page applies the same idea to coding. A vague request, "implement a function that validates email addresses", becomes a precise one when you add three example cases: user@example.com is true, invalid is false, user@.com is false. Three short input/output pairs settle questions that a paragraph of prose would leave open.

How many examples, and which ones? Begin with one. Add more only when the output still misses, which in practice usually means two or three. Choose them on purpose. The platform guidance says examples should be *relevant* (close to your real use case) and *diverse*: "Cover edge cases and vary enough" that Claude doesn't pick up a pattern you didn't intend. Anthropic's context-engineering guidance warns against the opposite habit, where teams "stuff a laundry list of edge cases into a prompt". It recommends a small set of "diverse, canonical examples" instead. If all three of your examples are well-formed US phone numbers, Claude will learn that every input looks like that.

Sources123

2.Write the test suite before the implementation

A test is an input/output example that a machine can run. Writing tests first turns a one-off clarification into a loop that repeats: Claude implements, runs the suite, reads the failures, and fixes them. The Claude Code on the web guide recommends this pattern for backend work and gives this prompt:

Add rate limiting to the /api/search endpoint.

The rate limiter should:
- Allow 100 requests per minute per API key
- Return 429 status when limit exceeded
- Reset limits after 60 seconds
- Track different API keys independently

Use a TDD approach: write comprehensive tests first, then implement the rate limiting logic to pass them.

The guide explains why it works. The tests give Claude "clear validation criteria to work towards", and Claude can iterate "using test failures to identify and fix problems" without you supervising each step. Look at what the bullet list covers. There's normal behaviour (100 requests per minute), the boundary (return 429 when the limit is exceeded), and edge cases (the reset after 60 seconds, separate tracking per key). The exam guide also lists *performance requirements* as something to test up front. The sources here don't show an example of that, so treat it as the same principle applied to speed or resource limits: if it matters, write it down as a test.

The same approach works when an existing implementation mishandles an edge case. Don't write "handle nulls better." Give Claude the exact input and the result you expect. For example: a migration row whose field is null, and what that row should look like after migration. The best-practices page phrases it as asking Claude to "write a failing test that reproduces the issue, then fix it." The failing test holds your specification, and when it passes you have evidence the fix works.

Sources45

3.The interview pattern: let Claude ask first

Examples and tests only help if you already know what correct looks like. In an unfamiliar domain you often don't. You might not know you need a cache invalidation strategy, or what the failure modes of an external service are. The interview pattern reverses the usual direction: before implementing, Claude asks *you* questions. The best-practices page gives a template:

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

Three details make this work. The prompt asks for "the hard parts I might not have considered". That covers design questions you didn't know to raise, not things you already know. Claude stops interviewing only once everything has been covered. And the result is written down as a spec that later implementation turns can follow. A field guide on Claude Code suggests a version that ranks the questions: "Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture." When you know little about an area, it recommends a "blind spot pass" first, asking Claude to help you find your "unknown unknowns." It also advises telling Claude how much you already know, so the questions fit your level.

Sources56

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.When the output is inconsistent, the fix is to list every edge case and rule you can think of in the prompt.Why is that wrong?

   Anthropic advises against stuffing a prompt with a laundry list of edge cases. Use a small, diverse set of canonical examples instead, starting with one and adding more only if needed.

   Covered in Show the transformation with concrete examples

2. 2.The interview pattern means letting Claude ask for clarification on everything, including basic requirements.Why is that wrong?

   The documented prompt tells Claude to skip obvious questions and focus on the hard parts the developer hasn't thought about.

   Covered in The interview pattern: let Claude ask first