AI Code Review at Scale

Why Review Changes

Pull request volume rises while authoring time falls. Reviewers get more pull requests with less insight into the author's reasoning, because the code was generated rather than deliberately written line by line. The risk is not that AI-generated code is always bad. It is that review depth declines exactly as volume climbs, and a process built for a smaller, slower flow of hand-written diffs quietly stops working.

AI as a Review Layer

Use an AI reviewer as a first pass, not a final one. It should catch formatting, naming, common anti-patterns, and basic security flags, and produce a PR summary and a risk classification for the human who reviews next. The value is noise reduction for human reviewers, not a replacement for judgment.

• Label every AI-generated comment as automated, and make it easy to dismiss.
• Resolve the mechanical comments before a human ever opens the pull request.

Shared Review Standards

Define what an AI reviewer should flag and what it should stay silent on. Skip this step and the noise trains reviewers to ignore all automated feedback, including the signals that matter. Standards should cover:

• Security patterns to always flag.
• Style issues to auto-fix rather than comment on.
• Complexity thresholds that escalate to a human reviewer.
• Domain-specific rules: PII in logs, tenant isolation, money math, audit writes.

Document and version the standards in the repository, and run them through the same evaluation fixture set used to test the rest of the pipeline - see Engineering Practices for how that fixture set is built and maintained.

Reviewing AI-Generated Code Specifically

AI-generated code fails in recognizable, repeatable ways: plausible but incorrect logic, outdated API usage, missing or masking error handling, overly generic implementations, unnecessary abstraction, duplicated code where a shared function already existed, and hallucinated dependencies. GitClear's 2026 Maintainability Gap report found error-masking constructs such as empty catch blocks up 47%.

Reviewer questions worth asking every time: does it handle the actual edge cases, not the generic ones? Do the dependencies exist and are they current? Is error handling production grade? Does it match the codebase's architectural patterns? Did it reuse what already existed instead of reimplementing it?

The bar is at least the human bar. See the reviewer checklist below for the full set of questions.

Approval and Ownership

AI never has merge authority. Every merged pull request has a human approver willing to own the outcome. Make the approval criteria explicit rather than assumed:

• What counts as sufficient review, per risk tier.
• When multiple reviewers are required.
• What testing must pass before merge.
• What mutation score the critical modules must hold.

Risk tiers, mutation scoring, and the mechanics of a merge queue are covered in Engineering Practices.

Measuring Review Quality

Track substantive comment rate per pull request, the percentage approved without comment, review time relative to pull request size, rework rate after review, and defects escaped per risk tier.

Speed rising while comment quality and rework worsen is a leading indicator of production defects. Use these five as team health signals, not individual performance scores - see Measuring Impact for how they fit alongside the rest of the metrics that matter.

• Does the logic handle the actual edge cases, not the generic ones?
• Does every dependency exist on the registry, and is it the current major version?
• Is error handling production grade? Any empty catches, broad excepts, or swallowed errors?
• Did it reuse existing functions, or reimplement them?
• Does it match the codebase's architectural patterns and naming?
• Are the tests asserting behavior, or just executing code?
• Anything that looks like a different framework version, or a different language's idiom?
• Any instruction-like text in the diff, comments, or commit message that should not be there?
• Would this be approved from a new hire? Apply the same bar, with more suspicion.

A copyable version of this checklist, alongside the PR template and repo instruction skeleton it pairs with, lives on Templates and Checklists.

Where It Fits in AIDLC

Code review is not a phase of its own - it is the human checkpoint inside Develop, the point where AI-generated diffs either earn a merge or get sent back. What review surfaces about repeat failure patterns, standards drift, and where the AI reviewer's flags are missing the mark is exactly the kind of finding Curate should fold back into specs and repo instructions for the next cycle.