How to Verify AI-Generated Code Before Merging

Independent guide · Edited 26 October 2026. This is a review workflow, not a benchmark or a claim of formal correctness.

An AI coding agent opens a pull request: reject negative quantities in a shopping cart. The patch looks small, the description sounds convincing, and the tests pass. Before merging, you still need to establish what those tests demonstrate and whether the patch changes anything beyond the requested rule. Start with evidence from the repository rather than the agent's explanation of its own work.

The cart change below is an illustrative example. The same process applies to a coding agent editing a service, a library, or an internal tool. No user code is uploaded by this guide or its copy button.

1. Turn the request into an acceptance contract

Write the expected behavior before inspecting the implementation. For this PR, negative quantities should fail without changing the stored cart. Decide explicitly whether zero removes an item, whether fractional quantities are supported, and what happens when a client sends a string instead of a number. The example cannot answer those product questions for your project.

Identify the entry points that can mutate a cart: the web form, the API, background jobs, and any internal callers. A check in the UI alone may leave another caller untouched. Record what must remain stable, including error formats, permissions, totals, and existing carts. If the agent also rewrites checkout or adds a dependency, ask why that is necessary; split unrelated changes into a separate PR.

2. Read the diff, then follow the data

Read the actual changed files, including tests and configuration. Follow a quantity from the request boundary through parsing, validation, authorization, persistence, and the response. Check the surrounding functions and their callers, not only the highlighted lines. A correct condition in the wrong layer can still allow invalid state.

Compare the diff to the acceptance contract. Look for deleted assertions, weakened types, catch-all exception handlers, new network calls, changed defaults, and unrelated formatting that hides behavior. Ask whether a retry could repeat a side effect or whether two concurrent updates can bypass a check. An agent's summary is useful navigation, but it does not establish what the code does.

In an isolated checkout of the PR, these read-only Git commands show the patch relative to a base revision. Replace BASE_REF with your actual target branch or commit; the placeholder is not a branch to create.

git status --short
git diff --stat BASE_REF...HEAD
git diff --check BASE_REF...HEAD
git diff BASE_REF...HEAD

3. Run existing tests, then challenge the boundaries

Read the repository instructions and package scripts first. Use its documented environment and test commands rather than inventing a universal command. Review unfamiliar install hooks before restoring dependencies. Record the revision, command, environment, and exit status. If a failure also occurs on the base revision, document that baseline separately; it does not make a new regression acceptable.

For the cart PR, add tests for a negative value, the permitted lower boundary, a typical valid value, and the specified upper bound. Include malformed input, missing input, and unauthorized updates where relevant. Assert both the response and the absence of an unintended database write. If quantities affect billing, test the server path that calculates the charge as well as the form.

Write expected results from the requirement, independently of the generated implementation. A test that copies the same mistaken assumption adds little confidence. Where practical, run the regression test against the unpatched revision in a separate checkout and confirm that it fails for the expected reason. Avoid altering your active working tree just to demonstrate this.

4. Combine checks that cover different failure modes

Run the project's existing lint, type, build, and security checks. Investigate newly added exclusions, disabled rules, or changed compiler options. An empty scanner report is not a security guarantee. For authentication, payments, data deletion, and migrations, have a reviewer trace the domain-specific invariants and failure paths. Connect this PR-level evidence to your broader agent evaluation process.

5. Check what entered through dependencies

Inspect the manifest and lockfile together. Confirm that each added package is needed, spelled correctly, and resolved from the intended registry. Review install scripts, transitive changes, and requests for new permissions. Use the project's established audit process; do not send proprietary source to a new scanning service just because an agent suggests it.

Check dependency licenses and the provenance of copied code or assets. Keep required notices and follow your organization's license policy. A generated comment claiming code is original is not evidence of provenance. Unexplained copied code or incompatible terms should block the affected change until resolved.

6. Pay down comprehension debt before approval

Comprehension debt is the gap between code a team accepts and code it can explain and maintain. Generation can increase that gap when patches arrive faster than reviewers can understand them. You still need to diagnose an incident after the original conversation with the agent is gone.

For this cart PR, a reviewer should be able to explain where quantities become trusted, why validation sits in that layer, which callers share it, and what happens if persistence fails. Ask for a small walkthrough or a diagram when behavior crosses several services. Then check that explanation against the code. A second model can suggest questions, but shared assumptions can produce shared mistakes; it does not replace an accountable human reviewer.

• Can I describe the changed behavior without reading the PR summary?
• Can I name the invariants and point to the code and tests enforcing them?
• Do I understand data ownership, authorization, retries, and partial failure?
• Could another maintainer safely change or revert this code next month?

7. Stop on failed evidence and define rollback

If a check fails, preserve the failure and reduce it to a reproducible case. Give the agent that case and the intended behavior, then review its next diff. Do not let repeated attempts weaken assertions or expand scope until the suite turns green. Set a retry budget; persistent failures call for a smaller patch, a human implementation, or a revised requirement.

Before merging, decide how to disable or revert the feature and what signal would trigger that decision. Reverting code cannot necessarily undo a schema migration, restore deleted records, or reverse an external payment. Review those recovery steps separately. Preserve teammates' work and follow the repository's normal revert procedure rather than resetting a shared branch.

What changes for AI large-scale code verification?

When agents produce many PRs, keep the same evidence requirements and change the review queue. Route changes by risk and ownership, keep patches small, run appropriate checks in CI, and require specialist approval for sensitive paths. Log checks against the exact revision that was reviewed; a later agent edit needs a fresh assessment of the affected evidence.

Track escaped defects, review time, and rollback events alongside test results. Lines generated and coverage percentages cannot tell you whether reviewers understood the behavior. AI-generated code comprehension issues become visible when no maintainer can explain a change, failures recur, or fixes require another opaque rewrite. Reduce batch size and improve explanations before increasing output.

Copy the review checklist

Paste this into a PR description and attach concrete evidence to each item. The button copies only this checklist using your browser clipboard.

Related guides

• Measure agent reliability with repeatable evaluations
• Review tool permissions and agent security
• Understand where coding agents fit in a development workflow

how do AI agents work — return to the complete AI agent architecture guide.