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.
Why AI-generated code breaks the review process
AI assistance multiplies the volume of plausible-looking code a team produces. Review capacity is still a fixed number of human hours. A process designed for human-paced authorship quietly stops working: queues grow, depth drops, approvals become rubber stamps. Velocity still looks fine, so the failure is quiet: understanding leaks out of the system one LGTM at a time. The leaked understanding 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 commitments a team might make. Examples to adapt, not best practices:
- Comprehension review for AI-authored PRs. The reviewer explains the diff back before approving; approval means understood, not just plausible.
- 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 multiplies the volume of plausible-looking code a team produces, while review capacity is still a fixed number of human hours. A process designed for human-paced authorship quietly stops working: queues grow, depth drops, and approvals become rubber stamps. 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. Routing AI-authored PRs to an explain-back review instead of line-by-line correctness review is a testable change with a measurable outcome.
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.