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

Source: https://codelifter.com/forum/posts/how-should-you-review-ai-generated-code-before-you-merge-it/
Site: CodeLifter Forum, category Code provenance
Published: 2026-10-22. Updated: 2026-10-26. Replies: 2.

## Question by CodeLifter editors (staff), 2026-10-22

Review AI-generated code like a change from a new contributor: read every line, run it, and check that the tests can fail. Then add checks aimed at known AI failure modes, such as invented packages, unsafe handling of model output and leaked secrets. Review tools can help, but a person with merge rights should approve.

## 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](https://google.github.io/eng-practices/review/reviewer/looking-for.html), 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.](https://arxiv.org/abs/2211.03622) (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](/forum/posts/why-does-ai-generated-code-import-packages-that-do-not-exist/)) and pass model output to places that execute it, which OWASP calls [improper output handling](https://genai.owasp.org/llmrisk/llm052025-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](/forum/posts/how-do-i-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](/forum/posts/how-can-a-team-enforce-an-assisted-by-trailer-on-commits/) 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](https://docs.github.com/en/copilot/concepts/agents/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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-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](https://codelifter.com/provenance/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.

## Reply 1 by CodeLifter editors (staff), 2026-10-22

**Can Copilot's approval count as a required review on GitHub?** Only if an administrator turns that on. GitHub's [Copilot code review documentation](https://docs.github.com/en/copilot/concepts/agents/code-review), read on 16 October 2026, says every Copilot review includes an approval assessment in its overview comment, but "By default, Copilot's reviews do not count toward required approvals for the pull request." When Copilot approvals are enabled in the repository, organization and enterprise settings, Copilot "can submit an approving review that satisfies your repository's required-approval rule the same way a teammate's approval would." If new commits are pushed after it approves, the approval is dismissed.

Before you enable it, weigh two facts from the same page. The vendor says Copilot is not guaranteed to find every problem and tells you to supplement it with a human review. And Copilot reads instructions and skills from the pull request's own branch, so the change under review can alter the reviewer's instructions. If you do let it approve, keep a human approval required for paths listed in `CODEOWNERS`, such as authentication code, CI workflows and instruction files.

## Reply 2 by CodeLifter editors (staff), 2026-10-26

**Should the person who prompted the AI also approve the pull request?** Not on their own. The person who wrote the prompt has the same blind spot as any author: they know what they meant, so they read what they meant. GitHub's [protected branch settings](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) have an option for this, **Require approval of the most recent reviewable push**, which means the latest push "must be approved by someone other than the person who pushed it."

Two further settings close the gaps. By default, branch protection rules do not apply to people with admin permissions, so a repository admin can merge their own unreviewed change; **Do not allow bypassing the above settings** applies the rules to admins too. And **Dismiss stale pull request approvals when new commits are pushed** stops an approval given to an early, small version of the change from carrying over to a later, larger one. On a solo project, where no second person exists, the nearest substitute is a written checklist run on a later day, plus required status checks that do not depend on your judgement.

---
Cite as: CodeLifter Forum, "How should you review AI-generated code before you merge it?", https://codelifter.com/forum/posts/how-should-you-review-ai-generated-code-before-you-merge-it/, accessed 2026-11-12.