Reviewing AI-Written Pull Requests: A 10-Point Checklist

AI-generated pull requests pass code review more often than they should. The code is well-formatted, it compiles, and when there are tests, they pass. The issues that get through are not the visible ones. They are the assumptions about which user can call which function, the missing input validation on a route that was not in scope for the tests, and the dependency that was hallucinated and then registered by someone else. This checklist is for engineers who review code where AI tools contributed significant portions of the diff.

Why AI PRs Require a Different Review Frame

A 2026 study (Liu et al., arXiv:2603.28592) analysed 302,600 verified AI-authored commits across 6,299 GitHub repositories. It found 484,366 distinct issues, with code smells accounting for 89.3 percent. More relevant to a reviewer: 22.7 percent of the tracked AI-introduced issues were still present in the latest version of the repository. They were not caught or cleaned up along the way.

The Veracode 2026 GenAI Code Security Report, adds the security dimension. Across the models Veracode has tracked, it found an average security pass rate of 56 percent. The best model on this year's leaderboard, GPT-5.5, reached 68 percent, so roughly one in three of its outputs still fails the security tests. Coding-specific models averaged 51 percent against 52 percent for general-purpose models, so specialisation did not help.

The problem for reviewers is that these issues are not the kind that look wrong on first read. A SECURITY DEFINER function that bypasses RLS looks like any other function. A dependency with a known CVE looks like a normal import. Confidence in AI output, because it reads fluently and compiles cleanly, makes these issues harder to catch, not easier.

Before You Open the Diff

Two things should happen before a reviewer opens the diff on an AI-heavy PR. First, a static analysis tool should have run in CI. This is not optional. If the team's CI pipeline does not include a linter and a security scanner on AI-contributed code, the reviewer is doing a worse job with more effort than an automated tool could do in seconds. Second, the reviewer should know which parts of the diff are AI-generated. Some teams label this in the PR description. If they do not, ask.

The 10-Point Review Checklist

1. Check every new dependency. AI tools hallucinate package names. Before any new package merges, verify it exists on the real registry, has recent commits, and does not appear in the OSV vulnerability database. A USENIX Security 2025 study of 16 code-generating models (Spracklen et al.) found average package hallucination rates of at least 5.2 percent for commercial models and 21.7 percent for open-source models, and attackers can register such names (slopsquatting).
2. Review authentication assumptions on every new route or function. Who can call this? Is it behind an auth check? For Supabase RPC functions, check whether the function is SECURITY DEFINER and whether anon has execute privileges (by default any role can call a function, including anon). For API routes, check whether the auth middleware runs before the handler.
3. Check input validation. AI-generated handlers often validate the happy path and ignore malformed, empty, or overlong inputs. Look for missing null checks, missing length limits, and missing type coercion for values that come from user input.
4. Look for hardcoded values that should be environment variables. API keys, URLs, credentials, and configuration that should be per-environment are a common category. Grep the diff for strings that look like tokens.
5. Review error handling. AI-generated error handlers often swallow exceptions or return stack traces to the client. Both are problems. Check that errors are logged server-side and that responses to the client do not include internal detail.
6. Check for data returned beyond the scope of the request. Functions that query by one ID should return exactly one user's data. If the function joins additional tables or returns fields that were not in the original spec, ask why.
7. Verify that tests cover the negative cases. AI-generated tests are often comprehensive on the happy path and missing on error conditions, invalid input, and unauthorised access. If there is a test for 'user gets their invoice,' check whether there is a test for 'user cannot get someone else's invoice.'
8. Read for maintainability, not just correctness. The arXiv study above found that code smells make up most AI-introduced issues, the kind of issue that does not break anything today but makes the codebase harder to work in next month. Variable names, function length, and unexplained logic are worth flagging.
9. Check the migration or schema change if there is one. AI-generated database migrations often miss RLS policies on new tables, set incorrect column types, or omit index definitions on columns that will be queried frequently. In Supabase, a table in an exposed schema without RLS is readable and writable by any role with a grant on it.
10. Verify what the PR does not change. AI agents working with broader context sometimes modify files outside the stated scope of the change. Review the full file list, not just the primary diff. An agent asked to update an endpoint may have also modified a shared utility or a config file.

Specific Patterns That Pass Review and Should Not

A few patterns deserve extra attention because they look correct on the surface.

SECURITY DEFINER without privilege restriction. As covered in the Postgres functions ownership post, a SECURITY DEFINER function runs with its creator's privileges, and a function owned by postgres bypasses RLS. Any occurrence of SECURITY DEFINER in a migration file should be flagged for a privilege review unless it has an accompanying REVOKE EXECUTE from public and anon.

Unbounded queries in server functions. A function that does SELECT * FROM table WHERE some_condition = $1 without a LIMIT is a denial-of-service risk if the condition matches many rows. AI-generated queries frequently omit LIMIT clauses on server-side endpoints where the result set could grow.

Client-side API keys. AI coding tools have a known pattern of placing API initialisation code in client-side files, which are visible in the browser, even when the key has server-side permissions. Any new import of a third-party SDK in a client component should be checked for key exposure.

The Culture Change That Makes This Sustainable

A checklist only works if there is time to use it. AI coding tools increase the volume of code going into review. If the team's expectation is that review time stays constant, quality will drop. The practical adjustment is to require that AI-heavy PRs are smaller, with a clear scope limit, rather than reviewing large AI-generated diffs at the same pace as human-written code. A PR that covers one endpoint or one migration is reviewable. A PR that covers an entire feature scaffold is not, regardless of who wrote it.

The DORA 2025 report, drawing on survey responses from nearly 5,000 technology professionals, concluded that AI does not fix a team, it amplifies what is already there. If your team's baseline is thorough code review with clear ownership, AI tools will help. If the baseline is optimistic review and shipping fast, they will accelerate the problems that creates.

Only 24 percent of developers in the Stack Overflow 2026 survey said their employer had approved tools or an official AI policy or guidance (as reported by IT Brief). If your team is using AI coding tools without a shared process for how their output gets reviewed, the checklist above is a reasonable starting point for writing that process.

Getting Outside Eyes on an AI-Heavy Codebase

The free code review tool runs automated checks across a repository for the categories that appear most commonly in AI-assisted codebases: secrets in source, dependency vulnerabilities from OSV advisories, Supabase and Firebase configuration issues, and common security misconfigurations. It is a faster baseline than working through every file manually.

If you have a larger codebase or want a human review of a specific area, including authentication logic, database function permissions, or API surface, you can request a technical review from the code review page. The patterns above are the ones a human reviewer should look at first.

Common questions

How should I review a pull request written by AI?

Make sure static analysis and a security scanner ran in CI, and find out which parts of the diff are AI-generated. Then verify every new dependency, check authentication assumptions on each new route, flag any SECURITY DEFINER in migrations, and keep AI-heavy PRs small.

Can AI coding tools hallucinate package names?

Yes. A USENIX Security 2025 study of 16 code-generating models found average package hallucination rates of at least 5.2 percent for commercial models and 21.7 percent for open-source models, and attackers can register such names. Verify a package exists on the real registry before merging.

Who can review a codebase built with AI tools?

Zovintra's free code review tool runs automated checks for secrets, dependency vulnerabilities, Supabase and Firebase configuration issues and common misconfigurations. For authentication logic, database function permissions or API surface, you can request a human technical review from the same page.