Reviewing AI-generated code: a checklist for leads

Why AI-assisted changes need adjusted review

Traditional review habits evolved around changes written by a colleague who understood them. Reviewers learned to trust certain signals: clean formatting suggests care, passing tests suggest correctness, a confident description suggests the author checked. AI tools produce those signals whether or not the change is right. The reviewer's job shifts toward questions the polish cannot answer: is this the right change, does it fit the system, and does the author understand it?

GitHub's own documentation on reviewing AI-generated code makes the same point in practical terms: run tests and static analysis first, confirm the change fits the project's requirements and architecture, scrutinize new dependencies, and watch for fabricated APIs, ignored constraints and deleted tests.

Set the ground rules before the review

• The author owns the change. Whoever opens the pull request must be able to explain it. This belongs in your team's AI coding assistant policy.
• Small changes only. Agree on a practical size limit. Generated changes grow quickly and large diffs get skimmed.
• Intent up front. The description says what problem is being solved, the approach, and what was considered and rejected.
• Automation runs first. Build, tests, linting, type checks, secret scanning and dependency checks pass before a person spends time on it.

The review checklist, in order

1. Is this the right change?

• Does it solve the problem in the ticket, and only that problem?
• Is there a simpler approach, or an existing helper that already does this?
• Does it change files or behavior outside the task? Agents in particular can widen scope silently.

2. Dependencies and imports

• Read the imports and any lockfile or manifest changes before the logic.
• Does every new package exist in the expected registry, under the expected name? Suggested package names can be wrong or can resemble a real package.
• Is a new dependency justified, maintained and under an approved license?

3. Correctness

• Do the APIs, functions and configuration options used actually exist in the versions you run?
• Are edge cases handled: empty input, errors, timeouts, concurrency, time zones, large values?
• Are constraints from the ticket or design respected, not just the happy path?

4. Tests

• Do the tests assert what the code should do, or merely what it currently does?
• Would a test fail if the core logic were wrong? Try breaking the logic mentally, or actually.
• Are mocks hiding the behavior that matters?
• Were any existing tests deleted, skipped or weakened to make the change pass?

5. Security

• Input validation, output encoding, authorization checks, and handling of secrets.
• No credentials, tokens or internal URLs in code, comments or test fixtures.
• Security-sensitive areas (authentication, payments, cryptography, access control) get a second reviewer.

6. Fit and maintainability

• Does it follow the codebase's existing patterns, or introduce a new one without discussion?
• Is there duplicated logic, unnecessary abstraction, or dead code?
• Will someone understand this in a year? Comments explain why, not what.

7. Understanding

• Ask the author to explain one non-obvious part, and how it fails.
• If they cannot, the change is not ready, however good it looks.

Divide the work between tools and people

AI review bots can be useful as a first pass. Treat their comments as suggestions from another tool, not as an approval. A person still makes the final decision.

Keeping review from becoming the bottleneck

1. Watch review load. If change volume rises faster than review capacity, quality will fall. Track time to first review and open pull request age at team level. See measuring engineering work.
2. Limit work in progress. Finishing reviews comes before starting new generated work.
3. Grow reviewers. Pair junior engineers with senior reviewers. Reviewing is how people learn to recognize what the tool gets wrong.
4. Review design earlier. A short design note before implementation prevents the expensive review comment: "this is the wrong approach."

How to write review comments

• Ask about behavior: "What happens here if the request times out?" teaches more than "handle timeouts."
• Separate must-fix from suggestions, so authors know what blocks the merge.
• Comment on the change, not the tool. "This duplicates the retry helper" is useful; "the assistant got this wrong" is not.
• Explain the why when you point to a team convention, so the next change gets it right, whether a person or a tool writes it.

Warning signs in a team's review culture

• Large pull requests approved within minutes.
• Review comments that only concern style.
• Authors answering questions with "the assistant suggested it."
• Reverts and follow-up fixes rising after merges. DORA calls the latter pattern deployment rework; see DORA, SPACE and DX Core 4.

Common questions

Should AI-generated code be reviewed more strictly than human code?

It should meet the same standard. In practice that means reading it more slowly, because the usual signals of care are present whether or not the change is correct.

Can an AI tool approve a pull request?

It can comment. Most teams keep approval and merge with a named person, and many repository settings can enforce that. Decide explicitly rather than by default.

How do I review a change I suspect the author does not understand?

Ask open questions about behavior and failure modes. Make it a normal part of every review so it never feels like an accusation.

Do reviewers need to know which lines were AI-generated?

Usually the approach and intent matter more than line-level origin. Regulated teams may need a record of AI assistance; see AI in regulated engineering.