AI-Generated Code Review Checklist

Treat AI-generated code as an untrusted contribution. Check the requested behaviour, read the whole diff and run the tests yourself before deciding whether to merge. The reviewer still needs to explain why the code should ship.

Use this checklist with any coding assistant, adapting it to your language, repository, threat model, and review policy.

Begin with the task, not the diff

A polished patch can solve the wrong problem. Before you read the implementation, write down what the user should see, the acceptance criteria, what’s out of scope, and any known constraints. If all you have is the original prompt, fill in the missing requirements before approving the change.

Who needs the change, and what should happen?
What must not change?
Which inputs, permissions, failure states, and environments matter?
What evidence would demonstrate the intended behaviour?

The review sequence

Check the requirements. Does the change solve the stated problem, including unhappy paths and non-functional constraints?
Read the whole diff. Look for unrelated rewrites, duplicated logic, generated files, configuration changes, and edits outside the authorised scope.
Follow the data. Where does input come from? Where is it sent or stored, and who can access it? Check whether logs or examples expose secrets or personal data.
Question new dependencies. Check that each package is needed, maintained, pinned appropriately, compatible with the project, and licensed for the intended use.
Trace the behaviour. Follow control flow, types, state transitions, concurrency, boundaries, error handling, and cleanup. Plausible names don’t tell you whether the code works.
Run and inspect the tests. Run the relevant existing tests and read the new ones. Add cases that could expose a flaw, and confirm that a regression test fails without the fix.
Review security. Check authentication, authorisation, injection boundaries, output encoding, secrets, unsafe deserialisation, dependency risk, and abuse cases relevant to the change.
Check how it will run. Consider migration, rollback, observability, performance, accessibility, and support. What happens when a dependency or model is unavailable?
Decide whether it should ship. Approve, request changes, split the work, or reject it. Record unresolved risks and the evidence behind your choice.

A pull request that needs more work

This fictional example shows how the review works. It doesn’t describe a real repository, incident, or measured outcome.

Proposed change: “Add an AI-generated summary to uploaded support transcripts.” The diff introduces a new model SDK, sends transcript text from the request handler, stores the returned summary, and adds one happy-path unit test.

Compiling and passing that test aren’t enough to approve this request. At least these questions still need answers:

Which transcript types are permitted, and may they contain personal or confidential information?
Has sending that content to the selected provider been approved, and what retention settings apply?
Who can request and read a summary? Does the new endpoint enforce the same authorisation as the transcript?
What happens when the model times out, refuses, truncates, or returns unsupported claims?
Must the summary cite transcript segments, and can a user correct or remove it?
Why is the new dependency needed, and has its licence and version policy been checked?
Do tests cover unauthorised access, oversized input, provider failure, deletion, and logging?
How will the feature be disabled or rolled back without losing the underlying transcript?

The review decision: request changes

Keep the useful interface work and separate out the provider integration. Before merging that part, agree which data it can handle, who can access it, how long it is retained, what happens on failure, and which cases to test. The feature may still be worth shipping, but these questions need answers before this version can be approved.

Keep the checklist with the pull request

Copy into the review

[ ] The task, acceptance criteria, and non-goals are clear.
[ ] Every changed file belongs to the requested scope.
[ ] Data sources, destinations, retention, and access are understood.
[ ] New dependencies, versions, and licences are justified.
[ ] Correctness was reasoned through beyond the happy path.
[ ] Relevant existing tests pass, and new tests can catch the failure.
[ ] Security and misuse cases relevant to this change were reviewed.
[ ] Failure, timeout, retry, logging, monitoring, and rollback behaviour are defined.
[ ] Accessibility and user recovery are considered where the interface changes.
[ ] The final decision and any accepted risk are recorded by a responsible reviewer.

The assistant’s explanation isn’t proof

An assistant can explain a diff or suggest tests; those answers need review too. Use deterministic tools, primary documentation, executable checks, and human review to assess the claims that determine whether code is safe to merge. Faster code generation doesn’t establish faster or safer delivery.