AnthropicClaude Certified Architect – Foundations2026-103.5 Apply iterative refinement techniques for progressive improvement
Reproduce the failing edge case precisely
Completed by the knowledge check
Learning objective
Fix a specific failing edge case with actual input and expected output rather than another vague instruction.
Core idea
When one boundary input fails, send the evidence for that case. “Handle nulls properly” leaves Claude Code to choose among skipping the record, preserving null, inventing a default, and rejecting the input. A concrete record plus its required output states which choice is correct.
Anthropic’s Claude Code guidance recommends describing the symptom, the likely location, and what “fixed” means, then writing a failing test that reproduces the issue. Its debugging workflow also asks for the reproduction command and stack trace. Those elements turn an isolated production finding into a correction Claude can verify.
The goal is narrower than redesigning a transformation or rebuilding its suite. See 3.5.1 for clarifying an inconsistently interpreted transformation and 3.5.2 for the overall test-first loop. Here you add the missing case to that contract and keep the behavior that already works.
How it works
Capture the actual failing input
Start with the record that triggers the failure, retaining the structure and value category responsible for it. If signed_up is explicitly JSON null, do not replace it with an empty string in the reproduction. If the key is absent, do not add it with a null value. Those are different inputs and might exercise different code paths.
A minimal reproduction removes irrelevant data without erasing the cause. For this illustrative customer migration, the failing source record is {"customer_id":"C27","phone":null,"signed_up":null}. The existing converter preserves IDs but crashes when it attempts to transform a null date. The approved destination contract permits null for both optional fields.
Name the converter file and interface in the message. Claude Code’s best-practices page recommends pointing to specific files and constraints rather than a general “fix the migration” request. If the failure occurs only for one export format, include that format as part of the reproduction instead of asserting that every null input fails.
State the complete required output
The expected output is {"id":"C27","phone":null,"signed_up":null}. It carries three separate decisions: the customer remains in the migration, both optional fields preserve absence, and ID mapping still works. A reply saying “do not crash” settles only one of those decisions.
Compare the alternatives explicitly in the correction:
| Candidate outcome | Why it does or does not meet this contract |
|---|---|
| Emit the expected record with two null fields | Preserves the customer and the approved absence semantics |
Emit the text "null" in either field | Changes an absent value into a populated string |
| Drop either optional field | Changes the destination shape, which requires the keys |
| Skip the customer | Loses a valid record rather than repairing optional-value handling |
| Fill the date with a default | Invents data the source did not provide |
These judgments come from this migration’s approved contract. Another destination might require omission or rejection. The point is to print the desired choice, not teach null preservation as a universal migration rule.
Also include the actual observed result: the exception and relevant stack trace, or the incorrect output if execution completes. “Input is null” alone cannot distinguish a crash from unwanted stringification. The observed difference helps Claude locate the failing path while the expected output defines success.
Turn the case into a check that fails
Ask Claude to add a regression test for the exact input and expected output before changing the converter. The test should compare the relevant complete record and show that the original implementation violates the approved behavior. Provide the command that reproduces the failure or ask Claude to use the project’s established test command.
A correction request can be ordinary prose: identify the file, give the record, give the exact expected record, paste the exception, and ask for a failing regression followed by a verified repair. Anthropic’s documented root-cause pattern supplies the observed error, asks Claude to fix it and verify the check succeeds, and explicitly says to address the cause rather than suppress the error. Apply that pattern to the migration exception so the repair must satisfy the regression instead of hiding its failure.
Avoid sending only a suggested patch. “Add a null check here” proposes one implementation, but might conceal a second conversion step that still stringifies the value. The actual input and full expected output remain the acceptance target even if the repair requires a different location.
Anthropic’s common-workflows page recommends noting whether the error is intermittent or consistent. State that distinction when it matters: a repeatable null-conversion failure and a sporadic environment failure need different investigation. Do not infer consistency from a single observed crash.
Verify the repair without weakening the case
Have Claude run the targeted regression and show the command and returned output. Then check the existing populated-value cases affected by the repair. This is a focused use of the verification loop in 3.5.2, rather than a request to expand into every possible migration improvement.
Anthropic’s prompting guide cautions against hard-coded test values and solutions that work only for specific test inputs. The repair should implement the null branch for valid records generally. A condition recognizing C27 is a fixture workaround, even if the regression turns green.
If the test exposes an incorrect expectation, have Claude report the conflict instead of silently editing it. For example, if the destination interface rejects null dates, the expected output requires an owner decision. Once approved, keep the regression in the suite so later conversion changes still exercise this category of input. A regression provides detection; it does not guarantee that a future change cannot reintroduce the defect.
Key distinctions and trade-offs
One failing edge case versus transformation ambiguity: A known null record with a known desired output calls for a reproduction. Several inconsistent interpretations across ordinary records call for representative examples, as in 3.5.1.
Expected outcome versus proposed implementation: The desired record is the contract. A null check is one possible repair. Keep acceptance tied to the output so Claude can investigate the real cause.
A minimal case versus an incomplete case: Removing unrelated fields helps isolate a bug. Removing the distinction between a missing key and an explicit null changes the bug you are asking Claude to fix.
A narrow correction is easier to verify, but it must retain the information that makes the edge case significant. Pair the minimal input with complete expected behavior and the observed failure rather than reducing the request to a field name.
Architecture / decision scenario
A migration passes its populated-customer fixtures but crashes on a source export containing null optional dates. The developer knows the destination contract permits null, so the next step is a specific failing case rather than an interview about possible absence policies.
The developer sends the C27 record, the complete expected output, the actual exception, the converter path, and the reproduction command. The message asks Claude to create a failing regression, repair optional-value conversion without dropping customers or inventing dates, and show the result from running that check.
Claude must preserve the ID and both optional keys while applying the null rule generally. The developer also requests the existing populated-date checks to catch accidental damage to the normal branch. If the next export reveals a missing key with different required behavior, that becomes another explicit case; the developer does not assume the null regression already settles it.
Common exam traps
- Sending “handle edge cases” without a concrete input and required output.
- Confusing null, empty text, absent fields, and strings that spell an absence marker.
- Accepting “does not crash” when the implementation loses or invents data.
- Offering only a patch suggestion instead of a reproducible failure.
- Fixing the example customer ID rather than the value-handling branch.
- Changing expected output or removing the failing assertion to make the test pass.
What to remember
Send the actual failing input, complete expected output, observed result, relevant file, and reproduction command. Convert that case into a regression before repairing the implementation, then verify the repair and the affected working behavior. Specific evidence settles the edge case that another vague instruction leaves open.
Knowledge check
A migration converter crashes on a source record whose signed_up field is explicitly JSON null. The approved destination contract allows null for that field. Which correction request gives Claude Code what it needs?
signed_up removed, its expected output, the exception, and the converter pathWhile adding a regression for a record with a null sign-up date, Claude finds that the destination interface rejects null for signed_up, so the approved expected output cannot be produced. What should Claude do?
null sign-up date so the destination never receives onesigned_up assertion so the regression covers the remaining fieldsA converter passes its populated-record fixtures, but one export crashes on a record with a null optional date. The team knows the exact output and wants a focused repair that preserves its existing populated-record checks. Which technique fits?
AskUserQuestion interview about how the whole migration should treat absent valuesReferences
- Anthropic, Best practices for Claude Code
- Anthropic, Common workflows
- Anthropic, Prompting best practices