How should you review AI-generated code before you merge it?

What is different about reviewing AI-written code?

Code review is a second person reading a change before it joins the main branch. The basics do not change when a model wrote the change. Google's public guide, What to look for in a code review, lists design, functionality, complexity, tests, naming, comments, style and documentation, and tells reviewers to "look at every line of code that you have been assigned to review."

Three things make AI-written changes worth extra care:

• Confidence is not evidence. In the user study by Perry et al. (arXiv 2211.03622), participants with an AI assistant wrote significantly less secure code than those without one and were more likely to believe it was secure.
• Security bugs are common in generated code. Pearce et al. (arXiv 2108.09293) generated 1,689 programs across 89 scenarios and found about 40% vulnerable, measured against the MITRE Top 25 weakness list.
• There are new failure types. Models invent dependencies (see why AI code imports packages that do not exist) and pass model output to places that execute it, which OWASP calls improper output handling.

The diff also tends to be large. Google's guide warns against over-engineering, "functionality that isn't presently needed", which is worth checking when a short prompt produced a long change.

What should the reviewer check?

Check	Why it matters for AI code	How to do it
Every new dependency	Hallucinated or squatted package names	npm view <name> or the PyPI page, before install
Secrets in the diff	Keys pasted into prompts end up in code	Search the diff for tokens; turn on secret scanning
Output handling	Model text reaching innerHTML, eval, a shell or SQL	Search for those sinks; require parameterised queries
Tests	Generated tests may only restate the code	Break the code on purpose and confirm a test fails
Scope	Extra features nobody asked for	Compare the diff to the issue or prompt
Licence and origin	Copied public code may carry a licence	Note where the code came from in the pull request

The output handling row has its own thread for front-end code: how to stop a coding assistant from using innerHTML.

How do you review an AI-generated pull request, step by step?

1. Read the prompt or issue first. Know what was asked so you can spot what was added beyond it.
2. Check out the branch and run it. Google's guide says checking behaviour matters most when a change has user-facing impact. Run the app, not only the tests.
3. Read every line of the diff. If you cannot explain a block, ask the author to explain it or rewrite it. Code nobody on the team understands is a maintenance cost.
4. Look up each new package in its registry and confirm it is the project the docs name.
5. Search for dangerous sinks: innerHTML, eval(, exec(, child_process, raw SQL strings, dangerouslySetInnerHTML. Each one needs a reason.
6. Test the tests. Change a condition in the code and confirm at least one test goes red. The guide's question is "Will the tests actually fail when the code is broken?"
7. Run the automated checks: linter, type checker, static analysis and secret scanning. Read what they report; do not just wait for green.
8. Record how the change was made. A trailer such as Assisted-by: in the commit keeps that history; enforcing an Assisted-by trailer covers how teams do it.
9. Approve only what you would defend. If the change is too big to read properly, ask for it to be split.

Can an AI tool review the code instead?

It can add a pass; it should not be the only one. GitHub's documentation for Copilot code review, read on 16 October 2026, says: "Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot's feedback carefully. Supplement Copilot's feedback with a human review."

Review layer	Good at	Misses
Linters and type checkers	Exact rules, every time, on every file	Intent, design, anything not written as a rule
Static analysis and secret scanning	Known vulnerability patterns and credential formats	New patterns, logic errors
AI review tools	Reading the whole diff quickly, suggesting fixes	Not guaranteed to find all issues, per the vendor's own docs
A human reviewer	Design, scope, "should this exist at all"	Fatigue on long diffs, which is why diffs should be small

One detail from the same GitHub page matters for AI-generated changes: Copilot reads repository custom instructions, agent instructions and skills "from the head branch (the branch with your changes), not the base branch." A pull request can therefore change the instructions its own reviewer follows, so review edits to .github/copilot-instructions.md or AGENTS.md as carefully as code.

How do you make human review mandatory on GitHub?

GitHub's protected branches settings (read 16 October 2026) let you:

1. Turn on Require pull request reviews before merging and set the number of approvals.
2. Turn on Dismiss stale pull request approvals when new commits are pushed, so an approval covers the diff that was reviewed.
3. Require review from code owners for sensitive paths, which GitHub defines in a CODEOWNERS file.
4. Turn on Require status checks to pass before merging for your linter and tests.

CodeLifter's guide to vibe coding security has a ten-minute routine to run before you ship.

Short version

• Use the normal review checklist, then add AI-specific checks: dependencies, secrets, output handling, tests that can fail.
• Run the change, read every line, and ask for a split when the diff is too big to read.
• AI review tools are an extra pass; GitHub's own docs say to supplement Copilot's review with a human one.
• Review changes to instruction files as code, because reviewers may read them from the pull request branch.
• Enforce it with required reviews, stale-approval dismissal and required status checks.