When AI writes most of the diff, code review becomes the bottleneck, and the fix is a review process built for volume rather than reviewers who read faster. Smaller PRs enforced by tooling, a written intent block from the author, automated checks that clear the mechanical issues before a human looks, and a daily review budget per engineer. Reading faster doesn't scale. Reading less, and better, does.
Why does review load explode?
Because generation capacity went up and review capacity did not. An engineer with a coding agent produces three or four times the diff volume they used to, while the number of hours a reviewer has in a day stayed exactly the same. The queue absorbs the difference until somebody starts skimming.
Skimming an AI-written diff is worse than skimming a human one, because the code looks confident and idiomatic even when it's wrong. Fluent bugs. Those are the ones that reach production, and it's exactly why more AI code needs a heavier QA layer, starting with review itself.
What we require in every AI-assisted PR
Every AI-assisted pull request carries four things before a reviewer opens it: an intent block, a verification checklist the author signs, a size under the cap, and tests in the same change. The author does more work up front so the reviewer does less, which is the whole trade.
- An intent block at the top of the description: what this changes and why, then what it deliberately leaves out. Three short paragraphs at most.
- A verification checklist the author ticks honestly: ran it locally, added or updated tests, read every line of the diff, and can explain any file touched outside the ticket's scope. "The agent added a helper in a file I never opened" is a common finding and a red flag.
- A size cap. Ours is around 400 changed lines. Bigger than that, split it or stack it. The tooling rejects the PR, so it never becomes a negotiation.
- Tests in the same PR, and a note on what the tests don't cover.
None of this is anti-AI. Use whatever tool you like to write the code. The PR is still your claim that it's correct.
Which checks run before a human reads a line?
Everything mechanical runs first: lint, type checks, the test suite, coverage delta, dependency diff, secret scanning, and a generated summary telling the reviewer where the risk sits ("touches auth middleware and two migrations"). By the time a person opens the PR, what's left is judgment: does this design hold up, and what happens when it fails.
| Layer | Who runs it | Blocks the merge? |
|---|---|---|
| Lint, types, tests, coverage delta | CI | Yes |
| 400-line size cap | The tooling, automatically | Yes |
| AI first-pass review | A bot, before review is requested | No |
| Does this design hold up | A named human via CODEOWNERS | Yes |
That AI first-pass reviewer has one firm rule: its comments are suggestions the author resolves before requesting review, never blockers and never a substitute for the human. It's good at catching the missing null check and terrible at knowing whether the change should exist at all.
How do you protect reviewer time?
Give review an explicit budget. Two hours a day per engineer, and after that the queue waits until tomorrow. Route risky paths through CODEOWNERS to the people who know them, let anyone review the rest, and track two numbers: time to first review, and the PR size distribution.
If sizes creep up, the cap isn't being enforced. Our own failed experiment: for a while we tried "everyone reviews everything" to spread knowledge. Time to first review went past three days and people rubber-stamped to clear the queue. Knowledge didn't spread anyway, because skimming teaches nothing. Small PRs plus rotating ownership worked better on both counts.
At Shanti Infosoft this is now the standard across our engineering teams, and it's the first process we rewrite when a software consulting engagement starts with "our velocity went up and our defect rate went up with it." The interesting side effect is that PR quality from human-only authors went up too. The intent block and the size cap were always good practice; the volume forced us to enforce them.
How long does a PR sit in your queue before someone reads it properly, and do you know that number or are you guessing?
Sagar Jain is the technical co-founder of Shanti Infosoft, which has delivered software for 700+ companies and reviews a great deal of machine-written code every week.
Top comments (0)