A pull request comes in from a teammate using an AI coding assistant. The formatting is clean. Variable names are sensible. The diff is smaller than you expected for the feature it implements. Tests pass. You skim it, it looks like exactly the kind of code you'd expect from a careful engineer, and you approve it in under two minutes.
Three weeks later that code is the reason a background job silently drops records under a specific load pattern nobody tested for. Nothing about the review was lazy by normal standards. It just wasn't built for what actually goes wrong in AI-generated code, which fails differently than code a person writes from scratch, and needs a different kind of scrutiny to catch it.
Why AI-Generated Code Reads as More Trustworthy Than It Is
Human-written code carries visible signals of how carefully it was made. Rushed code often looks rushed: inconsistent naming, missing error handling, comments like "TODO fix this later." A reviewer's eye is trained on those signals, consciously or not, to gauge how much scrutiny a given piece of code deserves.
AI-generated code breaks that calibration. It's consistently well-formatted regardless of how well-reasoned the underlying logic actually is. A model can generate a confidently wrong solution with the exact same clean structure, sensible naming, and tidy comments as a confidently right one. The surface signals reviewers normally use to triage where to look closely stop correlating with where the actual risk is.
Photo by Yan Krukau on Pexels
The Failure Modes That Are Actually Different Here
Reviewing AI-generated code for the same things you'd review human code for (style, obvious bugs, missing tests) misses the failure modes that are specific to how these tools actually get things wrong.
Plausible logic that's subtly wrong. A model asked to implement a rate limiter, a retry strategy, or a deduplication routine will produce code that looks like a textbook implementation, because it's trained on a huge volume of code that mostly looks that way. The bug is often in an edge case the textbook pattern doesn't cover for your specific situation: an off-by-one in a boundary condition, a race condition in concurrent access, an assumption about ordering that doesn't hold for your actual data.
Confidently fabricated APIs and library behavior. Models sometimes generate calls to methods, parameters, or configuration options that don't exist, or that existed in an older version of a library, presented with the same confidence as correct calls. This is a well-documented failure mode of large language models, sometimes called hallucination, and it's genuinely hard to catch by reading alone if the fabricated API looks structurally reasonable and the surrounding code compiles or type-checks.
Missing the requirement it wasn't explicitly told about. An AI assistant solves the problem it was given, precisely. It rarely infers unstated context a human teammate would pick up from being embedded in the team, like "this table has a unique constraint we added after an incident" or "we don't allow synchronous calls to that service because it rate-limits aggressively." If that context isn't in the prompt or the codebase's visible structure, it's not in the output.
Test coverage that confirms the code does what it does, not what it should. A model asked to write tests for its own code tends to write tests that pass against its own implementation, which is a weaker signal than tests written from the actual requirement. Green tests on AI-generated code confirm internal consistency, not correctness against the real spec.
A Review Checklist Tuned for These Failure Modes
Given those failure modes, a few review habits catch more than a standard style-and-logic pass:
- Trace every external API call against real documentation, not against what looks plausible. If the code calls a library method you don't personally use often, open the actual docs and confirm the method, its parameters, and its return shape exist as written.
- Ask "what wasn't this told?" before approving. What context about your system, your data, or your past incidents would a new hire need to know to write this correctly, and is there evidence the code accounts for it?
- Write or request one test from the actual requirement, independent of the AI-generated tests. If a human-written test targeting the real spec passes against AI-generated code, that's a much stronger signal than the AI's own tests passing.
- Read the diff slower than the clean formatting invites you to. The polish is exactly why the instinct to skim is stronger here than with obviously messy code. Deliberately resist that instinct on anything touching data integrity, auth, or money.
- Check for silent scope narrowing. AI-generated implementations sometimes handle the common case cleanly and quietly drop or ignore an edge case rather than erroring on it, which is worse than a visible failure because nothing alerts anyone that a case was skipped.
Where to Slow Down the Most
Not every AI-generated change carries equal risk, and treating a one-line copy change with the same scrutiny as a database migration wastes review effort where it matters least. The highest-risk categories consistently are: database schema migrations, authentication and authorization logic, anything handling money or billing, and code that runs unsupervised in a background job where a subtle bug can run for weeks before anyone notices the output looks wrong. OWASP's guidance on secure code review practices, written well before AI coding assistants existed, still holds up well as a baseline for which categories of change deserve the deepest scrutiny, since the risk categories haven't changed, only how the code gets produced.
"The teams that get burned by AI-generated code aren't the ones using it carelessly everywhere. They're the ones who let the tool's speed convince them migrations and auth code deserve the same five-minute review as a CSS tweak. Match your review depth to the blast radius of what's changing, not to how clean the diff looks." - Dennis Traina, founder of 137Foundry
Tooling That Actually Helps, and Tooling That Doesn't
A second AI model reviewing the first model's output catches some things, mainly obvious logic errors and missing edge cases that are visible from the code alone. It's meaningfully weaker at catching the "missing unstated context" failure mode, since a second model has the same blind spot to context that isn't written down anywhere it can see. Treat AI-assisted review as one more layer, not a substitute for a human who knows the system's history.
Static analysis and type checking remain just as valuable as they were before AI-generated code, and arguably more so, since they catch a class of error (type mismatches, unreachable code, unused variables) mechanically and consistently regardless of how convincingly the surrounding code reads. Google's published engineering practices for code review predate widespread AI code generation but describe a standard worth adapting: review for correctness against the actual requirement first, and treat clean style as a separate, lower-priority signal that doesn't substitute for it. NIST's AI risk management framework is also a useful reference for organizations formalizing how much scrutiny AI-assisted work requires at a policy level, beyond individual reviewer habits.
PR Size Changes How Much This Risk Actually Compounds
A large AI-generated PR compounds every failure mode above, simply because there's more surface area for a subtly wrong pattern or a fabricated API call to hide in, and reviewer attention degrades faster across a long diff than a short one regardless of how disciplined the reviewer intends to be. Requesting AI-generated changes in smaller, single-purpose PRs isn't just a general best practice carried over from human-written code, it's a more important discipline here specifically, because it keeps each individual diff small enough that the "read the diff slower than the polish invites you to" habit is actually achievable in practice rather than a nice idea that erodes under a 600-line change.
This also makes the "what wasn't this told" question easier to answer well. A focused, single-purpose change has a narrower set of unstated context that could realistically be missing, while a sprawling multi-concern PR makes it much harder for a reviewer to reason about what context each part of the change actually needed.
Setting Team Norms, Not Just Individual Habits
Individual reviewer discipline erodes under deadline pressure unless it's backed by a team norm everyone's accountable to. Two practices make this durable: requiring the PR description to state what was explicitly told to the AI assistant and what wasn't, so a reviewer can quickly spot unstated context gaps, and treating "AI-generated" as a visible tag on a PR rather than something reviewers have to infer, so review depth is a team decision rather than each individual guessing whether the extra scrutiny is warranted.
Neither of these slows a team down meaningfully. Both make the review process actually match the risk profile of what's being reviewed, instead of drifting toward the two-minute rubber stamp that clean-looking code invites by default.
Bringing It Together
AI coding assistants haven't changed what good code review is for. They've changed which signals a reviewer can trust while doing it. Clean formatting and passing tests used to correlate reasonably well with careful work; with AI-generated code, that correlation weakens, and the review process needs to compensate deliberately rather than assume the old heuristics still hold.
The practical shift is small: check external API calls against real documentation instead of trusting how plausible they look, actively ask what context the assistant wasn't given, write at least one test independent of the AI's own tests, and reserve genuinely careful review for the categories of change where a subtle miss actually hurts. None of it requires slowing every PR down. It requires knowing which ones deserve the two minutes back.
If your team is scaling how much AI-assisted code ships and wants a second set of eyes on review process or a security-focused audit of what's already shipped, 137Foundry's AI automation service works through exactly this kind of engineering process review. You can see the full range of services we offer or read more about how we work. Start from the 137Foundry homepage for the rest of our writing on building with AI tools responsibly.
