Reviewing AI-Assisted Code Changes

I'm not reviewing code. I'm reviewing a change in system behaviour.

The bigger the AI-generated change, the more effort goes into reviewing intent and edges, not lines of code.

Keep changes small and incremental whenever possible. That's the single best thing you can do for review quality.

Small change (minimal risk)

~1 to 5 files, ~10 to 100 lines. Renames, formatting, tidy-ups. No behaviour change intended.

1. What is the one thing this change is meant to do?
2. Does the diff match that intent?
3. Were any new branches, defaults or fallbacks added?
4. Did auth, env vars, network calls or data writes change?
5. Was any error handling added or loosened?

If it looks mechanical and behaves the same, suggest approve.

Medium change (some risk)

~5 to 20 files, ~100 to 400 lines. Helpers added, logic reshaped. Behaviour should mostly stay the same.

1. What is supposed to change and what must not?
2. Are permissions or validation wider than before?
3. Are errors still visible and logged?
4. Do defaults still make sense?
5. What happens with empty, invalid or missing input?
6. What happens if a dependency fails?
7. If this breaks, how would I notice?

Always run negative tests here.

Large change (high risk)

~20+ files, ~400+ lines. Bulk AI edits or new flows. Direct production impact.

1. Which parts are high-risk (auth, data, config, infra)?
2. What must never change as a result of this PR?
3. Did AI "helpfully" widen behaviour or hide failure?
4. Are any errors being swallowed or turned into defaults?
5. Are retries, timeouts or fallbacks hiding problems?
6. Do I still trust the logs and alerts?
7. What would a 2am failure look like?
8. Is rollback or staged rollout in place?

If you don't trust it, slow down.

Key takeaway

You are not reviewing code. You are reviewing a change in production behaviour. Match the depth of review to the size of the change.