How to review AI-generated code before merging

Before review: make the change reviewable

Ask for one self-contained change with its tests and a pull request description that names the user problem, intended behavior, affected boundaries, verification commands, and remaining uncertainty. Google's small change guidance recommends one focused change and related tests because reviewers can reason about smaller changes more thoroughly.

Split mechanical refactoring from changed behavior. Generated formatting, lockfiles, and migrations can hide a two-line logic error inside a large diff. If you cannot state the change's purpose in two sentences, send it back for a smaller scope or a clearer explanation before reviewing details.

The six-pass AI code review

1. 1. Confirm intent and architecture

   Read the issue, acceptance criteria, repository instructions, and nearby implementation before the diff. Write down the observable behavior that should change and the behavior that must stay stable. Check whether the agent copied an established seam or invented a second path around existing authorization, validation, caching, or error handling.

   Question to answer: Does this solve the named user problem through the codebase's intended boundary?

2. 2. Read every changed line in context

   Open whole methods and their callers, rather than reading only the diff hunk. Trace inputs, outputs, errors, state changes, and cleanup. Search for similar code and old tests. Google's review checklist asks reviewers to understand every assigned line and to bring in specialists for security, privacy, concurrency, accessibility, or internationalization.

   Question to answer: Can I explain each branch and side effect without relying on the agent's summary?

3. 3. Challenge the tests

   Run the smallest relevant test first, then the complete required suite. Read the assertions. Temporarily reverse or remove the production behavior and confirm that the new test fails for the intended reason. Check unhappy paths, authorization failures, malformed input, boundaries, time, concurrency, retries, and rollback where they matter.

   AI-written tests often repeat the implementation's assumption. A test that mocks the faulty boundary or asserts only a status code can pass while users still get the wrong result. Google's 2026 harness engineering guide recommends observable behavioral checks alongside larger end-to-end evaluation.

   Question to answer: Which realistic defect would make this test fail?

4. 4. Verify dependencies and security boundaries

   Confirm that every new package, API, command, model name, and configuration key exists in its primary documentation. Inspect the lockfile, license, maintenance status, and advisory record. Follow untrusted input through parsing, authorization, storage, logs, network calls, and rendered output. Search the diff for secrets, disabled checks, broader permissions, unsafe defaults, and generated files that should stay out of source control.

   GitHub's guide to reviewing AI-generated code specifically calls out hallucinated APIs, suspicious packages, deleted tests, licensing, and static analysis. Use scanners for coverage, then inspect business-specific permissions and data flows yourself.

   Question to answer: What can this code read, change, expose, install, or call that it could not before?

5. 5. Exercise the real user path

   Run the application in the intended environment and perform the changed task. For a web change, inspect desktop and mobile behavior, keyboard access, empty and error states, network responses, and persisted results. For a job or integration, submit one representative input and read the final state from the actual backend. A passing unit suite cannot prove that routes, templates, queues, configuration, and external contracts work together.

   Question to answer: What did a user or downstream system actually receive?

6. 6. Bind approval to the verified commit

   Record the tested commit SHA and require checks after the final rebase or merge-group creation. If another commit arrives, review its diff and rerun the affected checks. GitHub's merge queue documentation explains how a queue tests changes against the latest target branch and earlier queued work. This matters when two individually green pull requests conflict after combination.

   Question to answer: Are we merging the same code and dependency graph that passed review?

Worked example: an agent adds CSV export

An agent adds an account export endpoint, a CSV library, and a request spec. The test signs in an administrator and checks for HTTP 200. The diff looks tidy and CI passes.

• Intent: The issue allows account owners to export their own records, but the controller checks an administrator role. The implementation solves a different problem.
• Context: Existing downloads use a policy object and enqueue large exports. The new controller bypasses both conventions.
• Tests: Add owner, non-owner, suspended-user, empty-data, formula-injection, and large-export cases. Prove that changing the authorization check breaks the relevant test.
• Dependencies: The standard library already writes CSV, so the extra package adds supply-chain and licensing work without a clear benefit.
• User path: A spreadsheet interprets a cell beginning with = as a formula. Escape dangerous values and open a generated file in the supported client.
• Merge evidence: Run policy, request, export-job, security, and full-suite checks on the rebased commit.

A code-review model might flag the dependency or missing authorization. A domain reviewer still needs to know who may export data, which fields belong in the file, and how the product handles large accounts.

Where AI review helps, and where people remain responsible

Use all three where risk justifies them. Let deterministic checks reject known violations, ask AI for a critique that a person verifies, and keep merge authority with reviewers who understand the product and affected systems.

Limitations and common failure modes

• A checklist cannot replace specialist review for cryptography, payments, medical logic, privacy, infrastructure, or other high-impact work.
• More tests can create false confidence when they assert the same mistaken requirement or mock away the risky boundary.
• A green scanner does not prove secure business logic, safe authorization, or correct data retention.
• Review speed becomes a bottleneck when agents open too many changes. Reduce change size and work in progress before weakening approval rules.
• Review records lose value when they refer to an earlier commit than the one deployed.