Developer surveys keep repeating the same finding: most developers use AI tools, few fully trust the output, and the top frustration is code that is almost right. Almost-right code passes a quick glance and fails in production.

AI-generated pull requests need review that targets the specific ways these tools go wrong.

1. Does it solve the actual problem?

Read the issue first, then the diff. AI tools are good at producing plausible code for a slightly different problem.

  • Does the change handle the case described, including the edge case that prompted it?
  • Did it fix the symptom (a null check) instead of the cause (why the value is null)?

2. Were the tests changed to pass?

A classic failure: the implementation is wrong, so the test expectation was edited to match.

  • Review test changes as carefully as code changes.
  • Be suspicious of loosened assertions, removed cases and new skip markers.

3. Hidden error swallowing

Watch for:

typescript
try {
  await syncAccount(id);
} catch {
  // ignore
}

Broad catches, default fallbacks and optional chaining everywhere can make errors disappear instead of fixing them.

4. Invented APIs and outdated patterns

Models sometimes call functions or options that do not exist, or use APIs deprecated several versions ago.

  • Check unfamiliar methods against the documentation for the version you use.
  • Make sure the type checker and build actually ran in CI.

5. Security basics

Studies of AI-generated code have repeatedly found common vulnerabilities, including injection flaws, missing authorisation checks and leaked secrets.

  • Is user input validated and parameterised in queries?
  • Does every new endpoint check who is calling and what they may access?
  • Any hard-coded keys, tokens or URLs with credentials?
  • New dependencies: are they real, maintained and actually needed? Watch for look-alike package names.

6. Scope creep

AI tools like to "improve" nearby code. Unrelated refactors make review harder and hide risk. Ask for them in a separate PR.

7. Would you be able to maintain it?

  • Is the code consistent with the project's existing patterns?
  • Are names clear and is the logic simpler than it needs to be, not cleverer?
  • If the author cannot explain a section, it should not merge.

Make the checklist automatic

Put the mechanical parts in CI: type checking, linting, secret scanning, dependency review and tests. Save human attention for logic, security and design.

Key takeaways

  • Check the change solves the real problem, not a nearby one.
  • Review test edits and error handling with suspicion.
  • Verify APIs, dependencies and security basics.
  • Keep PRs focused and automate the mechanical checks.