When a pull request was mostly written by an AI assistant, review it in this order: new dependencies, authorization and input handling, secrets and config, error paths, tests, and anything the change touched that the description does not mention. The code usually reads well, which is exactly why it needs a deliberate pass.
Why the order matters
AI-written code tends to look tidy and consistent. That makes reviewers skim. A user study from Stanford researchers found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Confidence and correctness drifted apart.
So the checklist below pushes you toward the places where a plausible looking diff hides real problems.
1. Dependencies first
Open the manifest and lockfile changes before the code. Every new package needs a reason, a legitimate registry entry and a known publisher. Ask whether the standard library or an existing dependency already covers the need. See how to check an AI-suggested package.
2. Authorization, not just authentication
Find each new endpoint, handler or query. Does it check that the caller may access this specific record, or only that the caller is logged in? Assistants often write the happy path and leave object level checks out.
3. Input and output handling
Trace user input to every sink: SQL, shell commands, file paths, templates, HTML output, deserialization. Look for string concatenation where a parameterized call belongs.
4. Secrets and configuration
Search the diff for keys, tokens, passwords and connection strings, including in test files and example config. CWE-798 describes hard-coded credentials and notes that one discovered credential can open every installation that shares it.
5. Error paths and logging
Check what happens on failure. Does an exception return internal detail to the user? Does a log line include a token or personal data?
6. Tests that could fail
Read the tests as skeptically as the code. A test generated alongside the code often asserts whatever the code does. Ask for at least one test that tries to break the rule, such as a request from the wrong user.
7. Scope creep
Compare the diff to the description. Assistants sometimes reformat files, change unrelated settings or delete a check that "got in the way". Unexpected files in the diff are a finding.
Keep it proportionate
Do not apply this to every one line change. Apply it where the change touches authentication, money, data access, or anything that runs with elevated permissions.
Time budget
A full pass should not take an hour. For a change of a few hundred lines, spend the first five minutes on dependencies and new routes, ten on input and secrets, and the rest on tests and scope. If the diff is too large to review in that time, send it back and ask for smaller pieces. Large AI-generated pull requests are the easiest place for a flaw to hide, because nobody can hold the whole change in mind at once.
Quick check
Should AI-written pull requests have a different approval rule?
Many teams keep one rule and add a checklist. The author remains responsible for the change, whoever or whatever typed it, and the reviewer needs to be able to explain what the code does.
Sources
- Do Users Write More Insecure Code with AI Assistants? (arXiv)
- CWE-798: Use of Hard-coded Credentials (MITRE)
Last reviewed: 19 October 2026.
