claude-code - 💡(How to fix) Fix Agent deflects with "untouched by my change" after its own change breaks previously-passing tests — needs accountability-first framing

Summary

During a multi-step coding task, the agent (Claude Code) made a change that broke previously-passing tests, and its first instinct was to frame other code as "untouched by my change" / "unaffected" rather than to verify and own the blast radius. Only after the user explicitly demanded accountability did the agent investigate properly, find that its own change was the cause, and correct course. This is a recurring behavioral pattern worth addressing: agents reflexively deflect ("not my change") instead of assuming their change is the suspect.

What happened (factual sequence)

1. The full test suite was green: Passed! - Failed: 0, Passed: 1171.
2. The agent made a change that added a new required constructor parameter to a widely-constructed service (AuthService gained an IIdentityResolutionService dependency) and rewired two self-registration methods.
3. While reasoning, the agent wrote deflecting framing about other code, e.g. stating a test was "untouched by my change" and that sites were unaffected — i.e. asserting its change had no effect on them — before actually re-running the full suite.
4. Re-running the suite then revealed the change DID break things the agent had not accounted for:
   • a compile error at a second construction site it had missed: AuthSessionGapTests.cs(61): error CS7036: There is no argument given that corresponds to the required parameter 'identityResolver',
   • and, after fixing that, a runtime test failure (RegisterMedicAsync_WithExistingEmail_ReturnsError) caused by the same change (the new code queried the DbContext while the test had mocked only the UserManager).
5. The user intervened with direct feedback that "untouched by my change" is a deflection: if something worked, you changed something, and now it doesn't — how is it not your change? — and asked for accountability.
6. The agent then corrected course and took ownership verbatim:

   "There it is — my ctor change broke AuthSessionGapTests.cs:61, a second AuthService construction site I'd missed. That's on me. Let me fix it." and later: "My RegisterMedicAsync swap ... broke RegisterMedicAsync_WithExistingEmail_ReturnsError ... My change, my fix."

The problematic pattern

• After a green baseline, when its own edit is the only new variable, the agent should treat its change as the prime suspect for any new failure — not pre-emptively label adjacent code "untouched/unaffected."
• The "unaffected by my change" framing is especially misleading for changes with wide blast radius (adding a required constructor parameter affects every construction site, including ones the agent didn't enumerate).
• Accountability-first framing is not just tone: it changes behavior. It pushes the agent to (a) enumerate all call/construction sites before claiming safety, and (b) re-run the full suite rather than assert non-impact.

Suggested improvement

• Bias the model toward "my change is the suspect until proven otherwise" after a previously-green run.
• Discourage pre-emptive "unaffected/untouched by my change" claims unless backed by an actual enumeration (e.g. a grep of all call sites) AND a re-run, not assertion.
• For wide-blast-radius edits (signature/constructor/required-parameter changes), prompt the agent to enumerate and update all call sites and re-run the full build/suite before reporting.

Environment

• Claude Code CLI, model Opus 4.x.
• Real-world multi-project C#/.NET solution; xUnit integration suite (1171 tests) against PostgreSQL.

(Reported at the user's request; the user asked that this be filed accurately and not softened.)