How do you review AI-generated code in a pull request?

Review AI-generated code as if a fast, confident stranger wrote it: check intent first, then trust boundaries, dependencies and tests. The code usually compiles and reads cleanly, which is exactly why reviewers skim it. A named human must still own the merge.

Why is it different from reviewing a colleague?

A colleague has context. They know the system, the incident last spring and the reason a function validates twice. A model has only what was in its prompt. NIST's SP 800-218A, a community profile that extends the Secure Software Development Framework to generative AI, treats AI-assisted development as software development that needs the same practices, with extra attention to the AI components themselves.

So the review question shifts from "is this clean?" to "does this match what we meant, in this system?"

What should the reviewer read first?

The intent. Read the ticket and the prompt or summary before the diff. If you cannot say in one sentence what the change should do, send it back.

The edges, not the middle. Generated logic is often fine on the happy path. Look at input handling, error paths, authorization checks and anything that crosses a trust boundary: user input to query, request to file path, text to shell.

New dependencies. Models sometimes suggest packages that do not exist or that are near-miss names of real ones. Every new dependency in the diff needs a check: does it exist, who maintains it, is the version pinned, is it needed at all?

Removed code. Assistants will sometimes delete a check to make a test pass. Scan deletions as carefully as additions.

Secrets and sample data. Look for hardcoded keys, tokens and realistic-looking credentials copied from examples.

What about the tests?

A constructed example: an assistant adds a discount endpoint with five passing tests. All five exercise valid codes. None tries a negative quantity, a code from another tenant, or a replayed request. The tests prove the code does what the assistant imagined, not what an attacker will try.

Ask for one abuse-case test per change that handles input or authorization. Where possible, write it yourself or at least read it closely.

How do you keep review from becoming a bottleneck?

AI tools raise the volume of changes, and reviewers do not scale the same way. Counter this with smaller pull requests: ask the author to split a large generated diff into reviewable pieces, each with a single purpose. Put the mechanical checks in CI so humans spend their time on judgment: formatting, static analysis, dependency checks, secret scanning and test coverage on changed lines.

Also rotate who reviews security-sensitive paths such as authentication and payments, and give those reviewers a short checklist. A tired reviewer approving a four-thousand-line generated diff is the failure you are trying to prevent. Set a size limit and enforce it, and send back anything that exceeds it.

How to check or apply this

1. Require the author to state the intent and what AI tools produced which part.
2. Read the ticket, then the diff, starting with trust boundaries.
3. Verify every new dependency exists, is pinned and has a known maintainer.
4. Review deletions and changed tests as closely as new code.
5. Search for secrets and hardcoded credentials.
6. Demand at least one negative or abuse-case test for security-relevant logic.
7. Run static analysis and dependency scanning in CI, and treat findings as blocking where policy says so.
8. Keep a human approver accountable. No AI-only merges to protected branches.

Safeguard's policy gates can block merges on dependency or vulnerability findings, which catches some of the issues above automatically. A gate supports review and does not replace it.

Quick check

Sources

• NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 18 October 2026.