AI-Generated Code Review: 8-Point Checklist + Tools (2027)

AI-generated code review means screening code from Copilot, Cursor, Claude Code, or any other agent for invented packages, deleted tests, missing authorization checks, and deprecated APIs.

We'd run the scanners first, read the diff against the ticket second, and save hand fixes for small, local misses.

Why AI-generated code is harder to review

Review every AI pull request as you would one from a new hire whose work you haven't vetted yet. The code comes out tidy, well named, and commented, so you'll need tests and checks to find out whether it works.

Human review relies on cues that AI-generated code doesn't show, like the messy diff that warned you the author was unsure.

Our vibe coding best practices guide names the deeper problem. With vibe coding, the author's job is directing and checking the code, so they may not be able to explain every line in review.

Recent studies measure what slips through.

• Correct code still fails on security. In a December 2025 benchmark of 186 feature-request tasks (the SUSVIBES study), the best-performing setup (SWE-agent with Claude 4 Sonnet) solved 57% of them correctly.
  
  But only 11.8% of its solutions were secure (arXiv). That difference between working code and safe code is the subject of our AI code security breakdown.

• More defects per change. In an analysis of 470 open-source pull requests, CodeRabbit found AI-generated code introduced 1.7x more defects than human-written code (CodeRabbit report). CodeRabbit measured this with its own review system, so take it as one vendor's number.

• Invented dependencies. A 2024 study of 576,000 code samples from 16 LLMs found that, on average, at least 5.2% of the packages commercial LLMs suggested didn't exist, against 21.7% for open-source ones (arXiv).

A 2026 replication on five newer models still found rates between 4.62% and 6.10% (arXiv). Our vibe coding security guide explains how attackers register those invented names.

Volume adds to the risk. When agent diffs arrive faster than the team can read them, reviewers skim, and a clean-looking bug can reach production.

What you'll need before you start

• The prompt or ticket behind the change. You'll hold it next to the diff in check 8.
• A CI pipeline that builds the branch, runs the test suite, and scans every pull request with at least one security tool.
• A lockfile with pinned versions. It tells you which framework and library releases the code should target.
• A named human owner for sensitive paths such as authentication, payments, and regulated data.

The 8-point AI-generated code review checklist

Work through the checks in this order. Run the machine checks below first, so the scanners clear the mechanical problems before you start reading. The first three are quick and stop a broken change early, which leaves time for the slower checks on security and scope.

1. It compiles and runs with no new warnings

Build the branch (or let CI do it) and read the warning list next to the exit code. Look for unused imports, shadowed variables, and type casts that suppress compiler errors without fixing the type.

A green build can still carry new warnings, and each one is something the compiler flagged that you haven't reviewed yet.

Pro tip: Make "no new warnings on changed files" a CI rule so reviewers don't have to check it by hand.

2. Tests pass, and none were deleted or skipped

GitHub's guide to reviewing AI code puts it plainly, telling reviewers to "Watch for tests that are deleted or skipped, instead of fixed" (GitHub Docs). An agent told to make CI pass is aiming at the pass/fail result, and removing a failing test is one way to get it.

Scan the diff for removed test files, new skip or xfail markers, and assertions loosened from an exact value to "is not null."

Then look at what the remaining tests cover. If they stop at the happy path, ask for empty input, nulls, and a permission-denied case.

3. Every imported package and API exists

Look up each new import on its registry, like npm or PyPI. Confirm the package exists and is maintained, and that its license works with your project, as GitHub's guide recommends.

A package name that doesn't exist today can be registered by an attacker tomorrow. If the install fails, send the change back so the import never reaches your lockfile.

Methods need the same check. Search the library's docs for the exact signature of each new call, at the version pinned in your lockfile, since an invented method name can sound every bit as plausible as one that exists.

4. It uses current framework patterns

Models learn from years of public code, and they reproduce APIs that newer versions of your stack have deprecated. Python's datetime.utcnow(), for example, has been deprecated since Python 3.12, with datetime.now(UTC) as the replacement (Python docs).

Compare each pattern against the versions in your lockfile, and watch for old idioms mixed into a modern codebase, like class components showing up in a React app written with hooks.

Pro tip: list your framework versions and banned patterns in the rules files your tools read. Copilot code review reads AGENTS.md and .github/copilot-instructions.md, and CodeRabbit picks up those plus CLAUDE.md and .cursorrules by default (CodeRabbit docs).

With the rules in one place, the reviewer and the agent end up working from the same instructions.

5. It handles security and user input safely

Spend extra time here. Trace every input from where it enters the code to where it's used:

• Authorization: Each endpoint the change adds confirms that the caller is logged in and has the right role for the action. Broken access control ranks #1 in the OWASP Top 10:2025.
• Queries: SQL is parameterized. Queries assembled from strings go back to the author.
• Secrets: No API keys, tokens, or connection strings anywhere in the change, test fixtures included. GitGuardian detected 23.8 million new secrets in public GitHub commits in 2024 (report).
• Output and errors: User input is escaped before it renders, and error messages don't echo stack traces or credentials.
• Logs: Nothing writes personal data or tokens to a log line.

Veracode's spring 2026 benchmark gave models 80 tasks in Java, JavaScript, C#, and Python, with prompts that never mentioned security. They introduced a known vulnerability in 45% of cases (Veracode).

Since those prompts said nothing about security, the guardrails you set before an agent writes code carry a lot of weight. Our 9 vibe coding practices cover them.

6. It performs at production data volumes

Think about the sample data in your prompt. If it had five rows, the agent's code has only run against five rows. Four patterns tend to fail as the data grows.

• Database calls inside a loop (the N+1 pattern)
• Queries with no limit or pagination
• Whole tables or files loaded into memory
• Network calls with no timeout

Ask the author what happens at 100,000 rows. If they can't answer from the code, test it on a production-sized dataset before you approve.

7. It follows your codebase's conventions

The agent doesn't know your team already has a formatCurrency() helper, so it writes a second one. Qodo lists "duplicated logic" and "standards drift" among the ways AI-generated code fails (Qodo).

Check naming, error handling, folder placement, and which logging library the change uses. If you find a duplicate helper, ask the agent to call the one your team already has.

8. It does what the ticket asked, and only that

Put the original prompt or issue next to the diff. Watch for edits to neighboring files, renamed variables, and features the ticket never asked for. Each extra line is code outside the review plan.

Move those extras to their own pull request or revert them. Last, look for requirements from the ticket that never made it into the code.

Machine checks to run before you read the diff

Scanners and AI reviewers should clear the mechanical problems first, so your own time goes to intent and risk. Two kinds of tools split that work, and you'll want at least one of each. We group them by type, with no ranking inside each group.

Security linters and static analysis

These scanners apply fixed rules, so the same code gets the same result on every run. You want that repeatability from any check that can block a merge.

Semgrep

Semgrep matches code against rules written in the syntax of the code they catch, so a new rule is quick to read and write.

• What it catches: Vulnerabilities in 35+ languages with Semgrep Code, vulnerable dependencies your code reaches with Supply Chain, and hardcoded secrets with Semgrep Secrets.
  
  For agent sessions, Semgrep Guardian, launched June 23, 2026, scans "every file an agent touches" inside any agent that supports MCP, Cursor and Claude Code included (Semgrep blog).

• Watch out for: The open-source Community Edition can't track data beyond a single function or file. Cross-file analysis comes with Semgrep's platform, and the Free edition includes it.

• When to run it: Before commit and on every pull request in CI. Guardian adds a scan while the agent is still writing.

• Pricing: Teams starts at $30/month per contributor for Semgrep Code, with Supply Chain at $30 and Secrets at $15 per contributor a month. The Free edition covers up to 10 contributors and 10 private repos.

Bandit

Bandit is an open-source Python security linter from the PyCQA project. It builds an abstract syntax tree from each file and runs its test plugins against it.

• What it catches: Common Python security issues, with named tests such as hardcoded_password_string (B105), subprocess_popen_with_shell_equals_true (B602), hardcoded_sql_expressions (B608), and yaml_load (B506) (plugin list).
• Watch out for: Python is the only language, and it reads one file at a time, so it won't follow a value through your call graph.
• When to run it: Pre-commit and in CI. On a legacy codebase, save a JSON baseline and pass it with -b, so Bandit reports only new issues.
• Pricing: Free and open source under the Apache License 2.0.

SonarQube

SonarQube puts a pass/fail quality gate on each pull request for bugs, vulnerabilities, secrets, and test coverage on new code.

• What it catches: Since the 2026.1 LTA, SonarQube Server checks AI-written code against "Sonar way for Agentic AI," a quality gate that's stricter on security and new dependency risk and looser on minor maintainability issues.
  
  Version 2026.5 went further and added the Hunter Agent for Server, which looks for broken access control, business logic, and authentication flaws (What's new).

• Watch out for: The Hunter Agent is a separate purchase that needs a Server Enterprise or Data Center license and your own Anthropic key, so the agentic checks sit well above the entry price.

• When to run it: Make it a required status check on every pull request, and let SonarQube for IDE catch issues while you write.

• Pricing: SonarQube Cloud Team starts at $34/month, billed monthly by credit card, for up to 100k lines of code. Private projects up to 50k lines are free. Enterprise is billed annually through sales, and Server editions are priced per instance, per year, by lines of code.

Snyk

Snyk Code scans in the IDE and on every pull request, and its Agent Fix re-checks each patch to confirm the issue is gone and no new one appeared (Snyk docs).

• What it catches: SQL injection and cross-site scripting, plus dependency, container, and IaC scanning on the same platform. Snyk Secrets for hardcoded credentials became generally available in August 2026 (Snyk).
• Watch out for: Snyk Code skips files larger than 1MB, and Snyk retired its Code Quality product in August 2026, so style and maintainability checks need another tool.
• When to run it: In the IDE while you code, then as a pull request check before merge.
• Pricing: Team starts at $25/month, billed monthly, for teams of up to 10 developers, with 1,000 Snyk Code tests a month. Free includes 100 Snyk Code tests a month, and Enterprise runs on prepaid credits at $1 per credit.

AI code review tools

These reviewers read the diff with a language model and the surrounding repository as context. They comment on logic and intent, such as whether the code matches the ticket, which fixed rules can't check.

They can also miss bugs, so run them after the scanners and before a human reads the diff.

CodeRabbit

CodeRabbit comments on pull requests in GitHub, GitLab, Bitbucket, and Azure DevOps, and runs bundled linters and security scanners underneath, including Semgrep, TruffleHog, Checkov, and Trivy (tool list).

• What it catches: Logic and convention issues in the diff, with results from the bundled scanners folded into the same comments. CodeRabbit picks which tools run based on the languages and file types in your repo.
  
  Over time, its Learnings feature stores your team's replies and applies them to later reviews.

• Watch out for: Every plan caps pull request reviews per developer per hour, from 5 on Essentials to 12 on Enterprise, and Deep Scan and the on-demand Security Scan are billed separately from the base plan.

• When to run it: On every pull request, and from the CLI before you push.

• Pricing: Essentials costs $30 per developer per month billed month-to-month, or $24 billed annually. Team is $60 ($48 annually) and Advanced is $90 ($72 annually). The Free plan covers pull request summaries, and open-source projects get Team features at no cost.

Qodo

Qodo runs specialized review agents on each pull request, with the full codebase as context, and turns patterns from your pull request history into rules.

• What it catches: Bugs, rule violations, and places where the code drifts from the ticket. Cross Repo Review looks for breaking changes in shared libraries and APIs before merge.
• Watch out for: There's no permanent free tier, and audit logs, bring-your-own-key, and on-prem deployment are reserved for Enterprise, which starts at 30+ users.
• When to run it: On pull requests, and earlier through review skills inside a developer's coding agent.
• Pricing: Pro Team costs $0.015 per credit, pooled across the team and billed monthly with no annual commitment. The smallest pack is 2,000 credits, which Qodo estimates at about 14 reviews a month, and unused credits expire each cycle. Every workspace starts with a 14-day trial.

GitHub Copilot code review

Copilot code review is GitHub's own AI reviewer, included in every paid Copilot plan.

• What it catches: Issues in any language, guided by your rules in .github/copilot-instructions.md, path-specific .instructions.md files, and AGENTS.md.

• Watch out for: It doesn't review dependency files such as package.json and Gemfile.lock, so a new dependency added there gets no AI review.
  
  Each review also consumes AI credits, which GitHub estimates at $0.05 to $1 on "Lite" effort and $0.25 to $5 on "Balanced," plus Actions minutes.

• When to run it: Assign Copilot to a pull request, or set it to review new pull requests and pushes on its own.

• Pricing: Copilot Pro is $10/month. Business is $19 per granted seat per month and Enterprise is $39 per granted seat per month (plans), with review costs drawn from AI credits on top.

Greptile

Greptile builds a graph of how your repository's files and functions depend on each other, then reviews each pull request against that graph.

• What it catches: Effects of a change that reach past the diff, plus violations of coding standards you write in plain English. It also learns your conventions from your engineers' pull request comments.
• Watch out for: Billing is per review credit, so cost rises with pull request volume, and the deeper review tiers cost 3 credits (Plus) or 10 (Apex). Self-hosting is Enterprise only.
• When to run it: On pull requests in GitHub, GitLab, or Bitbucket.
• Pricing: Pro is $1 per credit, with unlimited developers, no seat fees, and 1 credit per base review. Greptile's page doesn't state a billing cycle for Pro and offers custom annual contracts. Starter is free for 1 developer with 50 credits a month.

Review tools at a glance

Pricing is correct as of November 2026. Monthly-billed prices are listed first. Verify with each vendor.

How to handle large AI-generated diffs

A 2,000-line pull request is too long to read carefully in one sitting. Break it down with these five steps.

1. Ask for the plan first. Have the agent list the files it will touch and why. You can reject a bad plan before any code exists, which takes far less time than rejecting a finished diff.
2. Split mechanical from behavioral. Renames, formatting, and moved files go in one pull request that the scanners clear. Logic changes go in another, and that's the one you read line by line.
3. Read in risk order. Start with authentication, data access, migrations, and public APIs. UI copy and styling go last.
4. Collapse generated files, except the lockfile. Skip snapshots and build output, but read the lockfile's diff, since every new package shows up there.
5. Write the size limit down. GitHub's guide suggests documenting your expectations for AI-generated code in CONTRIBUTING.md. Add your own maximum pull request size to that file and point agents at it.

When to reject the change and re-prompt

Fix it by hand when the miss is small and local, like a wrong constant or a missing null check. Reject the change and re-prompt when:

• The approach is wrong, like the wrong library or layer, or a new service where a function would do.
• The same mistake repeats in several files, which points to a problem in the prompt.
• Tests were deleted or skipped to make CI pass. Loosened assertions count too.
• The diff spreads across files well outside the ticket's scope.
• An import points to a package that doesn't exist, since the agent may have written other code around it.
• You've read a block twice and still can't explain it. GitHub's review guide also warns against accepting code that would take longer to refactor than to rewrite.

A good re-prompt names the failed check, the files involved, and the constraint the first attempt broke. Then add that constraint to your rules file, so the next session starts with it.

Common mistakes to avoid

Three habits weaken the review. The first is approving because the AI reviewer left no comments. That only tells you it flagged nothing, and the diff still needs a human read.

The second is reviewing the diff without the prompt, which leaves you guessing at intent. Check 8 only works with the ticket in hand.

The third is turning every AI comment into a blocker. AI reviewers comment on minor style points next to serious bugs until you tune them.

Tools like CodeRabbit and Greptile learn from your team's replies, so the noise drops as you go. Until then, a team that has to resolve every comment tends to start skimming past them.

Who owns AI-generated code review on your team

Your team decides who answers for an agent's code, so write these four rules down before the next agent-written pull request lands.

• The person who prompted owns the change. They answer for it in review the way they would for code they typed. Sensitive paths also get a named owner, set through CODEOWNERS or your Git host's equivalent.

• Deterministic gates block the merge. Build, tests, a SAST check with a severity threshold, dependency scans, and secret detection run as required status checks.

• A human approves every production change. By default, Copilot's reviews don't count toward required approvals (GitHub Docs).
  
  That changed for teams that opt in on October 28, 2026, when Copilot approvals reached general availability. Once an admin turns them on, a Copilot sign-off can satisfy your required-approval rule (GitHub Changelog).
  
  Even with approvals on, require a person's sign-off on every production pull request. Someone on the team has to be able to explain why the change shipped.

• Every approval leaves a record. Who approved, which scans ran, and which flagged issues were waived should all be traceable later.

For the full model, our guide to AI code governance covers visibility, quality guardrails, security scanning, review workflows, and audit trails. The AI code guardrails breakdown shows where each control sits, from the IDE through to CI/CD.

How Superblocks handles AI-generated code review

Apps that business teams make on internal-tool platforms can live outside the repo your scanners watch, and the checks above don't run on them. Superblocks gives those builders one approved route to production.

Builders create apps with Clark by Superblocks, and IT sets the review and security rules once for every app published through the platform. Git-connected apps run the same checks in your CI.

Superblocks covers that review before and after an app is published.

• Pre-publish security scans: Code Security has been on for all customers since October 9, 2026, in Blocking mode by default (new custom policies start in Advisory).
  
  Before each publish, a Policy Agent also checks the app's dependencies against known CVEs, and Clark can fix the issues it raises (release notes).

• Logged overrides: Admins set each policy to Advisory, Blocking with exceptions, or Blocking. Under Blocking with exceptions, anyone with deploy access can click "Publish anyway."
  
  Those overrides stay visible, because the full history of each scan, every override included, is recorded as audit log events (how findings work).

• Your Git, your CI: Git source control works with GitHub, GitLab, Bitbucket, and Azure DevOps (connect to Git). Builders open pull requests in your repository, where the tools from the machine-checks section run on that code.
  
  In exchange, Git-connected apps skip the pre-publish Policy Agents, and those checks move to your CI pipeline (release notes).

• Deploy permissions: Only builders with permission to deploy can publish an app to production (SDLC docs).

• Audit logs: Builder edits, deploys, permission changes, end-user activity, and credential updates are logged (audit logs), and the Superblocks MCP server can query audit events and compute aggregate metrics (MCP server).

Published apps also get hourly CVE scans, and the Security Center shows each app's SBOM for current and past versions (release notes).

Book a demo to see how Superblocks scans, controls, and audits the apps your teams make with AI.

Frequently asked questions

How do you do a code review using AI?

To do a code review using AI, run deterministic checks first, meaning the build, the test suite, and a SAST scanner like Semgrep or SonarQube. Next, add an AI reviewer such as CodeRabbit, Qodo, Copilot code review, or Greptile to comment on the pull request.

Last, a human reads the diff against the original ticket with the checklist open and gives the final approval.

Should AI review AI-written code?

Yes, AI should review AI-written code after the scanners and before a human, because it comments on every supported file in the diff, while a person's attention drops on a 1,400-line pull request.

Keep the human sign-off, since a model can share the blind spots of the model that wrote the code and miss the same bug.

Can AI review code without a human?

No, AI shouldn't review code without a human for anything headed to production. Once an admin enables Copilot approvals, they can satisfy required-approval rules, and a person stays in the loop only if your team requires one.

So require a developer's approval on every production pull request, and route sensitive paths to a named owner through CODEOWNERS.

What should an AI-generated code review checklist include?

An AI-generated code review checklist should cover 8 checks. The first four confirm that the code compiles with no new warnings, tests pass with none deleted or skipped, every package and API exists, and framework patterns are current.

The last four confirm that security and user input are handled safely, the code performs at production data volumes, it follows your conventions, and its scope matches the ticket.