There's a quiet double standard forming in a lot of engineering teams right now. A pull request written by a human gets scrutinized line by line. A pull request drafted by an AI assistant, cleaned up a bit, gets a faster skim and a merge - because it "looks" fine, and reviewing AI output carefully feels redundant when the whole point was to save time.
That double standard is going to cause a wave of production incidents that nobody sees coming until they're debugging them at 2am.
AI-Generated Code Looks More Confident Than It Is
Human-written code that's wrong usually looks wrong - awkward variable names, inconsistent patterns, a comment that says "TODO: fix this later." AI-generated code doesn't have those tells. It's syntactically clean, follows conventional patterns, and reads like something a competent engineer wrote carefully. That confidence is exactly what makes it dangerous to under-review: the code that most needs a skeptical second look is the code that looks the least like it needs one.
A model asked to write an auth check will usually produce something that compiles, runs, and handles the obvious case correctly. Whether it handles the case where a user ID is spoofed, where a token has expired mid-request, or where two requests race against each other - that's a different question entirely, and it's not one syntax cleanliness answers.
The Specific Failure Patterns to Watch For
A few categories show up disproportionately often in AI-drafted code, and they're worth treating as a standing checklist during review:
Happy-Path-Only Logic
Models are trained on enormous volumes of code that mostly demonstrates the common case. Ask for a payment flow and you'll often get the successful-charge path handled well, with partial refunds, failed retries, and webhook replay scenarios left as an afterthought - or missing entirely.
Hardcoded Values That Should Be Configuration
API keys, magic numbers, environment-specific URLs - these show up embedded directly in generated code more often than in code written by someone who's been burned by a hardcoded staging URL reaching production before.
Auth Checks That Cover the Obvious Case Only
A generated endpoint might correctly check that a user is logged in, while missing that the logged-in user isn't authorized to access this specific resource - a subtler and more common vulnerability class than an outright missing login check.
Plausible-Sounding but Wrong Library Usage
A model can generate code that calls a real library with a method that looks correct, uses parameters that exist, and produces no error - while still misusing the API in a way that silently returns wrong results instead of failing loudly.
Review Discipline Has to Match the Risk, Not the Source
The instinct to review AI output more lightly usually comes from a reasonable-sounding assumption: the model didn't get tired, didn't cut corners under deadline pressure, so the usual human failure modes don't apply. That's true - and irrelevant, because AI output has its own failure modes that are just as real, just less familiar to reviewers who haven't calibrated for them yet.
The teams handling this well aren't reviewing AI-drafted code less than human code. If anything, they're reviewing it with a specific, different checklist - one aimed at the failure patterns above, rather than the failure patterns a human reviewer instinctively looks for after years of catching human mistakes.
What a Reasonable Process Actually Looks Like
A few practices consistently show up in teams that get real velocity from AI-assisted development without a corresponding rise in incidents:
- Every AI-drafted PR still requires human sign-off - no exceptions for "it's just boilerplate," because boilerplate is exactly where hardcoded values and missing edge cases hide.
- A specific review checklist for AI output - auth boundaries, error handling, edge cases, and hardcoded config get explicit attention, not just a general "does this look right" pass.
- AI handles the repetitive first draft; a senior engineer owns the architecture decisions - the model accelerates typing, not judgment.
- Security-sensitive code gets the same scrutiny regardless of who or what wrote the first draft - auth, payments, and data access paths aren't where anyone should be moving faster just because a model did the initial typing.
This isn't a rejection of AI-assisted development - it's an acknowledgment that speed and review rigor are separate variables, and letting one erode the other is how "AI helped us ship faster" quietly turns into "AI helped us ship a security incident faster."
The Takeaway
The productivity gains from AI-assisted coding are real, but they come from AI handling the repetitive parts of writing code - not from skipping the parts of engineering discipline that exist specifically to catch mistakes before they reach production. Teams building around a hybrid human-plus-AI development model, where a senior engineer reviews and owns every merge regardless of who drafted it, tend to get the speed benefit without inheriting the risk that comes from treating AI output as self-certifying.
Anchor text used above: "a hybrid human-plus-AI development model" → links to https://www.zoraz.net/
Top comments (0)