AI-generated code deserves the same review as any code, plus a closer look at whether the tool followed your constraints and whether you understand the patch. Fluency and a green happy-path test do not establish correctness.
This guide is for engineers reviewing code suggested by a chat assistant, editor completion, or repository-aware agent. Your team still owns the decision to merge and operate it.
1. Reconstruct the intended change
Before opening the diff, write down the requirement in observable terms: what should change, what should stay the same, and what evidence would prove it. Compare that with the tool’s summary. If the summary is vague, ask for a file-by-file explanation and the commands it ran—but verify both directly.
Scan the file list first. Look for generated files, lockfiles, permissions, configuration, migrations, unrelated formatting, or files outside the requested area. An unexpected file is a question to answer, not automatically proof of a problem.
2. Read the diff by risk
Review the behaviour with the largest consequence first:
- Access and data: Can one user read or change another user’s data? Are roles checked on the server, not only hidden in the interface?
- Input boundaries: What happens for missing, malformed, oversized, or unexpected values?
- State changes: Can retries, concurrent requests, or partial failures leave duplicate or inconsistent data?
- Error behaviour: Are failures visible and safe? Are sensitive details excluded from responses and logs?
- Dependencies and generated APIs: Is the package necessary, maintained, correctly imported, and compatible with the installed version?
- Complexity: Did a small requirement gain unnecessary abstractions, configuration, or hidden behaviour?
Use the repository’s existing patterns where they are sound. A generated helper can be technically valid and still create a second way of doing the same thing that future maintainers must learn.
3. Test the paths the patch can break
Do not accept “tests passed” without knowing which command and cases ran. Read the test changes, run the relevant checks, and add a regression test when a bug was fixed. Include denied access, empty input, failure responses, duplicates, or timeout behaviour when those follow from the changed contract.
Illustrative authorization review
Suppose a new endpoint looks up an invoice using invoiceId from the request and returns it. The happy-path test proves a signed-in user can fetch an invoice. It does not prove that the caller owns that invoice. Ask what happens when user A requests user B’s ID, and verify that server-side authorization happens before the data is returned. A client-side route guard is not evidence that the API enforces ownership.
If you cannot tell whether an authorization rule exists, trace the request to the server-side data access and ask a domain owner. Do not infer safety from the names of variables or from an AI explanation.
4. Check tool boundaries and untrusted content
For an agent, inspect what tools it used and which files it changed. Treat repository text, issue descriptions, retrieved web pages, and generated shell commands as input to review. Do not run destructive commands or grant broader permissions simply because the agent suggested them. Follow your organization’s policy for proprietary code, credentials, and external model providers.
When a dependency is added, inspect the manifest and lockfile, purpose, license and package source. Verify APIs against the installed version’s official documentation. A package name or method can be hallucinated, deprecated, or aimed at a different major version.
5. Decide whether to accept, revise, or reject
Accept a patch when you understand the behaviour, the scope matches the task, important failure modes are handled, and the evidence is adequate. Ask for a focused revision when one or two assumptions need correcting. Reject or rewrite it when the design violates a security invariant, changes unrelated contracts, adds unjustified complexity, or remains opaque after investigation.
Pull request review checklist
- The patch matches the requirement and changes only expected files.
- Authorization is enforced at the correct server boundary.
- Inputs, empty states, retries, and failure responses are considered.
- New packages and APIs are verified against current documentation.
- Tests cover the changed behaviour and meaningful negative paths.
- I can explain the code well enough to maintain it.
- The PR records the checks actually run and remaining uncertainty.
Practice
Review a small AI-generated validation change. Invent three invalid inputs and one unauthorized request. For each, point to the exact code or test that demonstrates the safe outcome. If none does, write the smallest test that would expose the gap.