whybother

Field Guide 路 10 of 10

Why AI-generated code gets approved without review

“LGTM” takes a second to type and a large diff takes far longer to read. When an agent writes thousands of lines in minutes, the pressure to approve instead of read grows with the diff. This failure is the reviewer’s, not the agent’s: the agent only made approval cheaper than review. The defence is to make unreviewable diffs hard to merge and to make approval something one person cannot give to their own work.

What is actually happening

Review used to be paced by writing. A person wrote a diff slowly enough that another person could read it in the time it took. An agent breaks that pairing. The size of a change is no longer limited by what anyone can read, and the reviewer faces more code than the author did.

Under that pressure approval becomes a ritual: zero comments, zero questions, one merge. The skit has a /lgtm command that does it for you and a /review that claims 4,812 lines read in 0.3 seconds. Both are jokes about a real shortcut. Nothing the agent did caused the approval. A person pressed the button, or a tool pressed it for them.

An approval says that a person understood this change. When the person did not read it, the statement is false, and everything after it inherits the falsehood: the merge, the deploy, the status page. A second pass by another agent can be a useful extra check. It is not a person understanding the change, and it cannot sign in their place.

The agent is the wrong place to look for the fix. It will write the approval if you ask it to. The controls that work are the ones that do not depend on anyone’s mood that day: smaller diffs, a second person, and rules enforced by the system.

How it shows up in the review

LGTM 路 0 comments 路 0 questions 路 1 merge
files changed    37
lines changed    4,812
approved by      the author
merged           2 minutes after the push

This is an illustration, not the output of any platform.

Guardrail

The instruction cannot do the reviewing, but it can stop the agent from claiming it was done.

Paste into AGENTS.md

Do not approve, merge or describe your own work as reviewed. End every change with what you could not verify and where a person should look first.

Check it mechanically

# CI step. Assumes the base branch is main and the history is fetched.
base=origin/main
changed=$(git diff --numstat "$base"...HEAD -- . ':!package-lock.json' | awk '{ n += $1 + $2 } END { print n + 0 }')
if [ "$changed" -gt 400 ]; then echo "$changed lines changed (limit 400): split it"; exit 1; fi

The check adds up the added and deleted lines on the branch and fails above the limit, naming the total. A small branch, or one with no changes, prints nothing and exits 0. Binary files count as zero. The pathspec ':!package-lock.json' leaves one lockfile out, because a lockfile or any generated file can swamp the count; add one pathspec per file or folder to exclude. If origin/main is missing, git prints an error and the check still passes, so fetch first. The number 400 is a placeholder; pick yours, and the value of picking it is that a decision exists before the diff does. It reads commits only, so uncommitted files are not counted.

The check bounds the size of a review. It cannot see whether one happened. For that, use the controls your hosting platform offers, if it offers them: required approvals from someone other than the author, and no direct pushes to the main branch. Then ask the question that only a person can answer. The checklist asks that someone who did not write the change read it and asked at least one question. A diff with no question in it may have been approved by a hand rather than a reader.

Further reading

Software Engineering at Google, chapter 9: what code review is for, beyond catching defects. Approval means a person understood the change.