Code Review Standards for AI-Assisted Pull Requests

AI-generated code rarely fails the way broken code used to fail. It compiles. It passes the happy-path test the model wrote for itself. It reads like something a competent engineer typed out, and it can still be wrong in a way nobody notices until an incident report appears months later with no clear author to ask about it. Code looks correct because it's shaped like correct code, not because anyone confirmed the assumptions underneath it, and that gap is what makes it a plausibility trap. Traditional review was built to catch the opposite problem. Reviewers are trained to spot code that looks wrong, clumsy variable names, inconsistent formatting, logic that doesn't track. AI output defeats that instinct by default, since it mimics the surface features of good code while quietly skipping the parts a human author would have had to think through.

That changes what a reviewer actually has to check. It's not enough to read the diff. A reviewer now has to reconstruct the generation context: what prompt produced this change, which files the assistant actually looked at, whether it invented an API that doesn't exist in this version of the library, and whether the developer verified any of it or just accepted the output because the tests came back green. None of that context lives in the diff itself. It lives in a chat log or a terminal session that most PR templates don't ask for, which means the review is missing half its evidence before it starts.

The pattern is visible in the code's shape, too. GitClear's analysis of changed lines found that refactored or moved code fell sharply between 2021 and 2024, while copy-pasted lines climbed. That's not a style complaint. Duplication is the raw material of technical debt: every cloned block is a spot where the next fix has to be applied again, and again, wherever the pattern got copied. Code that used to get consolidated into a shared function now gets regenerated fresh each time a prompt asks for something similar. It compounds quietly, hidden by the plausibility trap. CircleCI's 2026 data shows feature branch throughput up substantially year over year while main branch throughput for the median team fell, and the volume mismatch makes the plausibility trap harder to escape, as the bottleneck has moved from writing code to deciding whether code is safe to merge. Per the DORA report, pull requests per developer increased meaningfully with AI help, but incidents per pull request also increased (volume gains are not free).

The Cost of the Governance Gap

Most engineering organizations picked up AI coding tools well before they built any policy to govern what those tools produce, and the record of what that gap costs is no longer theoretical. Qodo's 2026 State of AI Code Quality survey found that 89% of organizations reported having had an AI-related production incident. Amazon's March 2026 outages are the clearest large-scale example: a series of production failures in which AI-assisted code changes reportedly played a role, a fairly direct signal that AI can raise code volume faster than manual review can absorb it.

Bonterra, a social good software provider, offers the most granular documented case. According to CTO Tanuja Korlepra, proposed changes tripled within three months of adopting AI tools. Code entering review rose tenfold, and review times tripled on top of that, to the point where it became genuinely impractical for engineers to read every line that showed up in a queue. Bonterra's answer wasn't to hire more reviewers. It built agents that compare incoming code against approved design patterns, security rules, coding standards, and accessibility requirements, then route anything low-confidence or flagged straight to a human. That's a working example of tiered review built under real volume pressure, not a hypothetical.

The governance gap is visible in the numbers on the leadership side too. Qodo's 2026 report found that roughly nine in ten engineering leaders say they can report on AI's impact on their engineering org. Fewer than half, though, actually have traceability connecting AI activity to the code changes it produces, or centralized coding standards, or visibility into AI-related quality trends, or consistent policy enforcement across teams. So leaders believe they have a handle on this. Most of the infrastructure that would make that true doesn't exist yet.

There's a quieter cost sitting underneath all of this. Senior engineers in 2026 report spending noticeably more time on code review when junior developers lean heavily on AI assistants, a hidden tax that eats into the very productivity gain AI is supposed to deliver. And the compliance clock is already running. The EU AI Act entered into force in August 2024 with phased application timelines, and high-risk AI systems under that law need detailed logging, traceability, and human oversight, requirements that a lot of agentic coding setups simply don't meet yet. None of this reads like a series of one-off accidents. It reads like a structural gap between how fast AI tools generate code and how slowly organizations have built the policy layer to catch what's wrong with it, which is exactly the kind of gap a tiered, deliberate standard is built to close. Security researchers documented that between January 2025 and February 2026, nearly every significant breach in vibe-coded applications traced back to the same preventable root causes, including misconfigured databases, missing row-level security, hardcoded API keys, and exposed cloud backends, in a research brief [source unverified, gogloby.com/insights/ai-code-review does not appear to exist]. Per Opsera, AI-generated code contains more security vulnerabilities per line than human-written code at a meaningfully higher rate than human-written code.

Why the standard checklist fails AI-generated PRs

Traditional code review answers one question: did this human author build something correct and maintainable? That question assumes a person sat down, understood the requirement, and made deliberate choices along the way. Neither assumption holds for AI-generated code. There's no guarantee the model understood the requirement at all, so the reviewer's job shifts from judging choices to reconstructing what the model thought the task was in the first place. That's a fundamentally different exercise, and it's why simply running the old checklist against a new kind of diff misses the risk that actually matters.

Supply chain risk is a good example of how early the failure point has moved. AI tools suggest package names, imports, and setup commands as part of normal output, which means dependency review can't wait for a monthly software composition analysis report anymore. Slopsquatting, where attackers register package names that resemble ones a model is likely to hallucinate, is a live attack surface built specifically around this behavior. By the time a scheduled audit would have caught a bad dependency, it's already been pulled into a build.

Security review now needs two frameworks running at once: the OWASP Top Ten Web Application Security Risks for application code, and the OWASP Top 10 for LLM and Gen AI Applications for AI-integrated systems, covering prompt injection, sensitive information disclosure, supply chain, improper output handling, excessive agency, and related risks. NIST's SP 800-218A adds another layer specific to generative AI and dual-use foundation models, functioning as a community profile used alongside the existing Secure Software Development Framework rather than replacing it. Running only the old checklist against this kind of code isn't just incomplete. It's checking for the wrong category of failure.

What all of this points to is a mental shift more than a procedural one. Stop treating AI output as a human's finished work product, and start treating it as a plausible first draft whose assumptions still need to be verified independently. Sourcegraph's 2026 guide puts a fine point on why this matters: human reviewers are still the only layer that can catch code that's technically correct but wrong to build in the first place, a category of feedback that no amount of automation replaces. CodeAnt AI's 2026 best-practices guide makes a related, more concrete argument: reading the PR description, the linked ticket, and any design discussion before touching the diff is the step that separates approving code that runs from approving code that solves the actual problem. Put those together and the shape of a working standard emerges. It's a standard tiered by risk rather than one uniform checklist applied evenly to every PR. It's a standard tiered by risk, where mechanical, provable things get automated and judgment calls about intent, architecture, and trust boundaries stay with a human who has the context to make them.

A tiered pre-merge checklist: what automation can own, what requires human sign-off

The most workable structure splits review into two tiers: checks automation can own reliably on every single PR, and checks that need explicit human sign-off before anything touching a trust boundary gets merged. Metacto's 10-check standard states the organizing principle: low-risk changes can lean on automation, but anything touching auth, payments, infrastructure, data migrations, public APIs, or PII needs a human to sign off before it ships. Before either tier even runs, don't send every generated diff straight to a human reviewer. Run an automated pass first to clear out the mechanical stuff, since a structured AI review posted quickly after a PR opens cuts down the back-and-forth that turns review into a bottleneck in the first place.

Tier one runs in CI, blocks merge on failure, and needs no human to approve a pass:

• No hardcoded secrets. Tokens, keys, connection strings, and credentials shouldn't appear in code, tests, logs, fixtures, or generated docs. Owner: author plus CI. This is the single most immediately exploitable class of AI-generated vulnerability, and it's entirely catchable by a scanner.
• No weakening of quality gates. The PR can't skip tests, loosen lint rules, lower coverage thresholds, bypass hooks, force a failing command to succeed, or silence a security check.
• Every imported module, function, SDK method, CLI flag, and config key has to exist in the actual version of the library the repo is running.
• Input validation and output handling. External input gets validated at the boundary; output gets escaped, encoded, or parameterized for wherever it lands. This is squarely automatable through SAST tools and linting rules.

Static analyzers like Semgrep and ESLint are deterministic: a rule either fires or it doesn't, and a team can audit why. The point isn't to replace an AI reviewer with these tools, it's to pair them, since each catches a different category of problem.

Tier two needs explicit approval from a senior reviewer before anything merges:

• Requirement fidelity. Does the diff implement the ticket's actual acceptance criteria, or the AI assistant's plausible guess at what those criteria meant? Owner: primary reviewer. This can't be automated, because it requires understanding intent, not just syntax.
• Authentication and authorization on protected paths. New endpoints, server actions, background jobs, and data access paths need to enforce auth consistently. Owner: senior reviewer. This is, per metacto's standard, the check most often missed in AI-generated code that otherwise looks right.
• Error handling and observability. Failures should be handled on purpose, logged with context that's actually useful, and shouldn't leak internal implementation details. AI-generated error handling tends to swing to one extreme or the other, logging far too much or far too little.
• Failure-path tests. Coverage for malformed input, empty states, permission failures, network failures, and concurrency where it's relevant. Owner: author plus reviewer. Tests that only cover the happy path are practically a fingerprint of unreviewed AI output.
• Architectural fit. Does the change respect existing module boundaries, naming conventions, and data flow, or does it introduce a stray utility clone or a circular dependency? Owner: senior reviewer. Duplication left unchecked here is exactly the raw material that turns into long-term technical debt.

Treat AI output as pre-reviewed only when there's a system in place that can actually prove it was. If a change touches trust boundaries, customer data, money movement, infrastructure, or production access, the merge decision stays with an accountable human who has the full system context, no exceptions.

One more check sits outside both tiers, because traditional review has no equivalent for it. Authors should document, right in the PR description, what prompt or task produced the code, which files the assistant had access to, and what the developer actually verified by hand. This is the generation context that traditional checklists were never built to ask for, and without it a reviewer is working blind. The same logic that applies to AI reviewers applies to human ones here: a reviewer who sees only the diff gives generic feedback, while a reviewer who sees the full file, the PR description, and the linked issue can actually say something useful. Tier two requires human sign-off, meaning explicit approval from a senior reviewer before merge. The prompt and context check is specific to AI-generated PRs and has no equivalent in traditional review.

AI review tools: where they help and where they create a false sense of coverage

AI code review tools are worth having as a pre-screening layer. They are not an approval authority, and the gap between those two roles is exactly where most teams get calibration wrong. The honest state of the technology in 2026 is that it's matured fast, but the marketing around it has outpaced what it actually does, and that gap is widening.

A structural objection sits here. Using AI to review code that AI wrote risks becoming a closed loop, one system checking another system's homework using similar blind spots. The point was never to get an AI rubber stamp on AI output. It's to free up human attention for the things a model still can't judge well: planning, intent, whether the architecture actually makes sense. Qodo's 2025 State of AI Code Quality report found that 65% of developers using AI for refactoring say the assistant misses relevant context, which lines up with a broader point: context is the lever that actually determines review quality, not which model happens to be running.

Cross-cutting changes make that clear. Without retrieval into the rest of the codebase, AI review accuracy drops sharply, because the model literally can't see the code its change affects. A tool with full-codebase retrieval can reason about whether new code breaks an invariant somewhere else in the system. One that only sees the diff can't, and produces surface-level comments as a result. Sourcegraph frames the review pipeline as three stages: diff ingestion and context gathering, model evaluation against rules and patterns, then comment generation with noise filtering. Quality mostly comes down to how well a tool handles that first stage, not which underlying model does the evaluating.

None of that means these tools are useless, though. Quite the opposite, on the mechanical layer they're genuinely reliable. Naming convention violations, inconsistent import style, sloppy variable names, all the small stuff that gets deprioritized the moment a deadline gets tight, an AI reviewer applies the standard every single time without getting tired of it. Hardcoded credentials, unsanitized inputs, and SQL injection vectors get flagged on every PR that runs through the tool, not only when a security-focused engineer reviews. Missing test coverage gets caught the same way: a new function with no test file, a new edge case with no assertion covering it, exactly the kind of gap that's tedious to catch by hand and trivial for a tool to flag consistently.

So the calibration question is where to point these tools, not whether to use them. It's where to point them. Aimed at the mechanical layer, deterministic rules, missing tests, known vulnerability patterns, they earn their keep on every PR that comes through. Aimed at requirement fidelity or architectural judgment, they're still guessing, and treating that guess as coverage is how the plausibility trap closes back in from a different direction. The tools available as of mid-to-late 2026 each cover a distinct use case, per Mastra's roundup and supporting sources. CodeRabbit offers dedicated AI code review across pull requests, IDEs, and CLI, with context that includes repository conventions, linked issue requirements, prior feedback, and related.