AI-Generated Code and QA: Why Code Review Needs to Change

OKQA. AI-Generated Code and QA: Why Code Review Needs to Change

The risk isn't bad code. It's fast code.

It's easy to frame that "AI writes buggy code," but that framing gets you the wrong conversation. 

The tools are, honestly, pretty good now. They follow conventions, they handle boilerplate cleanly, and on a narrow, well-specified task they'll often beat a tired engineer at 6 pm on a Friday.

The actual problem is that AI can produce working, plausible-looking code faster than most review processes were ever built to check it.

Code review, test coverage, QA gates....all of that was designed around a world where output was capped by how fast a person could type and think. That cap is gone. What used to be the bottleneck (writing the code) isn't the bottleneck anymore. Verifying it is. Most teams' processes haven't caught up to that shift yet, and that gap is exactly where things go wrong.

A few ways we've seen it play out:

It looks right, which is not the same as being right. AI-generated code is optimized to look correct. It compiles; it's syntactically clean, and it mimics the shape of good code from its training data. What it doesn't do reliably is understand your specific business logic or the edge case your actual users will hit. A discount calculation that's off by one condition. An access check that works only for the happy path.

These don't fail a casual read-through, because they're not typos. They're logic errors wearing a clean diff.

The AI writes the code, then writes the tests for the code. This one shows up constantly. Same model, same session, same assumptions baked into both. The tests pass, the PR turns green, everyone moves on. But a test suite built from the same assumptions as the code it's testing will confirm those assumptions, not challenge them.

If the model misread a requirement, its tests will faithfully validate the misreading. Passing tests start to feel like proof of correctness when they're really just proof the code agrees with itself.

New failure modes that didn't used to exist. A few we keep running into:

• Hallucinated dependencies. Models occasionally invent plausible-sounding package names. If someone registers that name on a public registry before you notice, you've got a real supply-chain problem, not a hypothetical one.

  
  

• Inconsistent error handling. Code stitched together across a dozen prompts often handles failures differently function to function, because no single person (or model) was holding the whole system in their head at once.

  
  

• Logic that doesn't fit your data. AI writes what's statistically common, not what's true of your production data's actual shape, scale.

  
  

• Security gaps that look clean. Veracode's 2025 GenAI Code Security Report tested output from over 100 models across Java, Python, JavaScript, and C#, and found that roughly 45% of the code samples introduced at least one OWASP-category vulnerability. What stood out to us more than the headline number was that newer, larger models didn't meaningfully improve on it; the report found security pass rates stayed roughly flat across model generations, even as the code got cleaner-looking and easier to read. Syntax quality got better a lot faster than security did.

None of this shows up in a five-minute look at a diff. It shows up in production, usually at a bad time.

This is where QA gets more important, not less

Some teams' instinct is to treat AI-written code as pre-tested and scale back human review to go faster. We'd push back on that. As AI absorbs more of the actual typing, the highest-leverage human work becomes almost entirely judgment: does this do what we actually meant, not just what we literally asked for.

That's a QA instinct, not a typing one. It shows up in three ways:

1. Reviewing intent instead of just output: "does this work" and "is this what we meant" are different questions, and only the second one requires actually understanding the product, not just the syntax.

2. Testing adversarially: throwing inputs at the code that a rushed engineer wouldn't think of, and that a model generating "reasonable" output almost certainly didn't consider either.

3. The harder one to systematize: asking questions the model has no way to know to ask. It doesn't know about your compliance requirements, or that time two years ago a bad migration took down billing for six hours, and everyone swore they'd never let a schema change ship without a second set of eyes again. That kind of institutional scar tissue isn't in anyone's training data. It lives in the team, or it doesn't live anywhere.

What's actually working

We don't think the answer is slowing down. We think it's moving the checkpoints:

1. Flag AI-generated code in the PR itself, so reviewers know where to spend their attention instead of treating every diff identically.

2. Write edge-case and integration tests from a separate process than the one that generated the feature: doesn't have to be a human from scratch. Just something that isn't grading its own homework.

3. Add one deliberate pause before anything AI-heavy ships. Someone asking, plainly, "what would have to be true for this to be wrong?"

4. Track review depth, not just review completion. A rubber-stamped approval on a 600-line AI-generated PR isn't the same signal it was on a 60-line human-written one, even if the checkbox looks identical.

None of this requires going back to pre-AI speed. It requires being honest about where the speed is actually helping you and where it's quietly working against you. Nobody's had time to figure it out; the tools changed faster than anyone's process could reasonably keep pace with.

To sum up

As AI changes how software gets written, it also changes what good testing looks like. The teams adapting fastest aren't abandoning QA. They're using it differently, focusing less on verifying that code runs and more on verifying that it does the right thing under real-world conditions.

If your team's testing process was designed for a slower, human-only development workflow, it may be worth taking another look at whether it still matches the way you ship software today. Sometimes the biggest gaps aren't in the code itself. They're in the assumptions your process is still making.