AI now authors roughly half of all committed code in organizations that use it, yet only 56% of AI-generated code passes basic security tests, and just 33% of developers trust its accuracy. Quality assurance was designed for a world where humans wrote every line. That world is gone, and the QA function that replaces it looks different in tooling, process, and people.
The 2025 DORA report finds that AI adoption among software professionals is at 90%, with developers spending a median of two hours a day working with AI tools. Veracode's 2026 GenAI Code Security Report estimates that AI now authors roughly half of all committed code in organizations using these tools. In terms of volume alone, AI has become the most prolific contributor on most engineering teams.
It is also the contributor nobody fully trusts. In Stack Overflow's 2025 Developer Survey, 46% of developers actively distrust the accuracy of AI output, while 33% trust it, and only 3.1% trust it highly. DORA found the same pattern: 90% adoption, but only 24% of professionals reported substantial trust in AI-generated code. Engineering organizations are shipping enormous amounts of code written by a contributor they would never let merge unsupervised if it were a person. This article examines what that does to quality assurance: what changed, why traditional QA misses new failure modes, and what a testing process built for AI-era volume actually looks like.
How Do You Test Software When AI Writes Half of It?
Testing AI-written software starts with one rule: treat AI-generated code as an untrusted contribution. Track which code is AI-authored, keep a named human accountable for every merge, run automated security scanning on every commit, and define tests before generation so the suite acts as a specification rather than an afterthought.
That rule sounds obvious. In practice, most organizations are running the opposite experiment: AI raised the volume and speed of code production while review and testing capacity stayed flat. The gap between those two lines is where quality incidents now come from, and closing it is a process and staffing problem before it is a tooling problem.
What Has Actually Changed for QA?
There is more code arriving faster, from a contributor with no memory of your system. A model does not know your naming conventions, your legacy quirks, or the incident from last March. It produces locally plausible code without global context, shifting the defect profile away from typos and toward integration and design errors that unit-level checks do not catch.
Review capacity is now the bottleneck. Reviewers face a growing stream of code they did not write and cannot interrogate the author about. Stack Overflow's 2025 survey found that the single largest frustration with AI tools, cited by 66% of developers, is solutions that are almost right but not quite. Almost right is exactly the category human reviewers are worst at catching at speed: the code compiles, reads cleanly, and fails on the edge case.
Debugging costs moved downstream. In the same survey, 45% of developers reported that debugging AI-generated code takes more time than debugging their own. The time saved at generation is partially repaid at diagnosis, with interest, when the person debugging never understood the code's intent in the first place.
Why Does AI-Generated Code Fail Quality and Security Checks?
The security data gives the clearest picture, because it has been measured the same way for two years. Veracode's 2026 report found that AI-generated code passes security tests just 56% of the time, essentially unchanged from 55% in the previous report, even as the models themselves got better at writing working code. In other words, 44% of code-generation tasks introduced a known vulnerability class, and a second year of model progress did not reduce that number.
The failure pattern matters more than the average. AI models now handle the famous, well-documented flaws well: SQL injection defenses pass 83% of the time, and cryptographic implementations pass 87%. The failures concentrate where security depends on context rather than pattern matching: cross-site scripting passes only 15% of the time, and log injection just 12%. A model can reproduce a parameterized query it has seen a million times. It cannot know which of your outputs will eventually render in a browser or land in a log pipeline.
For QA leaders, that asymmetry is actionable. AI-generated defects are not random; they cluster in predictable, scannable categories. A pipeline tuned for those categories catches a large share of what human reviewers, reading almost-right code at speed, will miss.
What Does an AI-Era QA Process Look Like?
Set a provenance policy first. You cannot apply different scrutiny to AI-written code if you cannot identify it. Require AI-assisted contributions to be flagged at the pull-request level and tracked as metadata. This is also the foundation regulators are starting to assume: risk frameworks and emerging AI rules expect organizations to know where AI operates in their systems.
Rebuild code review around accountability, not authorship. The old social contract, in which the author explains and defends their code, breaks down when the author is a model. Replace it with explicit merge ownership: a named human is accountable for everything that lands, AI-assisted or not. Keep diffs small enough to review honestly, and budget review time as a first-class engineering cost rather than an interruption.
Move security scanning into the pipeline, tuned to the known failure classes. Static and dynamic analysis on every commit stops being optional when 44% of generation tasks introduce a vulnerability. Prioritize the categories where models fail most: XSS and injection into downstream systems, and treat scanner findings in AI-authored code as expected output, not exceptional events.
Write the tests before you generate the code. Test-first development quietly became more valuable in the AI era: a well-specified test suite acts as the specification the model never had, and it converts "almost right" from a silent risk into a red build. Coverage thresholds and mutation testing prevent generated code from being graded leniently.
Use AI to test AI, with the same trust rules. AI-generated tests are a legitimate way to expand coverage fast, and 59% of professionals in DORA's survey say AI has positively affected code quality. But a generated test that asserts what the code does, rather than what it should do, launders bugs into the suite. Humans own the assertions; AI drafts the scaffolding.
What Does This Mean for Your QA Team?
DORA's 2025 report describes AI as a mirror and multiplier: it amplifies the strengths of well-run teams and the weaknesses of fragmented ones. Nowhere is that more literal than in QA. Teams with strong review culture, real test coverage, and clear ownership are absorbing AI-scale code volume and shipping faster. Teams that treated QA as a cost center are discovering that AI has multiplied exactly what they underinvested in.
The staffing implication is a shift in seniority and role, not a reduction. Manual, repetitive verification is increasingly automated, while demand grows for senior QA engineers and SDETs who can design test strategy, build pipeline tooling, and triage risk across code no single human wrote. That talent is scarce in the US market, and it is one of the roles US companies most often fill through nearshore AI-experienced engineers working in the same time zones as their teams. How you structure that capacity, whether by hiring, upskilling, augmentation, or a dedicated team, is the same staffing-model decision we mapped in our guide to staffing for AI.
It is also a build-quality decision. QA of AI-written code works best when the delivery process is engineered for it from the start: provenance tracking, scanning, and test-first guardrails belong inside the development workflow, which is how our AI development teams ship systems that hold up in production rather than in demos.
Common Questions About QA for AI-Generated Code
Can you trust AI-generated code in production?
Not without verification. AI-generated code passes security tests only 56% of the time, according to Veracode's 2026 report, and only 24% of professionals report substantial trust in it per DORA 2025. Production readiness comes from the process around the code: accountable review, automated scanning, and tests that specify intended behavior.
How much enterprise code is written by AI?
Veracode's 2026 GenAI Code Security Report estimates AI now authors roughly half of all committed code in organizations using AI coding tools. Adoption is near-universal: the 2025 DORA report found 90% of software professionals use AI, spending a median of two hours per day with these tools.
What are the most common security flaws in AI-generated code?
Context-dependent vulnerabilities dominate. In Veracode's testing, AI code prevented cross-site scripting only 15% of the time and log injection 12%, while handling well-documented patterns like SQL injection (83%) and cryptography (87%) far better. Scanning pipelines should be tuned to those weak categories.
Should QA teams use AI to generate tests?
Yes, with guardrails. AI accelerates test scaffolding and coverage expansion, but a generated test may assert what buggy code does rather than what it should do. Keep humans accountable for the assertions and the test strategy, and measure suite quality with coverage and mutation metrics rather than test count.
If AI is writing half of your code, quality is no longer a review stage: it is an engineering system that needs people who know how to build it. Talk to the Golabs team about staffing senior QA capacity or building AI-era quality guardrails into your next project.