Why QA Teams Are Seeing More Bugs Since Developers Started Using AI
Software Testing Mentor and RCV Academy 
Ask a developer how AI coding tools are working out and you will likely hear about speed. Ask the QA engineer testing what that developer just shipped, and you get a different answer. A 2026 survey of 300 QA engineers, SDETs, and test leads found that 52 percent report bug volume has increased since their development teams started using AI to generate code, and 58 percent say their own testing workload has grown along with it. Nobody added QA headcount to match.
This is not a story about AI being bad at writing code. It is a story about what happens when the speed of writing code outpaces the speed of verifying it.
Two different pictures of the same code
Developer surveys and QA surveys have been telling two separate stories, and almost nobody puts them side by side. Sonar's 2026 State of Code report, based on 1,149 professional developers, found that 82 percent agree AI helps them code faster, and 72 percent of developers who have tried AI tools now use them every day. That part of the story is genuinely positive.
The same report also found that 96 percent of developers do not fully trust that AI generated code is functionally correct, and 61 percent agree that AI often produces code that looks correct but is not reliable. Only 48 percent say they always check their AI assisted code before committing it. Put those two findings together and the pattern becomes obvious, code is being produced faster than it is being verified, and a lot of that unverified code is landing on QA's desk.
The 300 person QA survey mentioned earlier adds the other half of the picture. 65 percent of QA engineers now work with development teams that use AI to generate code actively, so this is not an edge case anymore, it is the default input arriving at the testing stage.
What kind of bugs are actually increasing
Not every category of bug increased equally. Among QA engineers who described the defects they catch most often in AI generated code, logical errors topped the list at 58 percent, followed by unhandled edge cases at 52 percent, and duplicated or unnecessary code at 42 percent. Security vulnerabilities came in far lower, at 10 percent, not because AI generated code is secure, but because catching CWE level vulnerabilities was never QA's job to begin with, that responsibility sits with application security tooling.
The pattern QA engineers described most consistently was not a single bug type but a shape, code that handles the obvious case correctly and breaks something unrelated a few steps away. One respondent described UI elements disappearing after a change that had nothing to do with the new functionality. Another described a generated variable name colliding with one that already existed elsewhere in the codebase, a collision review missed that only broke in specific execution paths. AI tools solve the problem directly in front of them well and understand the surrounding system less reliably.
Why code review is not catching this earlier
The honest answer is that review has not kept pace with generation. Data from over eight million pull requests found that review time on AI generated pull requests has increased 91 percent, and those pull requests wait 4.6 times longer for a reviewer to even pick them up compared to human authored ones. When a plausible looking pull request can be produced in minutes, the review attention available per line of code goes down right as the review attention actually needed goes up.
QA engineers describe feeling this directly, with several respondents noting developers submitting AI assisted fixes without re checking whether the fix addressed everything QA had flagged, sending it straight back to testing instead.
A related finding is worth knowing even though it sounds counterintuitive. A controlled study from METR found that experienced developers using AI tools on complex, familiar codebases were actually about 19 percent slower, despite feeling roughly 20 percent faster and predicting even larger savings beforehand. That gap between how fast AI assisted work feels and how fast it actually moves shows up again and again in this research, on both the developer side and the QA side.
What QA teams are already changing
Most QA engineers are not waiting on a policy fix. In the same survey, 74 percent said their testing approach has changed specifically because of AI generated code, clustering around a few consistent habits: spending more time on edge cases and boundary values rather than trusting the happy path, running broader regression suites in places that used to only need smoke testing, and checking generated code against the original requirements more explicitly rather than assuming it did what the ticket asked.
A number of QA engineers are also using AI themselves, not to generate final code, but to draft test plans, surface edge cases they might not think of alone, and review test suite structure. Used this way, AI becomes a tool for the verification side of the process, not just the generation side, which is arguably where it belongs given how the trust numbers above actually break down. RCV Academy's Generative AI and AI Agents for QA course covers exactly this kind of workflow, using AI tools to strengthen test coverage rather than just generate code faster.
Frequently asked questions
Does this mean AI coding tools are net negative for software quality? The data does not support that conclusion cleanly. The same research shows genuine productivity gains and, in specific well scoped tasks like fixing flaky tests or optimizing a slow query, real quality improvements. The negative findings concentrate specifically around open ended feature work reviewed too quickly, not AI assisted coding as a whole.
Should QA teams be catching security vulnerabilities in AI generated code? Generally no, and treating QA as the safety net for AI code security is a mismatch of roles. Application security tooling, static analysis, and dependency scanning are built for that job. QA's defect intake data reflects that division of labor, with security findings showing up far less often than functional and logical defects.
What is the single most useful change a QA team can make right now? Based on what QA engineers themselves report doing, broadening regression coverage for areas a change did not obviously touch tends to catch the specific failure pattern showing up most, unexpected impact in unrelated parts of the system.
RCV Academy's ISTQB Generative AI certification course covers exactly this kind of risk, how to evaluate AI generated output critically rather than trusting it by default, which is fast becoming one of the most practical skills a tester can have.
Categories: : Agentic AI, AI SDET, AI Tools, Generative AI
