Reviewing an agent’s diff before you merge it

Read the diff, not the summary

An agent’s own description of what it did is a claim, not evidence. Start with the diff and read it as you would read a stranger’s pull request, because that is what it is.

The first pass is structural: how many files, which ones, and does that match the task. A change that touches forty files to fix a bug is not a fix, it is a rewrite you did not ask for.

What agents get wrong most often

• Tests that assert the new behaviour instead of the intended one — a test written to pass rather than to catch.
• Silent fallbacks: a caught error that returns a default, turning a failure into a wrong answer.
• Deleted code that was load-bearing, because nothing in the repository said why it was there.
• Widened scope: unrelated formatting, renamed variables, an upgrade nobody asked for.
• Comments and docs that describe the previous behaviour, because they were not reread.

Do it before the merge

Reviewing after the merge is not review, it is archaeology. The value of a branch is that it can be sent back for another pass without touching what everyone else is working on — which is why the worktree model and the review habit are the same idea seen twice.

A useful default: never merge a session that ran unattended without reading its diff end to end once. Not skimming. Once, properly. It takes a minute and it is the whole reason the rest of the workflow can run fast.