Español

Ask What Your Agent Didn't Touch

Ask your AI what it deliberately did not change. It's the most useful question you can put to a coding agent, and almost nobody asks it. You review what's in the diff — but the risk lives in what the agent quietly touched on the way past, or in what it decided to leave alone without telling you.

Scope creep hides inside a big green diff

Agents love to fix things you never asked about. You request a bug fix; you get the fix, plus a "while I was here" refactor, a reformatted import block, and a renamed variable three files over. Each edit looks reasonable in isolation. Together they turn a 20-line fix into a 300-line diff — and reviewer attention does not scale with it.

The data is blunt about what that costs. Defect-detection rates fall steeply as a change grows: reviews of small changes catch the large majority of defects, while reviews past ~400 changed lines find far fewer defects per line as fatigue sets in. Reviewer focus drops off sharply after about 60 minutes. A bloated diff isn't just annoying — it measurably hides bugs.

Make every change end with a summary

The fix is a standing instruction, not a one-off. Tell the agent that every change ends with three short lists:

The middle list is the point. "Changes made" restates the diff you already see. "Things I didn't touch" is the agent narrating the boundary it drew — the adjacent function it noticed was ugly and left alone, the config it chose not to migrate, the test it didn't update. That's exactly where uninvited renovation would have shown up, so its absence is the proof you wanted.

Drop it into your CLAUDE.md, AGENTS.md, or system prompt so it fires on every task:

End every change with three lists:
1. Changes made — file by file.
2. Things I didn't touch — nearby code left alone on purpose, and why.
3. Concerns — anything unverified or risky to follow up on.
Do not make changes outside the stated task without flagging them here.

Why it works

A "done" with no summary tells you nothing you can act on. A structured close-out turns the agent into its own first reviewer. The didn't-touch list surfaces scope creep before your human reviewer does, and it proves the agent stayed in its lane instead of renovating uninvited. The concerns list catches the honest "I couldn't run the tests" or "this assumes the cache is warm" that a confident-sounding agent otherwise buries.

It also composes with the small-diff discipline the research points to: one goal per change, and a close-out that names anything outside that goal. If the didn't-touch list starts filling up with things the agent did touch, that's your signal to split the task.

Power moves

• Make the reviewer read the list, not just the diff. If you run a review subagent, feed it the three lists and have it check the "changes made" against the stated task — anything in the diff but not in the list is unflagged scope creep.
• Turn concerns into tests. Every item in the concerns list is a candidate test or a follow-up ticket. Don't let it evaporate when the session closes.
• Watch the didn't-touch list grow. A short list means a focused change. A long one means the agent was tempted a lot — tighten the task or the prompt.
• Ask for it retroactively. Even on a change that's already made, "list what you deliberately left unchanged near this code, and why" pulls the boundary into the open before you merge.

Resources

• Best practices for Claude Code — one goal per change, and closing with what changed, what was verified, and what's uncertain.
• Code Review for Claude Code — reviewing diffs against the stated scope so nothing outside the task slips through.
• Does PR size actually matter? (cubic) — data on how defect detection falls as diffs grow.
• The impact of PR size on code review quality (Propel) — detection-rate breakdown by change size.
• Pull Request Size Matters (BSSw) — the classic ~200–400 LOC review guidance.