A Code Review Checklist for AI-Generated Pull Requests

Reviewing a pull request written by an AI coding agent is not the same as reviewing a colleague's. The code usually looks clean and confident, the description is fluent, and the mistakes are in different places: an agent rarely makes a typo, but it will happily invent a helper that already exists, weaken a test to make it pass, or add a dependency that does not do what its name suggests. This checklist focuses on those differences.

Before you read the diff

• Read the issue and the plan first. Know what was asked for and what the agent said it would do, so you can spot the difference.
• Check the size. If the diff is much bigger than the task, stop and ask why before reviewing line by line. Unrequested changes are the most common problem in agent pull requests.
• Check the validation result. Which commands ran, and did they pass? If the repository has no tests, review with that in mind.

Scope

• Every changed file is explained by the task.
• No "while I was here" refactors, renames, or formatting changes in unrelated files.
• No changes to configuration, CI workflows, or infrastructure unless the task was about them.
• Database migrations, if any, are new files — not edits to migrations that have already run.

Tests

• No existing test was deleted, skipped, or marked as expected to fail.
• No assertion was loosened — watch for exact checks turned into "is not null" or "contains".
• Snapshot or fixture files were not regenerated wholesale to match new output.
• New tests would actually fail without the change. A test that only checks that a function runs proves nothing.
• Mocks do not replace the very thing being tested.

Dependencies

• Every new package is necessary — the standard library or an existing dependency could not do it.
• The package is the one you think it is. Agents sometimes suggest package names that do not exist or are near-misses of popular ones, and attackers register such names. Check the registry page, the publisher, and the download count.
• The lockfile changed only as expected, without unrelated version bumps.

Security

• Authorization checks are present on every new route, endpoint, or action — agents often copy the handler and forget the policy.
• User input is validated, and queries are parameterized, not built with string concatenation.
• No secrets, tokens, or real credentials in code, tests, fixtures, or logs.
• Errors do not leak internal details to users.
• In multi-tenant code, every new query is scoped to the current tenant or workspace.

Correctness

• Edge cases are handled: empty inputs, very large inputs, missing records, concurrent requests.
• Errors are not swallowed. Watch for empty catch blocks and blanket "return null on failure".
• Called functions and APIs actually exist and behave as the code assumes — agents occasionally call methods from a different version of a library.
• Comments and docstrings describe what the code does, not what the agent intended it to do.

Fit with the codebase

• The change follows existing conventions for naming, structure, and error handling.
• It reuses existing helpers instead of adding near-duplicates.
• No dead code, unused imports, or leftover debugging output.
• Generated files and build output were not committed.

Process

• The reviewer is not the same person who requested the change.
• Sensitive paths have been reviewed by their code owners.
• The pull request explains how to roll back.
• If the change is wrong in approach, send the agent back with instructions instead of fixing it by hand — your instructions improve the next run.

Catch problems earlier

Most items on this list are cheaper to prevent than to review. Approving a plan before the code is written stops scope creep and test-deleting plans before they happen — see how to add human approval to AI coding agents. Running your own checks in a sandbox and blocking pull requests that fail them means the review starts from green — see how to validate AI-generated code before merging.

How Dualzo handles this

Dualzo does both before a pull request reaches you: every plan is approved by a person, every task is validated on your own commands in a sandbox, and the pull request lists what changed per task, which checks ran, and how to roll back. That is the core of AI coding governance.