A code review process for AI-generated code
Your reviewers approve more code than they can read, and everyone on the team knows it. Most advice on this is reviewer technique: what to look for in the diff. This page is about the process around the diff, and who gets to change it. Three commitments to copy, free, then a worked example of a team turning its review queue into changes it owns.
The process was built for last year’s volume
An agent drafts a change faster than anyone can read it, and the reading is the part that did not scale. The extra volume lands in the queue and waits. LinearB’s 2026 benchmarks measured agentic-AI pull requests waiting over five times longer for first review than human-written ones.
Depth goes with the wait: fewer comments per change, more approvals with no discussion at all. What has to change is the shape of the process itself, and that is a set of team decisions. They need a way to get made, owned, and followed up.
Reviewing harder is not a plan. Something has to decide where the human hours go.
Three review-process commitments, free
Each one is a decision a team can make in a single retrospective and hold for a sprint. Starting points to adapt, not a checklist to install.
- Risk-based review routing Write down which changes need deep human review and which can pass on tests, static analysis, and a lighter check. Build the deep list from your last ten incidents rather than from first principles; in most codebases it lands on auth, data models, and public interfaces. What the deep tier holds back is comprehension debt.
- Reviewer WIP limit Cap how many reviews one person holds open at once. Count open requests per reviewer for a week first, then set the cap under what your busiest reviewer carries today, so requests above it wait in a queue everyone can see instead of landing on the same person.
- Small-batch rule for agent output Set a maximum diff size for agent-generated changes, and find it in your own history: the size above which comments per pull request fall off is the size above which review stopped happening. Bigger work lands as stacked, individually reviewable pull requests.
Any of the three works on a whiteboard. Whether it survives the next sprint depends on the team choosing it and something tracking it, which is what continuous improvement software is for.
Why is code review the bottleneck with AI-generated code?
Because generation scaled and review did not. AI assistance increases the volume of code a team produces, while review capacity is still a fixed number of human hours. The effects are measurable: longer review queues, fewer review comments per change, and a larger share of approvals without discussion. The constraint moved from writing code to understanding it.
Should AI-generated PRs be reviewed differently than human-written ones?
Yes, and that is a process decision rather than an individual choice. Tests and static analysis cover more of the correctness question than they used to. What a human reviewer adds on an AI-authored diff, and nothing else does, is comprehension: someone on this team can say what this code does and why it was built that way.
Can we just use an AI reviewer to review the AI's code?
AI review helps. It catches real defect classes at low cost and belongs in the pipeline. What it does not produce is team comprehension, and comprehension is what pays off during debugging, incidents, and the next change to that code. If nobody on the team understands the diff, the cost has not been avoided. It has been moved to whoever debugs it next.
From review queue to commitments: a worked example
Simulated team · Real product output The seven-person platform team at Vantora Labs, a fictional Series B SaaS, has agentic coding tools funded for everyone, with merged pull request volume roughly tripled while review capacity stayed flat. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Every team member answers structured questions in their own words, and can take any thread further in a check-in conversation with the coach. Vantora ran four sessions, and three of them describe the same review queue from a different chair.
The lead: capacity did not triple
Marta puts the numbers in and asks what teams actually change about the process. The coach names it first: “you've optimized one part of the system (authoring) without adjusting the constraint that moved (review capacity).” Then three process changes, not a plea to try harder: review depth tiered by risk because not all PRs carry the same, automated checks that absorb the routine work so human review goes to architecture and logic, and a brief author walkthrough for complex AI-assisted changes so context arrives before review starts.
The reviewer: eleven open, one 900-line diff
Tomas asks for a third option between reading it properly and approving it unread. He gets a number: at Vantora, agent-generated changes over about 200 lines get broken down before review or arrive with a written explanation, and the human who submitted the change writes it. The commitment list above could not have told him 200. That number exists because this team's own review history produced it.
The junior: approving what you cannot judge
Aisha approves when every other queue is overflowing and the tests are green. First sentence back: “That's not code review, that's queue management.” Then the fix goes to capacity rather than to her: say you do not have enough context on this part of the system, and tag someone who does, so the shortage shows up as a queue instead of as an approval.
2Recommend, refine, commit
The analysis becomes concrete suggestions the team votes on and commits to. The AI informs the decision, it does not make it.
Buying back the hours
The cheapest tier of routing, made concrete: move style enforcement out of human review entirely. One success metric is “zero style-related comments in code reviews, freeing reviewers to focus on logic and design”, which is the same fixed-hours argument this page opens with. Read the Context field: it argues from this team's own scores, coding standards and readability both at two of five, not from a template.
3Execute and re-evaluate
The team runs the change in its own context, and the next analysis reads the commitments against what happened: queue time, review depth, what got sent back. Vantora has run one period, so the trend view starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the three review-process commitments above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.