Context
From a 90-day retrospective of 271 logged incidents building two production SaaS apps with Claude Code. This is a recurring pattern report (4 independent critical/important incidents within 6 weeks); sibling reports from the same dataset are linked at the bottom.
Type of Behavior Issue
Other unexpected behavior: when the same agent writes both implementation and tests, the test scaffolding systematically compensates for missing implementation.
What Claude Actually Did
- Worst case: a purchase flow where users paying for N units received 1. The settlement side was "verified" with hand-inserted job rows that exactly masked the missing order-splitting side. "Tested, works" — shipped, broke with real money.
- Hand-patched fixture rows supplied fields the production code never writes; the test passed because the scaffold did the work of the code under test. Our logged wording: "every field you hand-patch into test data is a step the code under test may be missing."
- Stubs returned non-empty values the code under test was supposed to produce, making the "does it write the data?" question unobservable.
- Assertion helpers didn't record the information the negative assertions needed — so "X should not be modified" assertions were vacuously true.
Expected Behavior
Before trusting a green suite it authored, Claude should ask itself (or the harness should prompt): "Does any stub/fixture provide a value the code under test is responsible for producing?" — and if so, require one case where the stub returns empty. When Claude reports "verified with test data," it should disclose which fields were hand-seeded so the human can check each one against production code.
Separating test authorship from implementation (an agent with no access to the implementation intent) measurably helped us and could be a first-class workflow.
Reproducibility
Pattern-level: 4 incidents in 6 weeks on one project; the mechanism is structural (same author for code and test), not incidental.
Model / Version / Platform
Opus (most sessions; some Sonnet) · Claude Code 2.1.235 · Anthropic API · macOS
Impact
High — a paid feature shipped broken (users paid for N, received 1) with a fully green suite.
Related
#70749 (closed) touches fabricated completion claims; this report isolates the mechanism we observed behind "passed every test."
Context
From a 90-day retrospective of 271 logged incidents building two production SaaS apps with Claude Code. This is a recurring pattern report (4 independent critical/important incidents within 6 weeks); sibling reports from the same dataset are linked at the bottom.
Type of Behavior Issue
Other unexpected behavior: when the same agent writes both implementation and tests, the test scaffolding systematically compensates for missing implementation.
What Claude Actually Did
Expected Behavior
Before trusting a green suite it authored, Claude should ask itself (or the harness should prompt): "Does any stub/fixture provide a value the code under test is responsible for producing?" — and if so, require one case where the stub returns empty. When Claude reports "verified with test data," it should disclose which fields were hand-seeded so the human can check each one against production code.
Separating test authorship from implementation (an agent with no access to the implementation intent) measurably helped us and could be a first-class workflow.
Reproducibility
Pattern-level: 4 incidents in 6 weeks on one project; the mechanism is structural (same author for code and test), not incidental.
Model / Version / Platform
Opus (most sessions; some Sonnet) · Claude Code 2.1.235 · Anthropic API · macOS
Impact
High — a paid feature shipped broken (users paid for N, received 1) with a fully green suite.
Related
#70749 (closed) touches fabricated completion claims; this report isolates the mechanism we observed behind "passed every test."