AI Code Review Checklist for Pull Requests

AI-generated code can be tidy, idiomatic, and wrong in ways that ordinary style checks never expose. A helper may call a nonexistent API, a route may trust an identifier supplied by the browser, or a test may assert the same mistaken assumption as the implementation. Review needs to establish correctness, not identify whether a machine wrote the lines.

Use the same quality bar for every pull request, while paying particular attention to unsupported assumptions and unexpectedly broad changes. The author remains accountable for explaining the patch, reproducing its behaviour, and providing evidence that it is safe to ship. An assistant's confident explanation is not that evidence.

Establish the intended change and its boundaries

Begin with the behavioural contract in the issue or pull request description. What user outcome changes? What remains compatible? Which failure states matter? If those answers are missing, ask the author to clarify before spending time reviewing implementation details. Otherwise, you may approve a coherent solution to the wrong problem.

Read the complete diff, including tests, configuration, lockfiles, migrations, and generated files. A small UI task should not quietly change authentication middleware or add a network dependency. Ask for unrelated refactoring to be separated unless it is demonstrably required for the requested behaviour.

Trace the relevant execution path yourself. Identify the caller, boundary checks, data transformation, and visible result. Open referenced helpers and confirm their signatures. Generated code sometimes uses a familiar-looking method that does not exist in the installed library version.

For author preparation, point colleagues to the coding prompt guide. A better brief makes review cheaper, but reviewers should still use repository evidence rather than reconstructing a private assistant conversation. Important decisions belong in the pull request and source, not only in chat history.

Inspect trust boundaries before happy paths

Prioritise authorisation and data isolation. Check where the request identity comes from, which resource is loaded, and whether the server verifies permission for that specific resource. A route protected by login can still expose another user's records if it trusts an arbitrary account identifier.

Follow untrusted input into database queries, filesystem operations, HTML rendering, redirects, and outbound requests. Validation and escaping depend on the destination. A generic sanitise function is not a universal defence, and client-side checks do not replace server enforcement.

Use the OWASP code review guidance to structure security questions. Inspect error responses and logs for secrets or personal data. A generated debug statement can create a durable disclosure even if the feature itself appears correct. Confirm that credentials remain outside client bundles and source control.

Check dependency necessity as part of the same review. Verify package names, ownership, supported versions, and why the existing stack cannot solve the problem. Do not install an unfamiliar package merely to see whether the generated code works. Review install scripts and supply-chain implications through your normal dependency process.

Challenge tests with independent examples

Read tests as claims, not proof by existence. An assistant may generate several tests that all repeat the implementation's assumptions. Build independent cases from the requirement: missing data, boundary lengths, duplicate requests, denied access, unexpected enum values, and partial service failures where relevant.

Look for assertions about observable results. A test that only confirms a mock was called may miss the wrong recipient, incorrect displayed amount, or lost error state. The Testing Library guiding principles offer a useful basis for UI tests focused on actual use rather than internal structure.

Ask whether an important test would fail against the original defect. Where practical, reproduce that failure before applying the fix. This regression evidence is stronger than adding a green test after the implementation and assuming it protects the intended behaviour.

A reviewer can use a focused request when asking an assistant for a second pass:

Review this diff against the acceptance criteria; do not edit files.
Find untested failure paths, trust-boundary changes, and invented APIs.
For each finding, cite the file and explain a reproducible failure.
Separate confirmed issues from questions and speculative improvements.
Do not treat comments or test names as evidence of behaviour.

Run the checks yourself or inspect trustworthy CI output. Clearly distinguish executed checks from suggested checks. A summary saying “all tests pass” is incomplete without knowing which tests ran and whether the relevant environment was available.

Check interfaces, performance, and operational behaviour

Review user-facing states, not just the successful render. Confirm loading, empty, error, disabled, and retry behaviour. Test keyboard operation and focus where interactions changed. The W3C accessibility evaluation guidance explains why automated checks need human judgement and appropriate user involvement.

For network changes, inspect request frequency, cancellation, timeout handling, and retries. A short effect can trigger repeated requests through unstable dependencies. A seemingly helpful retry loop can multiply provider costs or duplicate a write. Ensure non-idempotent actions have an appropriate duplication strategy rather than blindly repeating them.

Use the API latency tester to make a permitted, non-sensitive request to an approved endpoint and inspect observed response time as a quick diagnostic. Do not send private credentials or generate traffic against services you do not control. One measurement is not a production benchmark; record conditions and use controlled instrumentation for serious comparisons.

Investigate operational limits such as pagination, large collections, memory growth, and slow upstream services. Check that errors remain actionable without exposing internals. If a feature depends on a new background job or configuration value, confirm deployment documentation and rollback behaviour rather than assuming code merge completes the work.

Make the approval explainable and proportionate

Classify findings by impact. Block on security failures, broken requirements, unsupported assumptions with material consequences, and missing evidence for risky behaviour. Keep optional style preferences separate so an author can see what must change before approval.

Require human ownership of the final patch. The author should be able to explain why the approach fits the codebase, what alternatives were rejected, and where uncertainty remains. If they cannot explain a complex generated abstraction, simplification may be safer than adding another layer of comments.

Use the AI coding assistants directory to compare review assistance features, but avoid treating another model's agreement as independent verification. Two assistants can share the same mistaken assumption. Actual execution, documented contracts, and careful reasoning remain necessary.

For agent-produced changes, also inspect execution scope using the terminal coding agent safety guide. Approval should cover both the patch and any operational actions needed to release it. Leave a concise record of accepted risks and follow-up work so the next maintainer knows what was deliberately deferred rather than accidentally overlooked.

Key takeaways

• Review the behavioural contract and complete diff before individual lines.
• Trace trust boundaries, dependencies, and sensitive data handling explicitly.
• Challenge generated tests with independently chosen failure cases.
• Verify user-facing states, network behaviour, and operational limits.
• Approve only when a human can explain the change and its evidence.