TL;DR
Review AI-generated code in two passes. First, the author proves that the change matches the request, stays within a small blast radius and has tests that can fail for the right reason. Then a second person reviews the important decisions, risky boundaries and evidence. A green test run is useful, but it cannot prove the tests describe the intended behaviour. The change is ready only when a human can explain it, reproduce the checks and own the remaining risk.
In this article
7 min read
AI can produce a plausible change faster than a reviewer can understand it. That changes where the work sits. The person using the coding agent must do the first verification before asking somebody else to approve the pull request. The reviewer then challenges the parts where judgment, product context or security risk matter.
This is the practical answer to a question developers now ask directly: how do you review and validate AI-generated code before it reaches production? Treat the generated diff as an untrusted proposal, make the author prove what it does, and make the evidence as reviewable as the code.
Put the first verification back on the author
The author is the person who accepted the generated change, even when an agent wrote every line. OWASP’s 2026 Secure Coding with AI Cheat Sheet says every AI-assisted change needs a human owner and warns against using an AI review as a substitute for human review. That ownership has to mean more than a name on the commit.
Before opening the pull request, the author should be able to answer four questions without asking the agent again:
- What behaviour changed? Name the user-visible or system-visible result.
- Why were these files touched? Account for every changed module, dependency and configuration file.
- Which failure would the tests catch? Point to a test, change the implementation deliberately and watch that test fail.
- What remains uncertain? State the edge case, environment difference or assumption that still needs another person’s judgment.
If the author cannot explain a block of generated code, the answer is not a longer pull-request description. Reduce the change until it can be understood, or investigate the code before asking for review. The Eliyce article on comprehension debt in AI-generated code explains why unexplained code becomes a maintenance cost even when it works today.
Verify behaviour from the request, not from the diff
A diff can be internally tidy and still solve the wrong problem. Start with the request, specification or acceptance examples. Write down the behaviours that must become true, the behaviours that must remain unchanged and the failures the system must reject.
Then connect each behaviour to evidence:
Comparison
| Question | Useful evidence | What it cannot prove alone |
|---|---|---|
| Does the requested path work? | Focused automated test plus a demonstrated result | That nearby paths still work |
| Did existing behaviour survive? | Relevant regression suite and before/after comparison | That the suite covers every important assumption |
| Is the boundary secure? | Authorization tests, static analysis and manual boundary review | That business rules are correct |
| Can it be released safely? | Migration rehearsal, rollback check and production-like test | That every production condition was reproduced |
NIST’s minimum standards for developer verification describe verification as a combination of techniques, including automated tests, static analysis, secrets checks, structural tests, historical tests and dependency review. The point is not to run every technique on every change. Choose checks that match the failure you are trying to detect.
Test the tests, especially when AI wrote both sides
Generated tests can agree perfectly with generated code because both share the same mistaken assumption. A test that executes a method and asserts its current output proves consistency, not correctness.
Use mutation as a quick challenge. Break the implementation in a way the requirement says must matter: remove an authorization check, reverse a condition, change a boundary value or skip a state transition. The relevant test should fail with a message that points to the broken behaviour. Restore the code and confirm it passes again.
Also inspect what the test never observes. A controller test may assert 200 OK while ignoring the database change, emitted event or permission boundary. A unit test may mock the collaborator that contains the actual risk. Coverage can show which lines ran; it cannot show that the assertions express the product promise.
For a high-risk change, separate the source of the check from the source of the implementation. A reviewer can derive an acceptance example from the ticket, an existing production trace or a known failure rather than asking the same agent to invent another test from its own code.
Shrink the blast radius before reading every line
Large generated diffs create a review problem before the reviewer reaches the first line. If one change modifies a schema, API, business rule, user interface and deployment configuration, a reviewer has to hold too many relationships in mind at once.
Inspect the file list and dependency graph first. Ask whether each changed area is required for the stated behaviour. Separate opportunistic refactoring, formatting and dependency upgrades from the functional change. A smaller pull request is easier to test, easier to revert and harder to hide an unrelated mistake inside.
Risk should decide the depth of review:
Decision guide
- Low-risk, reversible change: focused tests, linting and one human review may be enough.
- Business-rule or data change: add regression examples, data-boundary checks and a rollback plan.
- Authentication, authorization, payments or destructive action: require a reviewer with the relevant domain knowledge and explicit negative tests.
- Unfamiliar or cross-cutting change: stop and split it before approval rather than compensating with a longer checklist.
GitHub’s documentation on protected branches and pull-request controls shows how required status checks, approving reviews and code owners can make these rules enforceable. The repository can block a merge when evidence is absent; it cannot decide whether the evidence tests the right thing.
Make the pull request carry the evidence
A reviewer should not have to reconstruct the agent session. The pull request needs a small evidence packet that survives after the chat disappears:
- State the requested behaviour and the important behaviour that must remain unchanged.
- List the changed areas and explain any surprising file or dependency.
- Record the exact checks that ran and their result on the final commit.
- Show one meaningful result: a response, screenshot, migration rehearsal or failing-then-passing test.
- Name the remaining risk and the person who can accept it.
The record should be specific enough that another developer can reproduce the decision. “Tests passed” is weak evidence when it omits which tests, which commit and what they were meant to prove. GitHub notes that required checks must pass on the latest commit SHA; the same principle applies to every piece of review evidence.
This process does not require treating AI-generated code as uniquely bad. It applies an old engineering principle to a much faster producer: evidence must scale with risk, and the person asking for approval must understand what they are asking another person to accept. The AI code evidence receipt develops the durable record in more detail.
If your team is producing changes faster than it can explain and verify them, Fix this for your team. The Programme applies a shared delivery workflow to real backlog work and compares the result with your starting point; it is a fit conversation, not a promise of a particular outcome.
Frequently Asked Questions
How do you review and validate AI-generated code before it reaches production?
Require the author to explain the intended behaviour, account for the files changed, challenge the tests and record the checks on the final commit. A second person then reviews the decisions and risks that automation cannot settle. Merge only when both people can state what the evidence proves and what it leaves open.
Do developers need to prove they understand AI-generated code before they submit it?
They need enough understanding to own the change: describe its control flow, identify its important dependencies, predict the main failure modes and maintain it without relying on the original chat. That is practical accountability. It does not require memorising every line or passing an artificial oral examination.
What should the author verify before asking another developer for review?
The author should reproduce the requested result, inspect every changed file, remove unrelated edits, run the relevant checks and test at least one meaningful failure. They should also say where they remain uncertain. This keeps the reviewer focused on judgment instead of basic cleanup.
How do you know whether AI-generated tests are actually useful?
Deliberately introduce a fault that violates the requirement and confirm the expected test fails. Then inspect whether the assertion observes the real outcome rather than an internal detail. A useful test distinguishes acceptable behaviour from a plausible but wrong implementation.
When is an AI-generated pull request too large to review safely?
It is too large when the reviewer cannot connect each changed area to one coherent decision, or when unrelated risks require different reviewers and rollback plans. Line count is only a warning signal. Crossing several trust boundaries in one change is the stronger reason to split it.
What evidence should accompany an AI-assisted pull request?
Include the intended behaviour, affected areas, exact checks and final commit, one inspectable result, known limitations and the named owner of the remaining risk. Keep the evidence in the repository or delivery system so a future incident review does not depend on a private agent transcript.
