I've merged plenty of AI-generated code that was genuinely fine.
I've also caught myself almost merging code that looked fine and wasn't, because it read like something a competent person wrote and my brain filled in the rest.
Over the last year I've settled into a rough set of questions I run through before approving anything I didn't write line by line myself, generated or not.
Here they are, in the order I actually ask them.
1.
What problem is this code actually solving?
It's easy to review whether code works and skip whether it solves the right thing.
AI tends to answer the literal prompt, not the intent behind it.
If "active" was supposed to mean "logged in within 30 days" and not a boolean flag that's rarely updated, this passes every test and still solves the wrong problem.
Reviewer tip: Read the original ticket or request before reading the diff.
Check the code against the intent, not just the literal ask.
2.
Do I actually understand the implementation?
Not "does it look reasonable," actually understand it, line by line, well enough to explain it to someone else.
Reviewer tip: Try to explain the function out loud in one sentence per major step.
If you get stuck anywhere, that's the part you haven't actually reviewed yet, just skimmed.
3.
What assumptions is it making?
Every implementation bakes in assumptions about the shape of the data, the order things happen in, or what "normal" looks like.
This assumes is sorted chronologically and never empty.
Neither assumption is stated anywhere.
Reviewer tip: Ask "what does this assume about its inputs that isn't checked anywhere?" Write the answer down, literally, in the PR comment if it matters.
4.
What happens with bad input?
Bad input isn't an edge case, it's a certainty over a long enough timeline.
Pass it and it works.
Pass it , , or and you get a crash or a nonsensical value with no complaint.
Reviewer tip: Pick three inputs that would never appear in a demo but could plausibly appear in production: empty, wrong type, absurdly large.
Trace through what actually happens.
5.
What happens when an external service fails?
Generated code frequently assumes the network, database, or third-party API always responds successfully.
No timeout, no handling for a non-200 response, no fallback.
If that API is slow or down, this fails in whatever way and happen to fail, which may not be a clear error at all.
Reviewer tip: For every external call, ask "what does the caller see if this times out or returns an error status?" If the answer is "an unhandled exception," that's worth a comment.
6.
Are permissions actually enforced, not just checked?
There's a difference between "there's an auth check" and "it's the right auth check." This confirms someone is logged in.
It never confirms they own or have access to this document.
Reviewer tip: For any endpoint touching a specific resource, ask "does this check the resource belongs to the requester, or just that the requester is logged in?"
7.
Is sensitive data exposed anywhere?
Look at what actually goes into logs, error responses, and API payloads, not just what the happy path returns.
Fine in local development.
In production this can leak file paths, query fragments, or internal structure to whoever triggers the error.
Reviewer tip: Grep the diff for , , and catch blocks.
Check what they actually expose.
8.
Is this more complex than the problem needs?
Generated code sometimes over-engineers a simple problem with extra configuration, unnecessary abstraction layers, or generic solutions to specific problems.
Reviewer tip: Ask "could this be half the length and still be correct?" If yes, that's worth pushing back on, complexity has an ongoing cost even when it's not technically wrong.
9.
Are the tests actually meaningful?
Generated tests often confirm the code does what it does, not that it does what it should.
This confirms the arithmetic.
It says nothing about a discount over 100%, a negative price, or invalid input.
Reviewer tip: For each test, ask "what wrong implementation would still pass this?" If you can think of one easily, the test isn't pinning down enough.
10.
Does it fit existing conventions?
Locally correct code can still be a long-term problem if it introduces a new pattern the codebase doesn't already use, a different error-handling style, a new HTTP client, a different logging approach.
Reviewer tip: Before approving, check one comparable file elsewhere in the codebase.
If the patterns don't match, ask whether that's intentional.
11.
What happens under unusual load or concurrency?
Code that's correct for one request at a time can break under concurrent access, especially anything involving shared state or caching.
Fine single-threaded.
Under concurrent requests this can lose increments, since read-then-write isn't atomic.
Reviewer tip: For anything touching shared state, ask "what happens if this runs twice at the exact same moment?"
12.
Will the next developer understand this without me?
The final check.
If someone opens this file in eight months with zero memory of this PR, can they figure out what it does and why from the code and comments alone?
Reviewer tip: Read the diff as a stranger would, not as someone who already knows what it's supposed to do.
If it doesn't hold up, add a comment now while the reasoning is still fresh.
Copy-paste checklist for your PR template None of this is exotic review practice.
It's the same discipline good engineers apply to any code they didn't personally trace through, generated or not.
The only thing that's changed is how often that situation comes up, and how easy it is to skip these questions when the first draft already looks like someone competent wrote it.