To review AI-generated code before merging, first confirm the change does only what was asked. Then read the parts that decide who can do what, how input is handled and what the code now depends on. Treat tests written by the same tool as code to review, not as proof. Finally, set up the repository so a green build alone can't merge a change.
Cursor, Claude Code, Lovable, Bolt and Replit write code quickly and in large batches. A long diff that compiles and passes its own tests is easy to approve. The reviewer has to supply what the tool wasn't told: the threat model, the codebase's conventions and what must not change.
Why AI-generated pull requests need a different review
With a human-written pull request, the author can explain every line. With AI-generated code, the person who opened it may not have read every line, so the reviewer is often the first to do so.
That changes what goes wrong:
- Diffs grow beyond the request. A one-line fix arrives with renamed helpers and a refactor nobody asked for.
- Code looks confident when it's wrong. It can call a function your library version doesn't have, or swallow an error, in idiomatic style.
- Failures get fixed by loosening. The quickest way to make a failing check pass is to widen a permission, ignore an exception or skip the test.
- Context is missing. The tool doesn't know that a table holds payment data or that a partner calls a route.
The reviewer's question shifts from "is this well written?" to "is this what we asked for, and what else did it change?"
How to review AI-generated code: start with scope
A few minutes of triage tells you where to spend the review.
- Read the request. Ask the author to paste the prompt or task description into the pull request. Without it, you can't judge scope.
- Read the file list. Compare it with the request, and flag anything outside it: migrations, authentication middleware, CI workflows, lockfiles, security headers, CORS settings.
- Check the size. If you can't hold the change in your head in one sitting, ask for it to be split. Unrequested refactors go in their own pull request.
- Run it. Use the feature in a preview deployment and try one failure case, such as the wrong user.
One command lists changed files in places that need a closer look:
git diff --name-only origin/main...HEAD \
| grep -E 'migrations/|auth|middleware|\.github/workflows/|package\.json|lock|\.env|AGENTS\.md|CLAUDE\.md|\.cursor/'Where AI-generated code hides risk
OWASP's Secure Code Review Cheat Sheet treats a pull request as a diff-based review: assess the impact on existing security controls, look for new attack vectors and verify security at modified trust boundaries. In AI-built apps, these are the places to read line by line.
| Area | What to look for | Check you can run |
|---|---|---|
| Authorization | Checks done only in the UI, records fetched by ID without an ownership check | For each new route or server action, find the line that checks the user may act on the record |
| Input handling | Request bodies passed into queries, file paths, shell commands or outbound URLs | Search the diff for string-built SQL, exec(, eval( and dangerouslySetInnerHTML |
| Secrets | Keys in client-side variables such as NEXT_PUBLIC_ or VITE_ | Search added lines for those prefixes and for service_role |
| Error handling | Empty catch blocks, errors converted into success responses | Read every new catch and confirm it logs or rethrows |
| Database rules | New tables without row-level security, broadened policies | Read every migration line, including grants |
| LLM features | User text placed into prompts for a model that can call tools, model output rendered as HTML | Trace each prompt input back to its source |
Our list of security mistakes in apps built with AI tools covers each area in more depth, and Supabase row-level security mistakes covers database migrations.
A search over added lines finds the obvious cases in seconds:
git diff origin/main...HEAD -U0 | grep -nE '^\+.*(NEXT_PUBLIC_|VITE_|service_role|eval\(|exec\(|innerHTML|dangerouslySetInnerHTML|using \(true\)|@ts-ignore|eslint-disable)'A clean result says nothing about missing checks, which is why the authorization row needs a human reading the code.
How to review tests an AI tool wrote
When one tool writes both the code and its tests, they share its assumptions, so a passing suite only shows the code does what the tool intended. Look for:
- Assertions that can't fail, such as checking that a result is defined.
- Snapshot tests that record whatever the code currently returns, including a bug.
- Mocks that replace the thing under test, so the test exercises the mock.
- Only the happy path. Ask for the failure cases: another user's record, an expired session, a missing field.
- Tests removed, skipped or weakened. Search for
.skip,xit,--passWithNoTestsand lowered coverage thresholds.
Then break the code on purpose, for example by inverting the ownership condition, and confirm at least one test fails. If nothing fails, the tests don't protect that behavior.
Reviewing dependencies, migrations and configuration
For new packages, confirm the package exists under that exact name, is maintained, and that the lockfile change matches package.json. AI tools sometimes suggest package names that don't exist, and attackers register those names.
Migrations need a rollback plan, because dropped columns and renamed tables can't always be undone after deploy. Check grants as well as policies.
Configuration changes widen what every later change can get away with. Watch for a CORS origin set to *, a relaxed Content Security Policy, disabled lint rules or a CI step allowed to fail.
Rules files for AI agents, such as .cursor/rules/, AGENTS.md or CLAUDE.md, steer every future AI-generated change in the repository. Review them like CI workflows.
Pull request rules that keep the review honest
Review habits slip under deadlines, so let the repository enforce them. On GitHub, protected branch rules can:
- require a set number of approving reviews before merging
- dismiss stale approvals when new commits change the diff, so an agent's follow-up commits can't merge unreviewed
- require the most recent push to be approved by someone other than the person who pushed it
- require review from a code owner for files that have one
- require status checks to pass before merging
By default, these rules don't apply to repository admins. If the people opening AI-generated pull requests are also admins, enable "Do not allow bypassing the above settings."
A CODEOWNERS file routes sensitive paths to the right reviewers. An example, with placeholder teams:
# .github/CODEOWNERS
/supabase/migrations/ @your-org/backend-reviewers
/src/middleware.ts @your-org/backend-reviewers
/.github/workflows/ @your-org/platform
/.cursor/rules/ @your-org/platform
/AGENTS.md @your-org/platformAdd a pull request template that asks for the prompt, the files changed on purpose and how the change was tested. Our 25-point security checklist for AI-built apps works as the security section of that template.
Common mistakes when reviewing AI-generated code
- Approving because CI is green, when the tests share the code's blind spots.
- Asking the same tool to review its own change and counting that as the review.
- Reading only the files the description mentions.
- Spending the review on naming and style while a missing ownership check goes unnoticed.
- Accepting a rewrite of working code inside a feature change.
- Approving without running the change once, even in a preview deployment.
When reviewing each diff isn't enough
Diff-based review only covers what changes from today. If most of the codebase was generated before anyone reviewed it, start with what OWASP's cheat sheet calls a baseline review of the whole codebase. That is also the time to add the CI pipeline, tests and environments from our guide to taking an AI-built prototype to production.
Our Prototype to Production work starts with a code and architecture review and a prioritized plan. It then sets up the pipeline, tests and monitoring, so AI-assisted changes are reviewed, tested and deployed safely.
Frequently asked questions
Can AI code review tools replace human review?
They catch common patterns quickly and make a reasonable first pass. They don't know your business rules, such as which users may refund an order, and that is where serious flaws sit. Keep a human approval as the merge requirement.
Should AI-generated code be labeled in pull requests?
Yes. A label or template field tells the reviewer the author may not have read every line, so the stricter checks above apply. It also helps trace a defect back to how the change was produced.
Who should review AI-generated code in a small team?
Someone who didn't prompt the change and knows the part of the system it touches. If there's only one engineer, review your own pull request the next day against the checklist, and get an outside review before launches or enterprise deals.
Is AI-generated code less secure than code written by hand?
No general answer holds for every tool and codebase. The added risk comes from volume and from code merged without anyone reading it, so the review process has to scale with the volume.