How to Review AI-Generated Pull Requests: A Step-by-Step Workflow

How do you review AI-generated pull requests?

Reviewing an AI-generated pull request means running it through automated security, test, and dependency gates before a human ever opens the diff, then having a named reviewer sign off against a checklist built for how AI agents actually fail, not a generic approval click. Skip either half of that and you aren't reviewing the PR. You're rubber-stamping it.

Building that workflow takes three pieces: a repo policy that sets expectations before code ships, automated gates that catch mechanical problems at scale, and a human checkpoint that catches what machines can't.

Why do AI pull requests need a different review model?

A coding agent is, in GitHub's own framing, a productive, literal, pattern-following contributor with zero context about your incident history, your team's unwritten norms, or why that one function is deliberately ugly. It will happily generate a technically correct, completely wrong fix. It will also generate a lot of pull requests. GitHub Copilot's code review feature has processed more than 60 million reviews since its April 2025 launch, a 10x jump in usage in under a year, and now accounts for more than one in five code reviews on the platform. That volume is the real problem. It isn't that AI code is reviewed badly. It's that there's suddenly too much of it to review the old way at all.

Google's DORA research backs this up at the organizational level: a 25% increase in AI adoption is associated with a 1.5% decrease in software delivery throughput and a 7.2% decrease in delivery stability, because teams can generate code faster than they can safely review it, which pushes batch sizes up and stability down. The same research found 39% of developers still trust AI-generated outputs only "a little" or "not at all," even as adoption keeps climbing. That trust gap is rational. It just needs a workflow built around it instead of a vibe.

How risky is unreviewed AI-generated code, really?

The evidence here is not ambiguous. Veracode's benchmark across 100+ LLMs and 80 coding tasks found 45% of AI-generated code contains security flaws, and only 55% of AI output passed security checks overall, a figure that hasn't meaningfully improved as models have gotten bigger. Risk also varies sharply by stack: Python code passed security checks 62% of the time, JavaScript 57%, C# 55%, and Java just 29%. The right level of scrutiny for a PR depends on what language it's written in, not just who, or what, wrote it.

A separate academic analysis of 7,703 AI-attributed files pulled from public GitHub repositories mapped 4,241 distinct vulnerability instances across 77 CWE categories, with Python code showing vulnerability rates of 16–18.5% against 2.5–9% for JavaScript and TypeScript. GitClear's longitudinal study of 211 million changed lines of code found a related but different problem: the share of changed lines attributable to genuine refactoring fell from 25% in 2021 to under 10% by 2024, while duplicated, copy-pasted code rose from 8.3% to 12.3% over the same period. AI-assisted code isn't just more likely to carry a security flaw. It's increasingly cloned rather than reused, which compounds maintenance debt quietly.

There's also a time-budgeting problem reviewers should know about. A METR randomized controlled trial of 16 experienced open-source developers across 246 real tasks found that AI tool use made them 19% slower on mature, familiar codebases, even though those same developers believed afterward that AI had made them 20% faster. If your reviewers are budgeting review time based on how fast AI feels, they're budgeting against the wrong number.

How do you set the ground rules before code ships?

Most of the chaos in AI PR review comes from the absence of a stated policy. Fix that first:

• Write an AI contribution policy. A short AI_POLICY.md that states which agents are approved, what they're allowed to touch (no auth, no payments, no infra-as-code without extra sign-off), and what logging is required.
• Require self-annotation. PR templates should force the author, human or agent-assisted, to state what was AI-generated, what prompt or task drove it, and what they personally verified before opening the PR.
• Cap diff size and scope. Oversized, multi-concern AI PRs are where review quality collapses fastest. Set a soft limit and require a written justification to exceed it.

This is the same groundwork covered in more depth in an AI agent code security workflow built before you ship, and it's worth building before volume forces your hand.

How do you automate the first pass?

Before any human opens the PR, it should already have cleared a mechanical gate:

• Unit and integration tests, run in CI, not locally, with coverage thresholds enforced rather than advisory.
• Static analysis (SAST), tuned to the vulnerability classes that actually show up in AI output: injection, broken access control, improper input validation.
• Software composition analysis (SCA), checking every new dependency against known-vulnerability databases.
• CI-integrity checks that specifically look for signs the agent gamed the pipeline: removed tests, skipped lint steps, or || true hacks that make a failing step report green.

The mechanics of this pipeline, including where to set thresholds that catch what reviewers tend to skim past, are covered in detail in how to test AI-generated code before it breaks production.

What is slopsquatting and how do you defend against it?

Slopsquatting is an attack that exploits a specific, well-documented AI failure: models hallucinate package names that don't exist, and attackers register those names on public registries ahead of time. A USENIX Security 2025 study generated 2.23 million code samples across 16 models and found 19.7% contained at least one hallucinated package, totaling 205,474 unique fabricated names. Open-source models hallucinated at a 21.7% rate versus 5.2% for commercial models, and 43% of hallucinated names recurred every time the same prompt was run, which is exactly what makes them predictable, pre-registerable targets.

This isn't theoretical. A malicious npm package impersonating eslint-plugin-unused-imports kept logging roughly 233 weekly downloads even after being flagged, and a hallucinated package adjacent to huggingface-cli racked up over 30,000 downloads in three months after being copied into trusted documentation. OWASP's 2025 Top 10 for LLM Applications now formally codifies supply-chain risk as a top-tier concern for AI-assisted development.

Defend against it with a short, concrete list:

• Pin lockfiles, not version ranges, so a hallucinated dependency can't silently resolve on a later install.
• Maintain an allowlist of approved registries and packages for agent-generated code specifically.
• Check registry age and download history on any new dependency an agent introduces before merge.
• Generate an SBOM on every build so a slopsquatted package is traceable the moment it's flagged, not weeks later.

Why let AI review AI, as a prerequisite and not a replacement?

Once a PR clears the mechanical gate, run it through an automated code review tool, Copilot code review, PR-Agent, or Qodo, as a first filter for formatting, obvious logic errors, and style drift. This is exactly how GitHub frames its own tool: a way to clear mechanical noise so human reviewers can spend their limited attention on judgment calls. The deeper mechanics of building this layered review process, including where acceptance gates should sit relative to security scanning, are covered in how to review AI-generated code before it reaches production.

What should a human reviewer look for in an AI-generated PR?

This is the step teams skip when volume gets high, and it's the one that can't be automated away. GitHub's own red-flag framework gives reviewers a concrete checklist for every agent-authored PR:

• CI gaming. Look for removed tests, skipped lint rules, or disabled checks the agent used to make a failing build look green.
• Code-reuse blindness. Check whether the agent duplicated an existing utility instead of finding and reusing it, a pattern that matches GitClear's data on rising code duplication.
• Hallucinated correctness. Code that compiles, passes tests, and is still wrong. Tests written by the same agent that wrote the code tend to validate the agent's assumptions, not the actual requirement.
• Agentic ghosting on oversized PRs. A single enormous diff touching five unrelated systems is a sign the agent kept going past its original scope. Push back on size before reviewing content.
• Untrusted input and prompt injection. Any workflow where the PR's own code calls an LLM on user-supplied input needs a specific review pass for injection risk, separate from standard input validation.

How do you define escalation and ownership?

Every merged AI PR needs a named human owner, not just an approving reviewer. That person is accountable if the code breaks something in production, the same way they'd be accountable for code they wrote themselves. Keep an audit trail of the prompt or task that generated the change alongside the diff, so a postmortem six months later doesn't start with "nobody knows why this is here."

This matters because the ownership gap in code review is really the same gap showing up across shadow AI more broadly: roughly 78% of AI users at work bring their own unapproved tools, and most organizations still lack mature AI governance. Code that an agent generated and nobody formally owns is functionally the same risk as a tool an employee built and never told IT about, which is the exact problem covered in shadow AI governance for the agents employees build. Treating merged AI code as an owned asset, with a clear system of record for who built it, why, and what it touches, keeps self-built software accountable instead of invisible.

How do you put it together into a workflow you can run every day?

In practice, the stages above should run in a fixed order every time: policy and PR template compliance first, then automated tests and SAST/SCA scanning, then dependency verification against slopsquatting, then an AI-powered first-pass review, then the human checkpoint against the five red flags, then a named sign-off before merge. Time-box each stage rather than letting review balloon to match the size of the diff. A reviewer who knows exactly which five things to check moves faster and misses less than one working from a blank mental checklist.

Why choose governance over prohibition?

None of this is an argument against using AI coding agents. It's an argument against treating their output as finished work. The data is consistent across every independent study in this piece: AI-generated code ships faster and, without a deliberate workflow in front of it, fails more often. Teams that build the layered gate described here capture the speed without inheriting the risk. The ones that skip the human checkpoint are not moving faster. They're just finding out about their incidents later.