Reviewing a diff
Read in the right order, and look first for what you didn't ask for.
Reviewing What the Machine Produces
An agent's diff is hard to review, and for a specific reason: it's too well written. A hurried colleague's code contains clues: a sloppy name, indentation that jumps, a "TODO fix later" comment. These irregularities are signals that draw your attention to where the risk is. An agent produces uniformly polished text: the dubious workaround and the correct fix have the same typography, the same well-turned comments, the same confidence. Your usual anomaly detector no longer fires, and you approve a 300-line diff in four minutes, telling yourself it looks clean.
The second trap is reading order. Faced with a diff, the instinct is to start at the top of the first file and read straight through. With human code, that works well enough, because the author did what you asked, no more and no less. With agent code, it has you spend a long time on the expected change, the least risky part, the one you specified, and arrive tired at file number seven, the one you never mentioned and where the real problem lies. Effective review reverses the logic: first you look for what wasn't requested, and only then do you verify what was.
Comments
Comments are powered by GitHub Discussions
Sign in with GitHub to join the discussion