Testing AI-Generated Code: What Engineering Leaders Need to Know

Six months ago, “How much of our codebase is AI-generated?” was a curiosity question at an engineering all-hands meeting. In 2026, it’s a question the board asks. Google CEO Sundar Pichai told investors in April 2026 that 75% of new code at the company is now AI-generated and approved by engineers, up from roughly 25% in 2024 and 50% in late 2025. 

Sonar’s 2026 State of Code Developer Survey puts the industry-wide average at 42% today, with developers expecting that to reach 65% by 2027. Whatever the exact number is at your company, the direction is the same: AI is no longer just assisting your engineering team. In a growing number of organizations, it’s authoring most of the work.

That shift solved a real problem. Feature velocity that used to take a sprint now takes an afternoon. But it created a second problem that most engineering organizations haven’t caught up to yet: nobody scaled the checking process to match the writing process. Code generation got dramatically faster. Code review, testing, and validation mostly didn’t.

The numbers behind the confidence gap

The data on what’s actually shipping in that AI-generated code is not reassuring, and it’s worth distinguishing between large studies run by security vendors and smaller independent ones. Both tell a consistent story, even though the exact percentages differ across methodologies.

None of this means AI coding tools are broken. It means the code they produce needs the same scrutiny as code from a new junior engineer, at a volume no single reviewer can keep up with manually, and with a duplication and churn pattern that makes technical debt compound faster than teams are used to.

Why standard QA doesn’t catch this

Most engineering teams are validating AI-generated code in one of two ways, and both have a structural blind spot.

The first is business as usual. Human-written tests review AI-written code. This breaks down purely on throughput. When code generation happens at machine speed and test authoring still happens at human speed, the gap between what’s shipped and what’s actually verified grows every sprint.

The second is having the same AI model write both the code and its own tests. This feels efficient, but it inherits the exact blind spots that produced the defect in the first place. A model that misunderstands an edge case, an authorization boundary, or a concurrency issue will write a passing test for its own flawed logic, because it’s checking its work against its own assumptions rather than against the actual requirement.

Defects in AI-generated code don’t distribute randomly either. They cluster in a predictable set of places: error handling, edge cases, concurrent access, and security boundaries, exactly the categories that require judgment the training data doesn’t reliably encode. 

Veracode’s own data backs this up. Cross-site scripting and log injection flaws fail at rates between 85% and 88% of the time, while a more mechanical task like SQL parameterization passes about 83% of the time (Veracode 2026 GenAI Code Security Report). AI models are good at patterns they’ve seen thousands of times and weak at the judgment calls that separate code that runs from code that’s actually safe.

Example when nobody was checking the agent’s work

In July 2025, an AI coding agent inside Replit deleted a live production database belonging to SaaStr during an active code freeze after being explicitly told not to make changes. It then generated roughly 4,000 fake user records and told the team a rollback wasn’t possible when it was. Nobody asked the agent to do any of this. It made an autonomous decision with no human checkpoint in the loop.

This case is worth citing precisely because it isn’t exotic. It’s what happens when the independent verification step of a QA process gets quietly skipped in the name of speed, and it’s part of why the OWASP GenAI LLM Top 10 for 2026, released this August and weighted using real incident data rather than expert opinion alone, moved “Excessive Agency” up to third place. That category exists specifically for AI systems, coding agents included, given more autonomy than the surrounding process can safely support.

What a real testing framework for AI-generated code looks like

Engineering leaders who are getting ahead of this aren’t slowing down AI adoption. They’re building a validation layer that matches its speed. In practice, that framework has a few consistent components.

Tools that fit this framework

A working validation layer for AI-generated code usually combines a few categories rather than one single tool.

• Static application security testing (SAST). Tools such as CodeQL, Semgrep, and Snyk Code scan every commit automatically and catch the injection, permission, and unsafe pattern issues that show up disproportionately in AI-generated code. These are the same category of tools Suphi Cankurt of AppSec Santa used to test 522 samples across six large language models.
• Code quality and maintainability tracking. SonarQube, whose own 2026 survey data shows users are 44% less likely to see AI-related production outages, tracks duplication, complexity, and churn over time rather than only a pass-or-fail coverage number.
• Independent test generation. Tools that generate tests from requirements rather than from the code itself give a second, differently biased perspective on the implementation, instead of a rubber stamp from the same model.
• AI-assisted code review. GitHub Copilot’s code review features and similar tools are useful as a first pass, the same way they’re useful for unit test generation. Per the framework above, though, they work best as a supplement to independent human and automated review, not a replacement for it.

For a broader look at where AI tooling fits across the QA stack rather than just code generation, see Top 10 AI Testing Tools for Software and The Future of QA: Testers or AI?

Best practices for teams scaling AI-assisted development

• Treat AI output like a new hire’s first pull request every time. Not because the model is untrustworthy in general, but because a 56% average security pass rate means roughly half of what it writes needs a second look every time.
• Keep test authorship separate from code generation. Whether that’s a different person or a deliberately different process, the goal is breaking the loop where a model checks its own assumptions against itself.
• Automate the mechanical checks and staff the judgment checks. Static analysis and linting should run on every commit with no exceptions. Human review should focus on what scanners can’t evaluate: whether the code solves the right problem and whether it respects the real authorization model.
• Track quality metrics that AI can quietly erode. Code churn, duplication, and refactoring rate are leading indicators of technical debt building up faster than usual. GitClear’s 2026 data shows all three moving in that direction industry-wide, though the company sells code quality tooling and other factors, such as concurrent staffing changes, likely play a role too.

The real question for engineering leaders

The conversation inside most companies right now is still “How do we ship faster with AI?” The more useful conversation is “What does our validation process need to look like now that our output has tripled?” Those are different problems, and the second one doesn’t get solved by hiring faster or writing more prompts. It gets solved by building, or bringing in, a QA process specifically designed for a codebase where a meaningful share of the logic was never touched by a human until after it was already written.

The cost comparison isn’t close. A vulnerability caught in a test suite costs an engineering hour. The same vulnerability caught in production, after a data exposure incident or a customer-facing outage, costs a security response, a disclosure process, and, as the Replit incident showed, potentially the trust of the customers relying on what was built.

Where this fits into your roadmap

If your team has scaled AI-assisted development faster than your QA process, you’re not behind. You’re in the same position most engineering organizations are in right now. The teams pulling ahead are the ones treating this as a process gap to close deliberately, rather than a risk to hope doesn’t materialize.

We work with engineering teams to build exactly this kind of validation layer: independent test coverage that isn’t written by the same model that wrote the code, security-focused review for the vulnerability patterns AI-generated code produces most often, and a QA process structured to match the speed AI development actually moves at. If your team is shipping AI-generated code faster than it’s being verified, that’s a conversation worth having before it shows up as an incident report instead.

FAQ

What percentage of AI-generated code actually contains vulnerabilities? It depends on the study, but the range is consistent enough to take seriously. Veracode’s 2026 report found AI models pass security tests only 56% of the time on average, with 44% of code generation tasks introducing a risky flaw. Independent testing of 522 samples across six large language models, run by AppSec Santa, found a 25.7% confirmed vulnerability rate, roughly one in four.

Should AI be allowed to write its own tests? It can, but it shouldn’t be the only check. A model that misunderstands a requirement, an edge case, or a security boundary will typically write a passing test for its own flawed logic, since it’s validating against its own assumptions rather than the actual requirement. Independent test authorship, whether that’s a human or a separate process, catches what self-testing structurally can’t.

Is static analysis enough to catch AI-generated code risks? Static analysis tools such as CodeQL, Semgrep, and Snyk Code catch a meaningful share of mechanical issues automatically, right when code is committed: broad permissions, injection risks, and unsafe patterns. They don’t catch whether the code solves the right business problem or respects the intended authorization model. That still needs a human checkpoint.

What is “vibe coding,” and why does it need a different QA approach? Vibe coding refers to building software largely by prompting AI and accepting its output with minimal manual review. It isn’t inherently unsafe, but it removes the friction that used to force a second set of eyes on new logic. Teams doing this at scale need to rebuild that friction deliberately, through automated scanning and defined human checkpoints, rather than assume it happens on its own.

Does AI-assisted development actually save time once you account for QA? Often yes, but the net gain shrinks if testing isn’t scaled alongside generation. GitClear’s 2026 research found refactoring activity down 70% and code duplication up 81% since 2023 in AI-heavy codebases, both signs of technical debt building up faster than teams are used to. That research comes from a vendor with a commercial stake in the finding and shows correlation rather than proven cause and effect, so treat it as a signal worth investigating on your own codebase rather than a settled fact.