A code review process for AI-generated code
Generation got faster; review capacity did not. Most advice on reviewing AI-generated code is reviewer technique: what to look for in the diff. This page is about the team process: what to change when review volume outgrows the process that worked last year.
The problem: review volume outgrows review capacity
AI assistance increases the volume of code a team produces. Review capacity is a fixed number of human hours. When volume grows past capacity, the effects are measurable: review queues get longer, review depth drops, and a larger share of PRs is approved without discussion. Team understanding of the codebase declines as a result; that problem has its own page: comprehension debt.
"Review more carefully" is arithmetic that does not work: more care per PR times more PRs does not fit in the same hours. What has to change is the shape of the process: which PRs get deep review, what kind of review they get, and how big a batch a reviewer is asked to hold at once. Those are team decisions, and they need a way to get made, owned, and followed up.
How Aurora Coach addresses it
Aurora Coach runs a seven-stage improvement loop across six domains of team effectiveness: Foundation, Product, Engineering, Operations, Workflow, and Alignment. Review friction lands in the Engineering domain: code quality, testing, tech debt, AI-assisted development.
- Sense and Analyze Every team member contributes context. The pattern is inverted: the AI asks structured questions and the team responds, so review friction surfaces in the reviewers' own words. Quantitative signal comes from integrations like Aurora Coach for GitHub. The AI synthesizes that collective context into a SWOT and maturity assessment grounded in the team's actual situation, combined with industry best practices and academic research.
- Recommend, Refine, Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote; the team lead refines the recommendations to fit the team's reality. The AI never decides. The team commits to specific improvements, owned by the team and tracked through periods. A review process change stops being a retro note and becomes a commitment.
- Execute and Re-evaluate The team does the work in its own context, alongside delivery. Next period's analysis sees what changed: progress is visible against previous commitments, the loop continues, and context compounds.
Free-text check-ins keep context flowing between sessions. Review is one process; the method is general, and that is what continuous improvement software is for.
Example commitments
Three examples of what a team might commit to. Starting points to adapt to your context, not a checklist to install:
- Risk-based review routing. The team defines which changes need deep human review (for example auth, data models, public interfaces) and which can pass with tests, static analysis, and a lighter check.
- Reviewer WIP limit. A cap on concurrent open reviews per reviewer, at a limit the team picks; new requests queue instead of piling up.
- Small-batch rule for agent output. A maximum diff size the team picks; bigger work lands as stacked, individually reviewable PRs.
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, not an individual choice. Tests and static analysis cover more of the correctness question than they used to; the scarce thing a human reviewer adds on an AI-authored diff is comprehension: does someone on this team understand what this does and why. This is where the review process connects to comprehension debt: the explain-back review described on that page is the review commitment that addresses it.
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 no human understands the diff, the review process has passed on its costs to your future selves, whoever approved it.
If review is where your AI gains are stalling, MapROI turns that bottleneck into a tailored ROI analysis: free, no signup, about 5 minutes.