AI-written code fails differently. It fails confidently, it passes a casual review, and it fails at a rate the quality process you built for slower, hand-written code was never designed to catch. This guide lays out that defect profile — and the QE practices that hold up when a model wrote the first draft.
What most teams still rely on: functional tests and human review tuned for hand-written code — so polished, plausible generated code sails through while insecure, duplicated, "almost right" defects slip underneath a green pipeline.
What the quality shift looks like: rebuild QE around the new defect profile — automated security gates that assume the worst, tests that check properties not just paths, maintainability metrics you actually watch, and review that refuses to mistake clean-looking for correct.
A model writes code that looks finished — sensible names, clean structure, helpful comments — with the defect buried inside something that pattern-matches to "good." The polish lowers a reviewer's scrutiny exactly when volume raises the need for it.
The dangerous bugs — injection, weak crypto, missing input handling, XSS — pass functional tests because the feature still works. They only bite later, in production, under an attacker's attention.
Because generation is cheap, the path of least resistance is to generate similar code again rather than reuse. Duplication surges, refactoring collapses, and every clone becomes a place a future fix can be missed.
When 45% of generated code carries an OWASP-class flaw, you can't rely on a human to spot it. Run SAST, dependency, and secret scanning on every change and block merge on serious findings.
Move beyond "does the happy path work" to tests that assert security properties, handle malformed input, and probe edge cases — property-based and fuzz testing where the risk justifies it.
Track duplication, churn, and complexity as first-class quality signals and treat a spike as a defect. What you don't measure, you can't manage.
Cap change size so review stays honest, and review generated code the way you'd review a contribution from an unknown outsider: assume good intent, verify everything.
Generated code isn't lower quality because models are bad. It's lower quality because it's produced faster than the quality process around it was built to handle, and it fails in ways old QA wasn't watching for. Rebuild quality around the new defect profile and you keep the speed — and find your defects in review, not in production.
The largest test to date found 45% of generated code introduced an OWASP Top 10 flaw, with Java failing 72% of the time and XSS undefended in 86% of relevant cases. A Stanford study found developers using AI wrote less secure code while feeling more confident about it. The risk is well-evidenced.
Functional tests confirm the feature works, which is exactly what insecure and unmaintainable code can also do. You need security scanning and maintainability metrics on top.
VPs of Engineering, Heads of Quality, and engineering directors whose teams now ship a large share of AI-assisted code.
Veracode found security didn't improve with newer or larger models, so you can't wait it out. Build the quality process assuming the defects are here to stay.
Turn on automated security scanning (SAST, dependency, secret detection) as a merge gate. It directly targets the defect class generated code is worst at.
