How to Review AI-Generated Code: A Checklist for Developers

How do you review AI-generated code?

Reviewing AI-generated code is not the same job as reviewing a colleague's pull request, and treating it that way is why so much of it is shipping broken. The short version: verify what the code actually does before you trust what it claims to do, check the dependencies it pulled in, assume nothing about security by default, and build monitoring that catches what review misses. The long version is why that short version is suddenly urgent.

Why does most code now have an AI co-author nobody can fully account for?

Most code written today has an AI collaborator attached to it, and most engineering organizations have not caught up to what that means. DORA's 2025 report found that 90% of nearly 5,000 surveyed technology professionals now use AI at work. Sonar's State of Code survey puts a finer point on it: 72% of developers use AI tools every day, and AI now helps write up to 42% of committed code.

That is not a trend anymore. That is the baseline. The problem is that the baseline shifted faster than the habits and review processes built to catch mistakes in human-written code.

Why don't developers understand the code they're shipping?

Here's the uncomfortable part: most developers are knowingly shipping code they don't fully understand. Clutch's June 2025 survey of 800 software professionals found that 59% of developers say they use AI-generated code they don't fully understand. Independent analysis from Undo found that 35% of AI-generated code has not been fully comprehended by engineering teams before it reaches production. The same analysis found that 94% of engineers reported at least one productivity-loss incident from having to "unpick" AI-generated code in the past six months, and 29% said it happens multiple times a month.

This isn't limited to junior developers leaning on a chatbot. A SemiAnalysis technical staff member described OpenAI engineers reviewing an AI-generated GPU kernel for DeepSeek and concluded they "have no idea what this MLA kernel... actually does," despite deep hardware expertise. If engineers at a frontier AI lab can lose the thread on code their own tools generated, "read the diff carefully" was never going to be a sufficient review strategy for the rest of us.

There's a reason this keeps happening, and it's not laziness. A randomized controlled trial from Anthropic found that developers who used AI assistance to complete a coding task scored 17 percentage points lower on a comprehension quiz about that same code minutes later than developers who wrote it by hand: 50% versus 67%, roughly two letter grades. The biggest gap showed up on debugging questions, which is exactly the skill you need to catch an AI's mistakes before they ship. AI assistance isn't just producing code people don't understand. It's actively degrading the skill required to understand it.

Why is code review breaking down?

Developers aren't naive about this. They just aren't acting on what they know. Sonar's survey found that 96% of developers don't fully trust that AI-generated code is functionally correct, yet fewer than half say they review it before committing. Separately, 38% of developers say reviewing AI-generated code takes more effort than reviewing a human colleague's code.

Sonar and AWS CTO Werner Vogels call this gap "verification debt": the accumulating distance between how much code gets generated and how much actually gets checked. It's not a discipline problem. It's an incentive problem. Review a colleague's PR and you're reading something a person thought through, with context you can ask them about. Review an AI's output and there's no intent to interrogate, no author to walk you through tradeoffs, and often a volume of code that outpaces the humans assigned to check it. The traditional PR review process assumes a human reasoned through the change. That assumption is now false often enough to matter.

What's actually going wrong in AI-shipped code?

The failure modes aren't hypothetical. They show up in controlled studies and in production incidents.

• False confidence on security. A Stanford study found that programmers with access to an AI coding assistant wrote significantly less secure code than a control group without one, and were simultaneously more likely to believe their code was secure. That combination, worse code plus higher confidence, is precisely what breaks self-review as a safety net.
• Measurable security flaw rates. Separate studies found that 38.8% of programs generated by GitHub Copilot in one sample, and 32.8% and 24.5% of Python and JavaScript snippets in another, contained security flaws.
• Degrading code health. GitClear's analysis of 211 million changed lines of code found that 2024 was the first year on record where copy-pasted code exceeded refactored ("moved") code in commits, with code duplication growing roughly 4x. That's a codebase optimizing for shipping fast over staying maintainable.
• Hallucinated dependencies. AI tools regularly invent plausible-sounding open-source packages that don't exist, and attackers are registering the fake names with malware before anyone notices, a technique known as slopsquatting.
• Secrets leaking at double the rate. AI-assisted commits leak secrets like API keys at 3.2%, more than double the 1.5% baseline across all public commits, per GitGuardian data cited by the Cloud Security Alliance, with over 24,000 unique secrets found exposed in MCP configuration files alone.
• Real production damage. Amazon convened an engineering-wide meeting after a string of outages that an internal briefing attributed to a "trend of incidents" tied to "Gen-AI assisted changes" with "high blast radius," naming "novel GenAI usage for which best practices and safeguards are not yet fully established" as a contributing factor. The company now requires senior engineer sign-off on AI-assisted changes.

These aren't edge cases from careless teams. They're the documented output of mainstream AI coding adoption, at companies with real security budgets and real review processes.

What is a 7-step framework for reviewing AI-generated code?

GitHub's own documentation treats reviewing AI-generated code as a distinct discipline from reviewing a human pull request, built around five steps. Combined with what the research above shows is actually failing, a workable review process looks like this:

1. Start with functional checks. Confirm the code does what it claims before you evaluate anything else. Run it, don't just read it.
2. Verify context and intent. Ask what problem this change was supposed to solve, and check the code actually solves that problem rather than a plausible-sounding adjacent one.
3. Assess code quality independently of whether it runs. Working code and maintainable code are not the same thing, especially now that duplicated, unrefactored code is growing faster than it used to.
4. Scrutinize every dependency. Confirm every package the AI pulled in actually exists, is the package you think it is, and isn't a typo-adjacent name registered by someone exploiting hallucinated imports.
5. Treat security as a default assumption of failure, not success. Given that nearly 40% of Copilot-generated samples in published studies contained security flaws, and that developers using AI assistants are measurably more confident in insecure code, run dedicated security scanning on every AI-assisted change rather than relying on the author's (human or AI) confidence.
6. Pair review on anything you can't fully explain yourself. If the reviewer can't walk through why the code works, that's a signal to pull in a second person before merge, not to wave it through because it passed tests.
7. Make testing mandatory, not optional. Given that fewer than half of developers currently review AI output before committing, the only reliable backstop is automated tests that run regardless of whether a human chose to check.

For a step-by-step version of this built for teams processing AI code at volume rather than case by case, see how to review AI-generated code before it reaches production.

Why isn't review alone enough?

Here's the part most advice skips: even a good review process doesn't scale to the volume AI tools now produce. When a tool is generating 42% of committed code and the people reviewing it are already saying it takes more effort than reviewing a human's work, you cannot staff your way out of the gap with more careful PR review.

That's why review has to be paired with observability, not replaced by it. PR review catches what's visible in a diff. It does not catch the silent failure that only shows up at runtime: a dependency resolving differently in production, a race condition the AI's test coverage never exercised, a security control that worked in isolation but not under load. DORA's own 2025 findings back this up directly: AI adoption correlates with higher throughput, but it also correlates with lower software delivery stability, meaning the volume of change is outpacing teams' ability to catch what breaks. Monitoring what AI-generated code actually does once it's live, not just what it looked like in review, is the backstop that catches what a human reviewer, however careful, structurally cannot.

What does this mean for engineering orgs?

The comprehension gap, the verification debt, the confidence mismatch on security: none of these are going away because a team adopts a stricter review checklist. They're structural consequences of a development process where the volume of generated code has outgrown the human capacity to verify it line by line.

That has organizational implications, not just technical ones. If 59% of developers are shipping code they don't fully understand, and junior engineers are the ones most likely to lean hardest on AI assistance while their comprehension skills are still forming, the skill-atrophy risk compounds over years, not sprints. Treating AI-generated code as a governed asset, with audit trails, ownership, and documented review standards, rather than a productivity shortcut nobody has to account for, is the only version of this that holds up at scale. Organizations that have already built this out the hard way, through formal audit frameworks for AI-generated code, offer a useful starting template for teams that haven't yet (see how to audit AI-generated code in the enterprise).

The fix isn't banning AI-generated code. Adoption numbers make that a non-starter. The fix is accepting that reviewing it is a different job than reviewing a colleague's work, building the checklist for that job specifically, and backing it up with monitoring that catches what checklists miss. Teams that keep running the old process on the new code are the ones who'll find out the hard way what "high blast radius" means.