Reviewing AI-written diffs

Agentic tools usually give you a plain-language summary alongside the actual diff — "added a health check endpoint and a test for it." The summary is a starting point, not a substitute for the diff itself. Summaries can be accurate about intent while missing a detail that matters: an off-by-one, a changed default value, a dropped edge case. Skim the summary to orient yourself, then read the actual lines that changed.

1. Does this match what I asked for — and nothing more? Agents occasionally do more than requested ("while I was in there, I also refactored X"). Extra changes aren't automatically bad, but they're extra surface area you didn't plan to review, and they should be called out, not buried.
2. What happens on the edge cases? Empty input, a network failure, a missing field, a huge input. If the task involved data or user input, check whether the diff even considers these — many first-pass agent solutions handle the happy path well and skip edge cases unless explicitly asked to cover them.
3. Would I have written it this way? Not "is it wrong" but "is it consistent with how the rest of the codebase does this." Style and pattern inconsistency compounds over time even when each individual diff is technically correct.

The diff an agent produces is a normal diff — review it the same way you'd review a colleague's pull request: read it in your editor's diff view, run the linter, run the full test suite (not just the one test the agent added), and if your team uses code review, put it through the same process before merging. Agentic tools don't need a parallel review process; they need the one you already trust to keep working.

If a diff is mostly right but has one clear issue, it's often faster to tell the agent what's wrong and let it revise ("this doesn't handle an empty list — add that case") than to hand-edit around it, especially because the agent has the full context of why it wrote things the way it did. Save manual edits for small, obvious fixes where writing the correction is faster than describing it.

Because the underlying model always produces fluent, confident-sounding text, a wrong diff doesn't look uncertain — it looks exactly as polished as a right one. This is the same failure mode covered in the "why AI makes mistakes" lesson, applied to code: fluency is not a signal of correctness. The antidote is the same here as anywhere else in the curriculum — verify against something external (tests, actual execution, your own read of the logic), not against how convincing the explanation sounds.

Reviewing agent diffs gets faster with repetition, the same way code review does. Early on, read everything closely. Over time, you'll develop a sense for which kinds of tasks (a well-scoped bug fix with a test) tend to produce clean diffs on the first try, and which (broad refactors, ambiguous requirements) tend to need a revision round — and you can calibrate how closely you review accordingly.