A repeatable loop for reviewing AI-written code
Reading a large diff top-to-bottom is the slowest way to review it. Here's an order of operations that catches more in less time.
AI assistants have made writing code cheap and reviewing it expensive. The bottleneck moved, but most people’s review habits didn’t. Reading a 400-line diff from top to bottom is the worst available strategy: attention is highest at the start, and the risky code is rarely at the top.
What follows is an order of operations that front-loads the checks with the best return.
1. Read the diffstat before the diff
git diff --stat mainYou’re looking for surprises in shape, not content. A task that should have touched three files touching eleven is a signal worth resolving before you read a single line. Files you didn’t expect are where scope crept in.
2. Check what was deleted
git diff main -- . | grep '^-' | grep -v '^---'Additions get scrutiny by default because they’re the visible output. Deletions slip through — a dropped null check, a removed early return, a test that was “simplified”. When an assistant is optimising for a passing build, deleted constraints are a common casualty.
3. Verify the interfaces, trust the bodies — initially
Check every function signature, type, and public API touched by the change. These are the things that are expensive to change later and that propagate errors outward. Implementation bodies can be verified by tests; a wrong interface poisons everything downstream of it.
4. Run it before you finish reading
The single highest-value action. Not the test suite — the actual thing:
npm run build && npm run testStatic review is bad at catching what’s missing. Execution isn’t.
5. Ask for the reasoning, not the summary
Don’t ask “what does this do” — you can read that. Ask:
What did you consider and reject here, and why?
The rejected alternatives tell you whether the constraints were understood. An assistant that can’t name a tradeoff it made probably didn’t make one deliberately.
Things that should always stop the review
- A new dependency you didn’t ask for. Check it exists and is maintained.
- A changed test assertion. Tests get edited to pass far more often than they get edited to be correct.
- Broadened error handling — a
try/exceptthat swallows more than it did before is a bug that will surface much later, somewhere else. - Confident comments on subtle code. Certainty in a comment is uncorrelated with correctness in the line below it.
The underlying principle
Spend your attention where being wrong is expensive and where verification is hard. Tests and execution handle the rest more reliably than your eyes do at line 300 of a diff.