Reviewing code when half the diff was written by an agent

The bottleneck moved from writing to reviewing, and the old review habits do not scale to it. Four gates that keep quality without turning one senior engineer into a queue.

The first thing that happens when a team adopts coding agents is that pull requests get bigger and more frequent. The second thing is that review quality silently drops, because a reviewer facing an eight-hundred-line diff that looks plausible does what humans do: skims, trusts, approves.

That is the risk, and it is not about the agent writing bad code. Agent-written code tends to be syntactically clean, conventionally formatted and well commented, which defeats every heuristic reviewers built up over a decade for spotting where to look.

Gate 1: agree the approach before the code exists

The cheapest review is of a plan. Two paragraphs: what is changing, which files and interfaces are affected, what is explicitly out of scope, how it will be verified. Reviewed in three minutes, before an hour of generation.

This kills the worst failure mode — a large, internally coherent change built on a premise nobody agreed with. Once the code exists, that conversation costs a rewrite, and there is a real psychological pull to accept working code rather than throw it away.

Gate 2: the machine checks go first, and they are non-negotiable

Tests, types, linters, a build, a security scan. None of this is new; what changes is that it now has to be genuinely blocking, because the volume of change has outrun the reviewer's ability to catch what the tooling catches for free.

Two additions worth making specifically for agent output: a check that new dependencies were declared and justified — agents reach for a package where three lines would do — and a check on test quality, not just presence, because a suite that asserts the implementation rather than the behaviour is worse than no suite. Tests that were written by the same process that wrote the code prove less than tests written against the specification, so the one thing a reviewer should read line by line is the assertions.

Gate 3: the author states what they verified

The pull request description has to include a line the human wrote: what they ran, what they checked by hand, and what they are unsure about. "Ran the integration suite, checked the migration on a copy of staging, unsure about the retry logic in the third commit" directs the reviewer's attention better than any automated summary.

This also restores accountability. The person who submits the change owns it, whatever wrote it. Making that explicit in the template is a small act with a large cultural effect: it prevents "the agent wrote it" from becoming an available answer in an incident review.

Gate 4: review by risk, not by line count

Split the diff mentally into three buckets and spend accordingly.

Interfaces and contracts — API shapes, database schemas, public function signatures, anything other systems depend on. Read every line. Mistakes here are expensive and permanent.

Business logic and edge cases — the conditions, the error paths, the money arithmetic. Read carefully; this is where confident wrongness lives.

Mechanical bulk — the two hundred call sites updated by the same transformation, the generated boilerplate, the formatting. Sample it. If ten of two hundred are right, the other hundred and ninety are almost certainly right too, because the failure mode of a mechanical change is systematic, not random.

That last point is the one that makes large agent diffs reviewable at all: uniform changes fail uniformly, so sampling actually works, in a way it does not for handwritten code.

What we track instead of line counts

Defect rate after merge, per change, and how long a change waits in review. If the second number is climbing, the team is generating faster than it can absorb, and the fix is smaller changes rather than faster reviewers. Agents are very good at splitting work into three sequenced pull requests if you ask, and nobody asks.

What to do this week

Add two lines to your pull request template: "How I verified this" and "What I am least sure about". It costs the author thirty seconds and it is the highest-return change we have made to review practice since agents arrived.

ConsultorIA

Want this done on your cloud?

A ten-day read-only assessment is free, and Skyline lets you see your estate on a map before you write to us.

Related articles