Reviewing AI-generated code uses the same principles as reviewing any code, but certain failure modes appear more often and require deliberate attention. Confident, plausible-looking errors are more common; the reviewer's job is to slow down where human reviewers instinctively speed up.
Why AI-generated code feels easier to approve
AI-generated code is usually well-formatted, consistently named and accompanied by inline comments. That surface quality can lower a reviewer's guard. The code reads as though someone competent wrote it, which creates pressure to approve quickly. That pressure is the first thing to resist.
The underlying problem is that a language model optimises for plausibility, not correctness. It has no stake in the outcome. It cannot run the code before suggesting it, and it does not know what changed in your codebase last Tuesday.
What changes in the review
Assume less about intent. When a colleague writes a function, you can ask them why they made a particular choice. AI-generated code has no author to interrogate. If the intent is not clear from the code and its context, that is a gap to fill before approving, not after.
Check the seams. AI tools work on a context window. They see what was passed to them and nothing else. Errors cluster at the boundaries: where the generated code meets the rest of the system, where types are assumed rather than imported, where an API call matches the model's training data rather than the version you are actually running. See what is a context window for more on this limitation.
Treat tests with particular scepticism. Models generate tests that pass against the code they just wrote. That is not the same as tests that would catch a regression. Check whether the tests exercise the behaviour you care about, or whether they simply confirm that the function returns something.
Watch for hallucinated dependencies. Models sometimes reference libraries, methods or configuration keys that do not exist, or that exist in a different version than you are using. A quick check of imports and dependency versions is cheap. Discovering the problem in production is not.
Read error handling carefully. AI-generated error handling tends to be generic. Silent catches, bare except blocks, errors swallowed into a log line nobody monitors. These pass cursory review because they look like error handling. Read each one and ask what actually happens when this path is taken.
What does not change
The standard review checklist still applies: correctness, security, performance, readability, test coverage, fit with the existing architecture. AI generation does not make these considerations less relevant. It changes where the errors tend to hide, not whether they exist.
Security review in particular should not be abbreviated. Prompt injection is one category of risk specific to AI-assisted systems, but the broader set of concerns, injection, insecure defaults, improper access control, applies to AI-generated code as much as to any other.
Practical habits
- Read the diff as code, not as a summary. Resist the urge to skim because it looks clean.
- If a block is long, break the review into passes: one for logic, one for error handling, one for tests.
- When something looks cleverer than it needs to be, that is worth a second look. Models sometimes produce overcomplicated solutions.
- Record where AI-generated code caused problems. Patterns emerge quickly and inform what to check next time.
For a broader view of how code review practices are shifting, see what changed about code review.
What we test for
Reviewing AI-generated code is one of the skills we assess directly during vetting. In the AI-native assessment, AI output verification is scored explicitly: can the engineer catch hallucinated APIs, subtly wrong logic, or security gaps in generated code before it ships, rather than trusting it because it compiles? Judgement by risk is scored across both assessments, because agents produce a copy change and a payment migration at the same speed and with the same confidence. Full details of how both assessments run are at how we vet.
Short answers
Is reviewing AI-generated code fundamentally different from reviewing human-written code?
The principles are the same, but the failure modes shift. AI-generated code tends to look cleaner than it is, errors concentrate at context boundaries, and tests often only confirm what the model just wrote rather than catching future regressions.
Should AI-generated code be labelled as such in a pull request?
Many teams find it useful, because it prompts reviewers to apply the specific checks that matter. It also helps track where problems originate. There is no universal standard yet, but transparency tends to improve review quality.
How do you review AI-generated tests effectively?
Check whether each test exercises behaviour the codebase actually needs to protect, not just whether it passes. Models write tests that confirm their own output. Ask what regression the test would catch, not just whether it currently passes.
