AnthropicClaude Certified Architect – Foundations2026-103.5 Apply iterative refinement techniques for progressive improvement
Show the transformation before rewriting instructions
Completed by the knowledge check
Learning objective
Clarify inconsistent transformations with two or three concrete examples of inputs and expected outputs.
Core idea
When Claude Code repeatedly implements different interpretations of the same transformation, give it concrete input/output pairs. The missing information is often the meaning of “convert,” “normalize,” or “preserve,” rather than an implementation detail. Another paragraph using those words can leave the same choices unresolved.
Anthropic describes examples as a reliable way to steer output format, tone, and structure and improve accuracy and consistency. For a coding task, the examples specify the behavior the generated program must implement. You still need to verify that program; a plausible explanation of your examples is not evidence that the implementation produces them.
Choose a small set whose members discriminate between competing interpretations. Three ordinary records with different customer IDs teach little more than one ordinary record. An ordinary value, a value that must remain unchanged, and an explicit absence can settle three decisions in one correction. See 3.5.2 for turning the agreed behavior into tests before implementation.
How it works
Replace an ambiguous verb with observable pairs
Suppose a migration converts a legacy contact record into a destination record. “Clean up the phone number” could mean removing whitespace, dropping a country prefix, applying a national format, or rejecting an unsupported value. The required output selects among those interpretations.
For this example migration, the owner approves the following contract: rename customer_id to id, remove spaces from a populated phone string, retain its leading plus sign, and map an empty phone string to JSON null. These are application requirements, not a universal phone-number normalization algorithm.
Send three labeled pairs:
| Example | Input | Expected output | Decision it communicates |
|---|---|---|---|
| Ordinary populated value | {"customer_id":"C17","phone":"+44 20 7000 0017"} | {"id":"C17","phone":"+442070000017"} | Rename the ID field and remove spaces without dropping +44 |
| Already normalized value | {"customer_id":"C18","phone":"+12025550118"} | {"id":"C18","phone":"+12025550118"} | Preserve the populated value when there are no spaces |
| Empty source value | {"customer_id":"C19","phone":""} | {"id":"C19","phone":null} | Emit a null value rather than empty text or a missing field |
Each output is complete for the small record contract. If you omit id from an output merely to save space, the example could suggest dropping it. If a record has additional fields, say explicitly whether the pair is a complete expected record or an excerpt illustrating only one field.
Make the examples relevant, diverse, and structured
Anthropic’s prompting guidance names three properties: relevance to the actual use case, diversity that includes edge cases, and structure that distinguishes examples from instructions. It recommends <example> tags, with multiple examples inside <examples> tags.
In a Claude Code message, you can label each input and expected output directly. For a mixed prompt containing background, requirements, and sample data, use those tags to make their roles explicit. Put the transformation rule in the instructions and the pairs in the examples. Tags organize the prompt; they do not execute a validator or establish that a generated program is correct.
Diversity means varying the decision, not introducing distracting fields. The three pairs here keep the ID shape constant while changing the phone condition. That makes it clear that phone handling varies and ID preservation does not. If you change every field in every example, the reader and Claude must infer which difference controls the behavior.
You can ask Claude to assess your examples for relevance and diversity, as the prompting guide suggests. Review any proposed additions against the actual destination contract. A generated expected output is a proposal until the owner accepts it; allowing Claude to invent the answer recreates the ambiguity you were trying to remove.
State what the pairs do not settle
Examples establish cases, but a finite set does not describe every valid input. These three pairs say nothing about absent phone keys, explicit source null, tabs, or invalid characters. Name unresolved cases rather than assuming that one empty string covers all of them. If they matter to this change, add an explicit rule and an appropriate case before accepting an implementation.
Claude Code’s best-practices page recommends specific files, constraints, and example patterns in prompts. Identify the converter and its existing interface alongside the pairs. Ask for a general implementation of the approved transformation, then ask for evidence from running the relevant check. Anthropic’s prompting guide explicitly cautions against hard-coding test inputs and recommends implementing logic that works for all valid inputs.
Key distinctions and trade-offs
An example versus another description: “Keep missing values empty” has several interpretations. An output containing "phone": null distinguishes a null value from empty text and from omitting the field.
Representative examples versus exhaustive tests: A few pairs communicate the intended transformation efficiently. They do not replace the suite that verifies normal behavior, edge cases, and relevant performance requirements. That suite belongs to 3.5.2.
Diversity versus contradictory expectations: Examples should cover different conditions under one coherent contract. If two identical inputs have different expected outputs, resolve the requirement conflict before asking Claude to implement it. Otherwise the implementation cannot satisfy both.
More examples can resolve additional branches, but they also consume attention and require review. Choose pairs that rule out a plausible wrong transformation. Do not add a fourth routine record merely because it makes the prompt longer.
Architecture / decision scenario
A developer productivity team uses Claude Code to generate a customer migration converter. One attempt removes international prefixes; another preserves them but drops customers whose phone is empty. The team already knows the required destination record, so an architectural interview is unnecessary for this correction.
The developer sends the three pairs in the table, identifies the converter file, and states that all three outputs represent complete records. The message says to preserve the approved ID mapping and implement the same rule for other valid records rather than recognize these customer IDs. It also asks Claude to identify any source-value category the examples leave undecided before expanding the conversion policy.
The next review has a concrete basis: populated strings retain their prefix, normalized strings remain stable, and empty strings become null while the record survives. The developer asks Claude to run the agreed checks and show the output. If a later export contains an explicit null that still fails, use the specific reproduction technique in 3.5.3 rather than relabeling the entire transformation “wrong.”
Common exam traps
- Repeating “normalize correctly” when competing interpretations are the problem.
- Providing only inputs and expecting Claude to infer the required outputs.
- Choosing three nearly identical examples that leave the disputed branch untested.
- Treating an empty string, JSON
null, and an omitted field as interchangeable. - Accepting code that recognizes sample records instead of implementing the transformation.
- Assuming prompt examples replace evidence from a runnable check.
Where the exam guide differs
The exam guide asks for “2-3 concrete input/output examples” when descriptions produce inconsistent results. Anthropic’s prompting best-practices page recommends 3–5 examples for best results generally. This Bite uses three, satisfying both ranges. Read an exam item about inconsistent transformations as a choice to provide a small, varied set of explicit pairs; the guide’s count is not a product limit or a reason to reject an additional useful example.
What to remember
Show the input and the complete expected output, choose cases that separate plausible interpretations, and label them clearly. Examples clarify the contract; runnable checks verify the implementation. Keep unresolved source-value categories explicit instead of letting a few examples silently decide them.
Knowledge check
A developer has asked Claude Code three times for a function that converts legacy contact records, rewording the description each time. Each version handles phone prefixes and empty values differently. What is the most effective next step?
CLAUDE.md so every session reads themCLAUDE.md does not settle those choices; choosing among guesses still leaves the intended contract implicit.The approved contract for a contact migration renames customer_id to id, removes spaces from a populated phone while keeping its leading +, and maps an empty phone string to JSON null. Which three examples communicate it best?
+44 number, an already compact number, and an empty phone, each with its full output record+44 numbers for different customer IDs, each with its full output record+44 number, an already compact number, and an empty phone, each with only its output phone+44 numbers for different customer IDs, each given as input onlyid , which the contract keeps.Claude’s converter passes three approved pairs covering a spaced, a compact, and an empty-string phone. A new export contains records whose phone is JSON null, and the owner has not said how to treat them. What should happen before the converter is accepted?
null to the empty-string result the examples already shownull and add it as a fourth examplenull and add a pair with its expected outputnull is a different input from an empty string. An output Claude invents is a proposal until the owner accepts it, so the gap needs an owner rule and a pair showing it; more ordinary records leave the branch untested.References
- Anthropic, Prompting best practices
- Anthropic, Best practices for Claude Code
- Anthropic, Claude Certified Architect – Foundations Exam Guide