AI-Written PR Review Checklist (Interview Edition)

In a code review round, you get a pull request and a clock. When an AI wrote the PR, the code usually looks clean and the description sounds sure of itself, so a tidy-looking diff tells you little. This checklist gives you 15 things to check, each with a short example of what a problem looks like. It is part of our AI coding interview overview.

This page is the checklist. For the round itself (where it shows up, what graders want, a 20-minute routine and how to word a comment), read our guide to code review interview practice. The examples below are written for this page. They show the kind of issue to look for; they are not the answers to any problem in our library.

Run the checklist on real PRs. AICodingRound has pull requests written by an AI, inside working apps, where you comment on lines and approve or request changes. Start with Review the AI's retry PR (medium, about 10 min). The beta is free and places are limited: get a place.

How to use the checklist

You will not get through 15 checks line by line in a 30-minute round, and you should not try. Read the ticket and the PR description first. Then pick the checks that match what the diff touches: money, permissions, outside services, data writes. Run those carefully and skim the rest.

For every problem you find, try to prove it: a failing test, one request, or a line from the project's docs. One proven problem is worth more than three guesses.

Intent: before you read the code

1. The diff does what the ticket asked, no more and no less. Write one sentence: "This PR should..." Then check the diff against it. Example: the ticket asks to hide archived projects from the dashboard. The PR also removes them from the API that the billing export reads.

2. Every claim in the PR description is true. AI-written descriptions list features with confidence. Treat each one as a claim to check, not a fact. Example: the description says results are "cached for five minutes." The cache is set, but with no expiry, so stale data is served until a restart.

3. Every function, option and package it uses really exists. Models invent APIs. In a study of 576,000 code samples from 16 models, the average share of hallucinated packages was "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al.). Example: the PR passes a keyword option that only exists in a newer major version than the one your lockfile pins.

Security and data

4. Untrusted input never becomes part of a query, command or file path. Look for strings built with formatting or concatenation. OWASP notes that query parameters "represent data values, not table names, column names, or SQL keywords such as ASC and DESC" (OWASP), so those parts need an allow-list. Example: a sort query parameter appended straight after ORDER BY.

5. Every read and write is limited to what the caller may see. Check who is asking, which record they asked for, and whether that record belongs to them or to their team. Example: an export endpoint loads a project by ID and checks that the user is logged in, but never checks that the project is in the user's workspace.

6. Secrets and personal data stay out of logs, errors and responses. OWASP's logging guide lists session IDs, access tokens and passwords among the data to keep out of logs (OWASP). Example: a new debug line logs the full request headers, including Authorization.

7. Security claims match the code and the docs. "Secure," "safe" and "verified" in a PR description need a line of code behind them. Example: the description says passwords "are hashed." They are, with a fast general-purpose hash instead of a password-hashing function.

Failure paths and edge cases

8. Errors are handled, not hidden. A catch-all that hides a failure is worse than a crash, because nobody finds out. Example: a nightly import job catches every exception and marks itself "done," so a failed import looks like a successful one.

9. Anything retried is safe to repeat. The HTTP standard says a client "SHOULD NOT automatically retry a request with a non-idempotent method" unless it knows the request is idempotent or was never applied (RFC 9110). Example: a send-SMS call is retried after a timeout. The first attempt went through, so the customer gets two texts.

10. Edge inputs behave. Try empty, zero, one, very large, duplicate and malformed. Example: an upload handler works on a normal CSV, then crashes with a 500 on a file that has only a header row.

11. Time and money are handled with care. Daylight saving, time zones, rounding and currencies are where clean-looking code goes wrong. Example: a daily job scheduled for 2:30 a.m. local time runs twice, or not at all, on the nights the clocks change. Or a price computed in floating point comes out as 0.30000000000000004.

12. Two requests at the same moment do not break it. Look for read, then check, then write, with nothing stopping a second request in between. Example: two withdrawals arrive together. Both read the same balance, both pass the check, and the account goes negative.

13. The work grows with the request, not with the whole table. AI-written code often loads everything and filters in memory. Example: to show "3 unpaid invoices," the code loads every invoice the customer ever had and counts them in a loop.

Tests and fit with the codebase

14. The tests fail when the code is wrong. Google's review guide asks: "Will the tests actually fail when the code is broken?" (Google). When the same AI writes the code and the tests, the tests often confirm what the code does instead of what the ticket asked. Example: the test mocks the very function it claims to test, so it passes no matter what that function returns.

15. It follows the house rules. Read the README and any contract or docs folder before you approve. A change can be fine on its own and still break the project's rules. Example: every endpoint returns errors as JSON with a code field. The new one returns a bare 500 with a stack trace.

The one-page version

Print this, or keep it next to the editor while you practice.

Using AI while you review

If the round allows an AI assistant, use it to read faster, not to decide for you. Good asks: "Where else is this function called?", "What does this library version accept for this option?", "Write a test that sends two requests at once." Then check its answer in the code before you base a comment on it. An interviewer will often ask how you confirmed a finding, and "the AI said so" is a weak answer.

Practice the checklist on AICodingRound

These are pull requests written by an AI, inside working multi-file apps from our library. Each asks you to comment on lines, then approve or request changes. Run the checklist on them.

• Review the AI's profile-editing PR (easy, about 10 min)
• Review the AI's retry PR (medium, about 10 min)
• Review the AI's webhook-signature PR (medium, about 10 min)
• Review the AI's reminders PR (medium, about 30 min)
• Review the AI's percentage-refunds PR (medium, about 35 min)

The workspace is checked out on the PR branch, so you can run the tests and, in the larger apps, call the API to prove a finding. When you submit, your comments and decision are checked against the problems we know the PR has, a short debrief asks about your review, and the report gives a level per skill (Strong, Solid or Developing), including how you used AI. Your own Claude or Codex is there as a coach: it reads code and explains, but it does not write the review.

Start with the 10-minute drills, then take the checklist into the longer PRs. The beta is free and places are limited: get a place. For where review rounds fit in a wider loop, see our guide to the AI coding round.