State of AI-Generated Code 2026: The QA and Testing Gap

An industry study based on a 2026 survey of 300 QA engineers, SDETs, and test leads, examining how AI-generated code is reshaping software quality, testing workload, and defect patterns downstream of development.

Executive Summary

Every major report on AI-generated code — Stack Overflow, JetBrains, GitHub, LinearB, DORA — is written from the developer's seat. This one is written from the seat of the QA engineer who inherits what developers ship.

We surveyed 300 QA engineers, SDETs, and test leads about the AI-generated code arriving at their desks in 2026. The findings do not refute the developer-side productivity numbers. They add the second half of the ledger.

The five numbers

• 65% of QA engineers work with development teams that use AI to generate code actively. Another 16% report occasional use. AI-authored code is now the default input to testing, not the exception.

• 52% report bug volume has increased since developers began using AI. Only 2% report a decrease.

• 58% report their own testing workload has grown. None report additional QA headcount being added in response.

• 0 of 300 respondents gave AI-generated code a full trust rating on a five-point scale. Mean trust: 3.16.

• 91% — the increase in pull request review time in AI-adopting teams, per LinearB's 8.1-million-PR dataset [9]. AI-authored PRs wait 4.6× longer for review than human-authored ones. QA is absorbing the review deficit downstream.

What this means

The industry has been keeping one ledger: PRs merged, cycle time, developer NPS. It shows AI adoption working. The second ledger — bugs caught, regression scope, testing hours per feature, trust — shows a different picture from the QA seat of the same organization.

Both are true. Both belong on the dashboard.

What comes next in this report

Sections 1–3 establish the gap between what developers report and what QA reports about the same code. Section 4 documents the specific defect signature QA catches: logic errors, unhandled edge cases, duplication, and regression bugs in areas the change did not appear to touch. Section 5 — the report's namesake — describes the widening distance between how fast AI-assisted code is now produced and how fast QA can test it. Section 6 explains why QA is not, and should not be, the security net for AI-generated code. Section 7 examines the review process and the governance vacuum around it. Section 8 states what the survey supports as operational conclusions, and what it does not.

Every external statistic in this report is cited to its primary source. Every gap in the data is named rather than filled.

1. Two Ledgers, One Codebase

1.1 What developers report

The public record on developer experience with AI coding tools is unusually well-documented. Stack Overflow's 2024 Developer Survey found that 76% of developers are using or planning to use AI tools in their development process, up from 70% in 2023, with 62% currently using them [1]. While in 2025 they show adoption continuing to climb — 84% of developers now use or plan to use AI tools — but trust moving in the opposite direction: 46% say they actively distrust the accuracy of AI output, versus 33% who trust it, and positive sentiment toward AI tools fell from over 70% in 2023–2024 to 60% in 2025 [31]. A field experiment at Microsoft, Accenture, and a Fortune 100 electronics manufacturer covering 4,867 developers reported a 26% average increase in weekly pull requests completed by Copilot users, with junior developers benefiting most [11][12]. LinearB's 2026 Software Engineering Benchmarks Report, based on 8.1 million pull requests across 4,800 organizations, found that developers using AI complete 21% more tasks and their teams merge 98% more pull requests than teams that do not [9][10].

Sentiment tracks throughput. DORA's 2024 report found that AI adoption significantly increases individual productivity, flow, and job satisfaction [16]. Stack Overflow's forward-looking data shows 80% of developers expect AI tools to become more integrated in how they test code within the next year — a higher expectation than for AI's role in writing code or documenting it [2].

Read together, these numbers describe a workforce that is adopting quickly, shipping more, and feeling good about it. If the story ended here, the case for AI-assisted development would be unambiguous.

1.2 What QA reports

The story does not end there, because none of the sources above ask the QA function about the same time window.

DeviQA's 2026 internal survey of 300 QA practitioners — 40% Automation QA, 40% Manual QA, and 20% SDET, weighted toward respondents with five or more years of experience — asks exactly that. Of those respondents, 65% say the development teams they work with use AI to generate code actively, and another 16% say sometimes. Only 19% say they do not know. AI-assisted code is now, on the QA floor, the default assumption rather than the exception.

What has followed that adoption looks different from the developer-side ledger. 52% of respondents report that bug volume has increased since developers began using AI, with 18% of those describing the increase as noticeable. 58% QA engineers report their own testing workload has grown. Mean trust in AI-generated code, on a five-point scale, sits at 3.16. The distribution is more revealing than the average: 61.3% of respondents rated their trust at 3, 29.0% rated it at 4, 9.7% rated it at 1 or 2, and no respondents (0%) gave the maximum score of 5.

The same period during which developer-facing research reports 98% more merged PRs and rising job satisfaction is, from the QA seat, a period in which bug volume rose for the majority, testing effort rose for the majority, and full trust in AI-generated code remained absent.

1.3 The three gaps this report will map

This report frames the divergence as three overlapping gaps.

• The perception gap, examined in Section 3, separates how developers experience AI-generated code from how QA does. The two populations answer the same question about the same code and produce different answers.

• The testing gap, examined in Section 5 and the report's namesake, is the widening distance between the rate at which AI-assisted code is now written and the rate at which QA capacity has scaled to test it.

• The review gap, examined in Section 7, is the space that has opened at the merge boundary — where developers hand off, reviewers queue, and QA increasingly becomes the reviewer of last resort for code that no human author has read carefully.

Each gap is measurable. None is closing on its own.

2. Adoption on the QA Floor

2.1 What QA sees on the dev side

Public adoption figures for AI coding tools describe an unambiguous ramp. JetBrains' 2024 State of the Developer Ecosystem reports retention ratios of 66.4% for ChatGPT and 64.5% for GitHub Copilot among developers who tried them [8][6]. In 2025 edition they find adoption has become close to universal — 85% of developers regularly use AI tools for coding, and 62% rely on at least one dedicated AI coding assistant or agent — but only around 44% report AI as fully or partially integrated into their actual workflow, a gap the survey frames as adoption outrunning integration [33]. Stack Overflow's 2024 survey puts current developer use of AI tools at 62%, up from 44% the year before [1]. These numbers describe the developer's own hand on the keyboard.

The QA-side reading of the same phenomenon comes from a different angle: what QA sees arriving in the codebases they inherit. On that measure, DeviQA's 2026 survey finds AI-assisted development is no longer a pilot or an experiment in the projects QA works on. 65% responders report that their development team uses AI to generate code actively. Another 16% report occasional use. Other QA respondents work on projects where AI-generated code is now part of the normal input stream to testing.

The distribution matters as much as the headline. Active AI adoption is not concentrated in any single experience tier. 66.7% of Automation QA respondents with 5+ years of experience reported that their development team actively uses AI, while 60.0% of respondents with less than two years of experience said the same. Whatever else the data shows about how QA engineers experience AI-generated code, unfamiliarity is not the driver. Most respondents are working with AI on a daily basis.

2.2 Where visibility breaks down

19.4% of respondents answered "I don't know" when asked whether their development team uses AI to generate code.

That response is a finding in itself. QA professionals typically have access to source code, pull requests, and — particularly in the case of SDETs — often work in the same repositories as developers. The fact that 19.4% of respondents could not say whether AI is used to write the code they test suggests that adoption is occurring without clear disclosure, pull request metadata, or the operational conversations that would make AI-generated code visible.

The pattern is reflected in the free-text responses as well. One SDET with more than eight years of experience noted that even with access to the development codebase, they could not distinguish AI-generated code from human-written code. Another respondent, a Manual QA with two to five years of experience, wrote that they had "not seen the code before AI and don't see it after" — a candid acknowledgment that the shift has taken place outside their field of view.

This aligns with what developer-side research has already documented. Stack Overflow's 2024 code assistant pulse survey found that 73% of respondents do not know or are unsure whether their company has a formal AI policy [4]. What DeviQA's survey adds is that the same visibility gap exists one seat downstream, at the QA function that is expected to test whatever the policy — formal or absent — has produced.

2.3 Which tools show up in QA's daily work

The specific tools QA respondents name in open-ended responses depart from the developer-survey consensus.

External research is unambiguous about the top of the market. Stack Overflow ranks ChatGPT as the most used AI tool among developers, with GitHub Copilot at 41% [2]. JetBrains reports Copilot retention at 64.5% and ChatGPT at 66.4%, with Anthropic's Claude at a 52.4% adoption ratio among those who tried it [8].

DeviQA's QA respondents mention Claude and Claude Code more frequently than any other named tool. Multiple respondents describe QA workflows built around Claude Code — analyzing tickets, generating test plans, surfacing edge cases, and in at least one case, integrating with Git and Jira to attempt automated bug fixes on minor issues. GitHub Copilot appears in the free-text responses less often than Claude does.

This is a proprietary signal worth naming rather than smoothing. DeviQA's respondent pool leans toward Anthropic tooling. Whether that reflects the tooling mix on the client projects DeviQA staffs, or a broader QA-side preference for a conversational model over an autocomplete-first assistant, cannot be determined from a sample of 300. It is flagged as a question for the 2027 edition, where a larger sample can resolve it.

What can be said with the current data: the tool that shows up most in QA's descriptions of AI-generated code they now test is not the tool that leads the developer surveys.

2.4 Adoption without a policy

The final structural observation of this section is what the survey did not measure — and why that omission is itself a finding worth stating publicly.

The external record is already clear on the direction. JetBrains reports that nearly 80% of companies either allow third-party AI tools or have no formal restrictions [7]. Stack Overflow reports that 73% of developers are unsure of their company's AI policy [4]. Application Security Standards' 2026 AI-Generated Code Verification Framework — one of the first attempts to map controls for AI-generated code to PCI DSS, OWASP ASVS, and SOC 2 [27] — exists precisely because the governance layer has lagged the tooling layer.

The pattern the report will return to in Section 7 is visible already: adoption arrived first, policy has not yet caught up, and the QA function is one of the first places the consequences land. Section 3 examines how that lands as a perception gap. Section 5 examines how it lands as a testing gap. The rest of the report is, in effect, a description of what happens downstream of the adoption curve described here.

3. The Perception Gap

3.1 What developers say about AI-generated code quality

The developer-side view of AI-generated code is, in aggregate, positive on speed and mixed on trust — but the trust reservations do not appear to slow adoption.

Stack Overflow's 2024 Developer Survey captured the tension in a single pair of numbers. Seventy-six percent of developers were using or planning to use AI tools; only 43% said they trust the accuracy of those tools [3][1]. That tension sharpened in the 2025 survey: adoption rose to 84%, but only 33% said they trust the accuracy of AI output, while 46% said they actively distrust it — the widest adoption-trust gap in the survey's history [32]. Sixty-six percent named distrust of AI output as a top concern, and 63% said AI tools lack crucial organizational context [5]. Adoption ran ahead of belief.

The perceived-productivity picture is stronger than the trust picture, and it is where the gap this section names first becomes visible. METR's 2025 randomized controlled trial of 16 experienced open-source developers working on 246 real tasks in repositories they knew well found that developers using AI tools were 19% slower on average, even though they felt 20% faster and predicted 24% time savings before the study [13][15]. Over half of AI suggestions were unusable and required significant review or rework.

The METR finding is important because it establishes, in a controlled setting, that developers can be systematically wrong about their own throughput when using AI tools. The gap between how fast a developer feels and how fast they actually are is measurable in the same trial that measures both.

3.2 What QA says about AI-generated code quality

Ask the QA function to rate the same code and a different distribution appears.

DeviQA's 2026 survey asked respondents to rate their trust in AI-generated code on a five-point scale. The mean was 3.16 out of 5, but the distribution is more revealing than the average. 3.2% of respondents rated their trust at 1, 6.5% at 2, 61.3% at 3, 29.0% at 4. Zero of 300 respondents scored trust at 5.

The absence of the top score is not a rounding artifact. It is uniform across role and experience. Automation QA respondents, Manual QA respondents, and the single SDET all cluster in the 3–4 range. Respondents with 8+ years' experience are no more trusting than respondents with under two years' experience. The senior tier is, if anything, marginally more skeptical.

The contrast with the external record is direct. Snyk's 2024 State of Open Source report, surveying a developer-heavy sample of 453 technologists, found that 77.9% of respondents trust AI to enhance code security, and 84.1% said they audit AI-suggested open source packages with the same rigor as human-selected ones [23]. Same technology, adjacent questions, different professional population — and a trust distribution that does not resemble QA's.

The quality rating, asked separately in the DeviQA survey, showed the same pattern. Mean quality score ≈ 3.4/5. No respondent gave a 5.

3.3 The METR paradox, viewed from QA

METR's finding — that developers feel 20% faster and are 19% slower — describes a perception-vs-reality gap on the productivity axis. QA respondents, without prompting, describe an adjacent gap on the quality axis: code that looks correct to a reviewer at first pass, and reveals its problems only under structured testing.

The pattern surfaces in the free-text responses from respondents who trust AI-generated code more than the sample average, not less. A Manual QA with 5–8 years' experience who rated their trust at 4/5 nevertheless noted that "AI code may look syntactically correct, but contain hidden logical errors or missed exception handling." An Automation QA with 5–8 years' experience, also at 4/5, wrote that they now review autotest suites more carefully "for coverage completeness, because AI can implement the happy path well but miss non-standard cases."

The convergence with METR is not coincidental. Where METR found that reviewing AI-suggested code took longer than developers expected — enough to erase the throughput gain they perceived — QA respondents describe the downstream continuation of the same phenomenon: code that reads plausibly at review and fails under test.

The SDET in the sample summarized the dynamic in one line. "Some people don't look carefully at what was generated and then get unexpected problems. Others love to 'accept' the first working option AI gives, without trying to 'refine' it further." That is a perception-gap description written from the seat of the person who inherits the consequences.

3.4 Where senior QA disagrees with junior QA

Segmenting the trust and bug-volume responses by experience tier produces a directionally clear, though small-sample, finding: senior QA is not more comfortable with AI-generated code. They are, if anything, less.

Distribution based on 300 responses. Percentages within each experience tier.

Among respondents with 8+ years of experience, the mean trust rating is 3.4, slightly above the overall sample average. Regarding bug volume, 62.5% reported that AI-generated code contains the same or slightly more bugs, while 37.5% reported noticeably more bugs. 0% of senior QA respondents reported that AI-generated code contains fewer bugs.

Among respondents with less than two years of experience, 20.0% rated their trust in AI-generated code at 2, while another 20.0% gave the lowest possible rating of 1. Perceptions of bug volume were more mixed: 40.0% reported no change, while 20.0% reported noticeably more bugs.

"How has bug volume changed since your dev team began using AI to generate code?"

The direction matches the productivity literature. The Microsoft/MIT/Wharton field experiment found productivity gains concentrated among lower-tenure developers, with above-median-tenure developers showing no statistically significant throughput increase [11]. METR's contrarian trial, which found experienced developers 19% slower with AI in familiar codebases, has since been echoed by an ongoing methodological review from the same team [13].

The QA analog is directional rather than definitive. Sample sizes per experience tier are too small to draw strong statistical conclusions. But the direction is consistent: on both the productivity side (developer literature) and the quality side (this survey), more experience with the codebase in question correlates with less enthusiasm about AI-authored change to it.

3.5 Why this gap matters for engineering leadership

Most engineering leadership dashboards read from the developer side of the ledger. They report PR volume, cycle time, deployment frequency, and — when they capture sentiment at all — developer satisfaction. Each of those signals is real. Each is also drawn from the population that is authoring the code, not from the population that is validating it.

The perception gap this section documents is, in its practical form, a dashboarding problem. Leadership sees the axis where AI's contribution is unambiguously positive. It does not, in most current tooling, see the axis where QA reports a majority increase in bug volume, a majority increase in testing workload, and zero full-trust ratings across a small but experienced sample.

The rest of this report is, in part, an attempt to describe the second axis with enough specificity that it can be added to the dashboard.

4. The Bug Anatomy of AI-Generated Code

4.1 The QA-reported defect taxonomy

DeviQA's 2026 survey asked QA respondents to identify the defect categories they encounter most frequently in AI-generated code. The question allowed respondents to select multiple options from a predefined list and add additional categories in a free-text field. 87.1% of respondents provided a substantive answer, while 12.9% indicated that they either had no relevant experience or could not distinguish defects in AI-generated code from those in human-written code — a finding that reinforces the visibility gap discussed in Section 2.2.

Among all substantive respondents, the defect frequency distribution is as follows:

• Logical errors: 58% of substantive sample

• Unhandled edge cases: 52%

• Duplication and "garbage" code: 42%

• Non-compliance with requirements: 42%

• Integration problems: 26%

• Performance issues: 19%

• Incorrect or outdated APIs: 13%

• Security vulnerabilities: 10%

Two features of this distribution deserve early comment.

First, the top of the list is dominated by categories that are structurally invisible to static analysis and difficult to catch in code review. Logical errors and unhandled edge cases are, almost by definition, the defects that pass syntax checks, pass linters, pass compilation, and reveal themselves only under structured test execution or in production. They are QA-shaped defects.

Second, security vulnerabilities sit near the bottom. This is not a claim that AI-generated code is secure. Section 6 will examine why it is not. It is a claim that the QA function does not routinely catch security defects — because SAST, DAST, and SCA tooling are the appropriate owners, and QA in most organizations is not staffed to be the last-line defender against CWEs.

4.2 Where QA's list agrees with external research

The categories at the top of QA's list correspond closely to the failure modes external research has already documented, though from different angles.

The duplication finding is the sharpest external corroboration. GitClear's 2025 AI Copilot Code Quality report, based on 211 million changed lines from 2020 through 2024, found that the share of copy-pasted code in changed lines rose from 8.4% in 2021 to 12.3% in 2024, while the share of moved (refactored) code fell from 24.8% to 9.5% over the same period [17]. The report also found an eightfold increase in commits containing five or more lines of duplicated blocks during 2024, and all-line churn rising from 3.3% in 2021 to 5.7% in 2024. GitClear's follow-up 2026 research, 'The Maintainability Gap,' extends the same analysis through 2023–2026 across 623 million changed lines and finds the trend accelerating: block duplication climbed to 73.0 per million changed lines year-to-date in 2026 — an 81% increase over 2023 — while moved (refactored) code fell to just 3.8% of changed lines, down from 21% in 2022. Copy/paste now outpaces refactoring by roughly 5-to-1, and long-term legacy maintenance work has fallen 74% versus 2022 levels [37].

That trend line — more copy-paste, less refactoring, more duplicate blocks — is the aggregate industry version of what 42% of DeviQA's QA respondents report catching in their day-to-day work.

The edge-case finding aligns with METR's 2025 randomized trial, which reported that over half of AI suggestions to experienced open-source developers were unusable and required significant review or rework [14][15]. "Unusable" in that trial and "unhandled edge case" in DeviQA's survey describe overlapping phenomena from different vantage points: the developer's rework burden and the QA engineer's downstream catch.

The requirements-mismatch finding — 42% of QA respondents — has less direct external corroboration in quantitative form. Sonar's State of Code: Reliability report, based on 7.9 billion lines of code across 40,000+ organizations, established a baseline reliability-issue density of about 2,100 bugs per million lines of code, without segmenting AI-authored from human-authored code [18]. The industry does not yet have a comparable "requirements-drift" metric, and requirements-mismatch is a harder category to instrument than duplication or churn. DeviQA's finding here is a proprietary contribution to a measurement area the external literature has not yet formalized.

4.3 Where QA's list disagrees with the discourse

The public discourse on AI-generated code security is loud, well-sourced, and technically important. The NYU Tandon study of 1,689 Copilot-generated code samples across 89 security-sensitive scenarios found that approximately 40% of suggestions contained vulnerabilities mapped to MITRE CWE Top 25 categories [19]. Georgetown CSET's 2024 review concluded that AI code generation models "frequently output insecure code" under experimental conditions [20]. A much larger and more recent study — Veracode's 2025 GenAI Code Security Report, which tested over 100 LLMs (including GPT, Claude, and Gemini families) across 80 real-world coding tasks — found that 45% of AI-generated code samples contained at least one security vulnerability, with the rate exceeding 70% for Java specifically. Notably, the report found this ~45% rate has stayed roughly flat across successive model generations from mid-2024 through late 2025, suggesting that newer, larger models have not meaningfully closed the security gap on their own [38]. Package-hallucination research has documented over 205,000 unique hallucinated package names across analyzed models, with 43% of hallucinated names persisting across re-runs [21][22].

Ten percent of DeviQA's QA respondents named security vulnerabilities as a top defect category.

Both figures are correct. Their coexistence is the finding. Security defects are being generated at high rates by AI tools; they are also not being caught by QA in high proportion, because catching them was never the design intent of the QA function. The mismatch between how prominent security appears in AI-code discourse and how prominent it appears in QA's actual defect intake is worth stating plainly, because it has an operational consequence: any organization relying on QA to be the AI-code security net has misassigned the role.

Section 6 develops this point further. The point to register here is narrower: QA's defect anatomy is not a comprehensive audit of what is wrong with AI-generated code. It is a specific view — the view of the defects QA is positioned to catch. Reading it as a full audit would understate security risk; reading it as no signal on security would misread it in the opposite direction.

4.4 The regression amplifier

The most consistent qualitative pattern in the free-text responses is not a defect type. It is a defect topology: AI-authored change producing regression bugs in areas the change did not appear to touch.

One Manual QA with 5–8 years' experience wrote that bugs are now appearing "in places where bugs never happened before. Where I could get by with smoke testing and detailed feature testing, I now run regression." A Manual QA with under two years' experience described client-side developers adopting AI in production and then finding that "things that had nothing to do with the new release started breaking. And breaking critically." An Automation QA with 5–8 years' experience described a post-merge scenario in which "UI elements started disappearing that had nothing to do with the new functionality," compounded by feature-flag combinations that broke previously stable flows.

These are not three variants of the same defect. They are three variants of the same shape of defect: unexpected downstream impact from a change whose visible surface appeared narrow.

Two mechanisms plausibly explain the pattern. The first, described by several respondents, is that AI tools operate without full context of the surrounding codebase — they solve the local problem well and disturb non-local structures they did not model. An Automation QA with 8+ years' experience gave a concrete example: AI-generated code created a type name that already existed elsewhere in the application, review did not catch the collision, and real logic broke in cases that happened to hit the shadowed type. The second, described in Section 5 and Section 7, is that reviewers of AI-authored PRs are spending less time per line and more time per PR — a division of attention that misses cross-module impact.

The aggregate industry evidence points in the same direction. DORA's 2024 Accelerate State of DevOps report found that AI adoption significantly improves individual productivity and flow, but negatively impacts software delivery stability and throughput [16]. This finding has since been partially reversed: DORA's 2025 report (rebranded 'State of AI-Assisted Software Development') found that, for the first time, AI adoption correlates positively with software delivery throughput — while continuing to correlate negatively with stability. DORA frames AI as an 'amplifier' of existing engineering conditions rather than a uniform tradeoff [34]. "Stability" in the DORA framework — the ability to change software without incident — is the macro-level version of what QA describes at the micro level as regression amplification.

4.5 When AI helps QA

Honest reporting on defect anatomy requires reporting on the reverse case as well. Respondents were asked to describe both bugs caused by AI-generated code and cases where AI-generated code helped. Four responses in the "helped" category are worth naming, because they clarify where AI-authored change is producing net-positive outcomes on the QA-observable axis.

An Automation QA with 8+ years' experience described AI identifying inefficient database queries and producing a measurable platform-wide performance improvement. Another Automation QA at the same experience level described AI locating the root cause of flaky automated tests at the infrastructure level — CI/CD failures that passed locally, driven by generated test data and parallel job configuration — and shortening the fix cycle. A Manual QA with 5–8 years' experience described AI fixing a rare login race condition that surfaced once per hundred logins and had gone uncracked by the team. The SDET in the sample described AI PR review consistently surfacing improvement points that then became productive team discussions, alongside AI assistance in refactoring against a known target file structure and in generating custom bash scripts for CI configuration.

The pattern in these positive cases is not incidental. Each describes AI applied to a well-scoped, well-specified problem — a slow query, a flaky test, a bounded refactor against a template, a scripting task with a clear specification. None describes AI succeeding at open-ended feature work of the kind that dominates the negative cases in Section 4.4. The line between where AI-generated code helps QA and where it produces regression amplification appears to run through problem specification, not through problem complexity.

5. The Testing Gap

5.1 Framing the gap

The four preceding sections describe the state of AI-authored code arriving at the QA function: adopted broadly on the dev side, perceived very differently by developers and QA, and producing a defect signature dominated by logic errors, edge cases, duplication, and regression amplification.

This section addresses the structural consequences. The rate at which AI-assisted code is now being produced has changed. The rate at which QA capacity has scaled to test it has not — or, more precisely, has scaled only through the additional effort of individual QA engineers rather than through additional QA headcount or additional QA tooling capacity.

The gap has three components.

• The volume gap is the delta between code generation rate and testing rate.

• The review gap is the delta between the time available for pre-merge code review and the time AI-authored PRs actually receive.

• The coverage gap is the delta between what AI-authored code exercises well (the happy path) and what production requires exercising well (everything else).

Each component is measurable. Each is documented independently in the external record and in DeviQA's survey. The section that follows treats them in sequence.

5.2 The volume gap

The volume signal on the developer side is unambiguous. LinearB's 2026 Software Engineering Benchmarks Report, drawing on 8.1 million pull requests across 4,800 organizations in 42 countries, reported that developers using AI complete 21% more tasks and their teams merge 98% more pull requests than teams that do not [9][10]. GitClear's independent code-change analysis shows all-line churn rising from 3.3% in 2021 to 5.7% in 2024 [17] — more change per unit time, at higher rework rates.

The volume signal on the QA side, measured in DeviQA's 2026 survey, does not match that rate.

58.1% of respondents reported that their testing workload has increased since developers began using AI. Of those, 27.8% described the increase as significant, while 72.2% characterized it as modest. Meanwhile, 41.9% reported no change in testing workload, despite 64.5% of respondents indicating that their development team actively uses AI and 51.6% reporting an increase in bugs.

The 41.9% reporting no change in workload is the more significant finding. It does not suggest that testing has become easier. Rather, it indicates that testing capacity has not expanded in proportion to the increase in AI-generated code. Considered alongside the bug-volume data, the pattern is straightforward: more code is being produced, more bugs are reaching QA, and existing testing teams are expected to absorb the additional work without a corresponding increase in capacity.

None of the qualitative responses mentioned additional QA hiring following AI adoption. While the survey did not explicitly ask about headcount — a limitation discussed in Section 8 — the absence of any references to team expansion across the open-ended responses is notable. Instead, respondents consistently described adapting to higher regression workloads, broader edge-case coverage, revised test plans, and AI-assisted testing workflows, suggesting that QA teams are handling increased demands without additional staffing.

The macro-level version of this dynamic is documented in DORA's 2024 report, which found that AI adoption improves individual productivity but negatively impacts delivery stability and throughput at the team level [16]. An update is warranted here: DORA's 2025 report found that this throughput penalty no longer holds uniformly — AI adoption now correlates positively with software delivery throughput at the team level, though the negative effect on stability persists. DORA attributes the shift to teams maturing their AI practices rather than to the underlying tradeoff disappearing [34]. Individual gains and team-level cost are not incompatible findings. They describe the same phenomenon from different heights.

5.3 The review gap

The review gap has a sharper external signal than the volume gap.

LinearB's 2026 dataset found that pull request review time has increased by 91% in AI-adopting teams. AI-generated PRs wait 4.6× longer than human-authored PRs before a reviewer picks them up, though they are reviewed 2× faster once review begins. AI PR acceptance rate is 32.7%, versus 84.4% for human-authored PRs [9][10]. Xeve's analysis of the same data noted that to achieve the same number of merged PRs, teams need approximately 3.06 AI PRs per merge versus 1.18 human PRs per merge.

Read together, these numbers describe a review process under load. Faster generation is not producing faster review. It is producing deferred review, rejected review, and — in the tail of PRs that do get merged — review that has less human attention per line than the human-authored equivalent.

The consequence, from the QA seat, is that the review function is not fully being performed at the merge boundary. It is being pushed downstream. Two verbatim responses illustrate the pattern with unusual clarity.

A Manual QA with 2–5 years' experience described a case in which a developer submitted an AI-assisted fix, QA identified and documented multiple bugs with reproduction video, and the developer re-submitted after fixing one but ignoring the others: "The developer didn't even re-check whether all the bugs were fixed. He immediately sent it to QA."

A Manual QA with 2–5 years' experience described a broader pattern: "The dev created a feature entirely using AI. Probably tested superficially and threw the ticket into testing. After testing, 100500 inaccuracies and bugs were found."

The SDET in the sample framed the underlying dynamic without reference to any specific incident: "Some people don't look carefully at what was generated and then get unexpected problems. Others love to 'accept' the first working option AI gives, without trying to 'refine' it further."

The claim is not that developers are being careless. It is that the economics of review have changed. When AI can produce a plausible PR in minutes, the marginal review time available per PR has fallen — even as the marginal review time required per PR, per the defect anatomy in Section 4, has risen. QA is inheriting the delta.

5.4 The coverage gap

The third component of the testing gap is the one QA respondents describe most consistently in their own words: AI-authored code exercises the primary path well and misses everything adjacent to it.

Multiple respondents named the pattern directly. A Manual QA with under two years' experience: "AI often generates code that works for basic scenarios but misses non-standard cases." An Automation QA with 5–8 years' experience: "AI can implement the happy path well, but miss non-standard cases. After merge, UI elements started disappearing that had nothing to do with the new functionality." A Manual QA with 2–5 years' experience: "Because it doesn't understand the general context, it generates exactly what was written in the ticket. So you have to think about what should have been done but wasn't written in the ticket."

The pattern's operational implication is that AI-authored code shifts a specific type of work — negative-scenario design, boundary-value analysis, cross-flow verification — from the code-writing stage to the code-testing stage. Work that a careful developer would have handled while writing now has to be handled while testing.

The external record confirms that this expected shift has not been absorbed by AI-assisted testing tools. Mabl's 2024 State of Testing in DevOps report, based on 500+ development and QA leaders, found that 60% of teams are using AI in testing, but the top use case is test summarization rather than test generation or maintenance [25]. Test maintenance was the biggest single pain point identified in the same survey, with a 138% increase in teams ranking it as the top challenge year over year. Their 2025 edition finds AI adoption for testing continuing to climb — 55% of organizations now use AI tools for development and testing, rising to 70% among mature DevOps teams — but the coverage gap persists: test maintenance still consumes 20% of team time, and only 14% of organizations achieve 80%+ test coverage [36].

IDC's forecast for the same domain projects that generative AI tools will be capable of writing 70% of software tests by 2028 [26]. That is a forecast, not a measurement. The current measurement is Mabl's: AI is helping QA summarize test results, not extending test coverage.

The coverage gap, then, is not being closed by AI-assisted testing at the rate AI-assisted development is opening it. The delta between generation capacity and testing capacity is real, and it is currently being absorbed by human QA effort.

5.5 Changes QA has already made

The final component of this section is what QA has already changed in response.

DeviQA's survey asked whether respondents' testing approach changes when they know code was generated by AI, and if so, how. 74.2% of respondents answered yes. Their responses cluster around four common adaptations, presented below in the order they appear most frequently in the qualitative data.

Deeper edge-case scrutiny is the most consistent response. Respondents at every experience tier describe spending more time on boundary values, negative scenarios, and non-standard flows than they did before AI adoption. An Automation QA with 5–8 years' experience: "The approach became more focused on checking logic, edge cases, and integrations. I pay more attention to negative scenarios, boundary values, requirements compliance, and to whether the AI generated 'plausible' but factually incorrect code."

Broader regression scope is the second consistent response. Respondents describe running regression suites earlier and more often, in areas that would previously have been covered by smoke testing alone. A Manual QA with 5–8 years' experience: "Now I worry even more about the quality of testing. Bugs were appearing in places where bugs never happened before. Where I could get by with smoke testing and detailed feature testing, I now run regression."

Requirements re-verification is the third pattern. Because AI-generated code is described by multiple respondents as executing the ticket's literal text rather than the intent behind it, QA respondents describe checking implementations against the original acceptance criteria more explicitly. A Manual QA with 2–5 years' experience: "I check everything through AI first, then go through edge cases for each AC manually, compare with the design, and confirm I can reproduce the bugs it found — because often those bugs are not valid."

Adoption of AI as a QA-side tool is the fourth pattern. Respondents describe using AI to generate test plans, surface edge cases, review autotest structure, and analyze large data sets — a role reversal in which QA uses AI to keep pace with AI-authored change. A Manual QA with under two years' experience: "We use Claude Code for analyzing tickets, generating test cases including edge cases, and for better understanding of possible risks and scenarios worth checking." An Automation QA with 8+ years' experience described the current focus as "reviewing the outputs and improving the requests/prompts/skills" — that is, treating prompt discipline as a QA-owned practice.

None of these changes is a solution to the testing gap. Each is a locally rational adaptation to it. The volume and review gaps described in 5.2 and 5.3 are structural: they require changes in resourcing, tooling, or policy that individual QA engineers do not control. The coverage-gap adaptations described here are what remains within QA's own reach — and, on the evidence of the survey, most QA engineers are already making them.

6. Security: What QA Isn't Catching

6.1 What external research says about AI code security

The security research on AI-generated code is more extensive than the research on any other quality dimension, and its findings are consistent.

GitHub's Octoverse 2025 provides a real-world production signal at platform scale: Broken Access Control overtook Injection as the most common security alert on GitHub, appearing in over 151,000 repositories — a 172% year-over-year increase. GitHub attributes the shift specifically to AI-generated code scaffolds that produce functional-looking endpoints while omitting authentication checks, a pattern models learned from tutorial-style training data that prioritized 'getting it working' over security hardening [40].

The foundational study remains NYU Tandon's 2021 analysis, which constructed 89 security-sensitive coding scenarios mapped to MITRE CWE Top 25 weaknesses and generated 1,689 code samples using GitHub Copilot. Approximately 40% of the suggestions contained security vulnerabilities [19]. The study is now over three years old and predates the current generation of coding assistants; its specific 40% figure should be treated as aging. The pattern it identified, however, has been reinforced rather than contradicted by subsequent work.

Georgetown CSET's 2024 review of the same research area concluded that under experimental conditions, AI code generation models "frequently output insecure code" and that evaluating real-world risk in production settings remains an open research problem [20]. The CSET framing is important because it distinguishes between two claims that are frequently conflated: AI-generated code is measurably insecure in benchmarks, and AI-generated code is causing measurable breaches in production. The first is established. The second is not yet quantified with primary source evidence.

The most novel security research since 2024 concerns package hallucinations — the phenomenon in which AI coding assistants suggest imports for packages that do not exist. Spracklen et al. analyzed multiple coding LLMs and documented over 205,000 unique hallucinated package names across the tested models, with individual model hallucination rates ranging from 5.2% for some commercial models to 21.7% for some open-source models, and 43% of hallucinated names persisting across multiple re-runs [21]. The persistence rate is the operational finding — a hallucinated package name that recurs across sessions is a name attackers can register and weaponize.

A 2026 replication of this methodology on newer frontier models (Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, DeepSeek V3.2) found the inter-model hallucination range has compressed roughly an order of magnitude — from Spracklen's 5.2%–21.7% spread down to 4.62%–6.10% across all five models tested. The authors caution this reflects a shrinking range, not a retired threat: the study also identified 127 package names that all five models hallucinate identically, making them especially attractive slopsquatting targets since an attacker only needs to register one name to catch users of any of the five models [39].

The pattern has an established name and at least one documented incident. Security researcher Seth Michael Larson of the Python Software Foundation coined the term slopsquatting by analogy with typosquatting: registering the specific package names AI tools hallucinate, so that developers who accept the suggestion install attacker-controlled code [22]. The clearest public case is the Python package huggingface-cli, which AI coding assistants repeatedly suggested as a dependency before it existed. After the name was registered by researchers demonstrating the attack surface, it was downloaded more than 15,000 times [23][22].

The final external signal is the direction of security tooling adoption during the same period. Snyk's 2024 State of Open Source Security report, based on a sample of 453 technologists, found that adoption of Software Composition Analysis (SCA) and Static Application Security Testing (SAST) "barely exceeded 60%," container scanning sat at 35%, and — most notably — security tool adoption had dropped 11.3% and security training investment had dropped 17.8% compared with 2023 [24]. The AppSec safety net thinned during the exact period AI-generated code volume grew.

6.2 What QA actually catches

Ten percent of DeviQA's QA respondents named security vulnerabilities among their top defect categories in AI-generated code.

That figure is the finding, and it needs to be interpreted carefully. It is not evidence that AI-generated code is largely secure — the external research above is unambiguous that it is not. It is evidence that the QA function, as currently constituted in most organizations, is not the point in the pipeline where security defects are caught.

This is not a QA failure. It is a job-description observation. Manual QA and Automation QA roles are staffed and tooled to catch functional defects, regression, integration issues, and requirements mismatches — the categories that dominate the defect anatomy in Section 4.1. They are not staffed to run threat modeling, they are not tooled to perform SCA on generated code, and they are not the appropriate owners of CWE-level vulnerability detection. Those functions belong to AppSec.

9.7% respondents flagged security-adjacent risks in their free-text responses, and their observations are worth naming because they represent the boundary of what QA is positioned to notice. A Manual QA with 5–8 years' experience listed "logical errors in edge cases, dependency hallucinations, and ignored security best practices" as their top-three concerns — a striking response because it names slopsquatting in near-exact terms, from the QA seat. A Manual QA with 2–5 years' experience flagged unsanitized inputs as a category of defect that had appeared in AI-authored code and passed developer review. An Automation QA with 8+ years' experience listed "hallucinations" as the first-named risk without further qualification — a category encompassing both fabricated function signatures and fabricated dependencies.

The contrast with the developer-side sentiment is stark. Snyk's 2024 survey found that 77.9% of surveyed technologists (a developer-heavy sample) said they trust AI to enhance code security, and 84.1% said they audit AI-suggested open source packages with the same rigor as human-selected ones [24]. Whether that self-reported rigor matches practice is beyond the scope of this report. What can be said: developer confidence in AI-code security substantially exceeds QA confidence in AI-code quality, and neither population has direct visibility into the CWE-level defect rate the NYU and CSET research documents.

6.3 The dependency risk QA is structurally unable to see

The slopsquatting research introduces a category of risk that deserves separate framing, because it falls in the space between the developer's review and the QA's execution — and, in most current pipelines, is invisible to both.

A QA engineer running a functional test suite has no direct visibility into whether the packages a build depends on are the packages the developer intended to import. If a hallucinated package name has been registered by an attacker and installed via a normal pip install or npm install, and the malicious code inside it does not affect the specific behaviors the test suite exercises, the test suite will pass. The defect is real, the exploit path is real, and the QA function is not the layer that would detect it.

The persistence rate matters here. Spracklen et al. found that 43% of hallucinated package names recur across re-runs — meaning a name a model produces once is significantly more likely than chance to be produced again. That persistence is what converts an intermittent hallucination into an enumerable target for attackers, and it is what makes SCA and package-provenance controls a required — not optional — layer in AI-adopting organizations.

DeviQA's 2026 survey did not ask about dependency review practices, package provenance verification, or SBOM adoption at respondents' client organizations. Those questions belong on the 2027 instrument. What can be observed from the present survey is negative: no respondent described dependency review as part of their own workflow. This is the expected finding — dependency review is not typically a QA responsibility — but it means the survey cannot report on how AI-related dependency risk is being managed at the AppSec layer of respondents' client organizations. That gap is flagged explicitly in Section 8.

6.4 Downstream cost

The final external anchor for this section concerns the cost of software failures in aggregate — not attributed to AI-generated code, but establishing the cost floor into which AI-related security defects would feed if they reached production.

IBM's 2024 Cost of a Data Breach report found the global average breach cost reached USD 4.88 million, the largest year-over-year increase since the pandemic, with 70% of the 604 organizations studied reporting significant or moderate operational disruption from breaches [29]. Organizations using security AI and automation reduced average breach costs by USD 2.2 million and shortened the time to identify and contain breaches by nearly 100 days. In 2025 they show the first decline in five years — global average breach cost fell 9% to USD 4.44 million, driven largely by faster AI-assisted detection. Yet the report also found that 97% of organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policy at all — a direct echo of this report's own governance-gap finding, one layer up the stack [35].

The IBM figures do not isolate breaches caused by AI-generated code. As of mid-2026, the public record does not contain a widely cited enterprise breach postmortem that traces root cause explicitly to an AI-authored defect — a fact the CSET report notes and that this report accepts as a current limit of the evidence. What the IBM data does establish is the order of magnitude of the downstream cost of any security defect that does reach production. In an environment where AI-generated code is being produced at 98% higher PR volume, where 40% of samples in benchmark studies contain CWE-mapped vulnerabilities, and where AppSec tooling adoption is declining rather than rising, the expected value of a first well-documented AI-code-attributed breach is a function of time, not probability.

6.5 The role clarification this section is meant to force

The operational conclusion of Section 6 is narrow and directly stated.

QA is not the security net for AI-generated code. It was not designed to be. It is not staffed to be. The 10% figure in this survey does not indicate that AI-generated code is secure; it indicates that the QA function is doing the job it was configured to do.

Any organization that reads QA's low security-defect intake as evidence that AI-generated code is safe to ship has misread the signal. The correct reading is that AI adoption at the code-generation layer requires a matching investment at the AppSec layer — SCA on generated dependencies, SAST on generated code, provenance verification on suggested packages, and threat modeling on AI-authored features. None of these functions belongs to QA. All of them are more urgent in an AI-adopting organization than they were before AI adoption.

The report returns to this point in Section 8, as one of the four operational recommendations grounded in the survey data. It is placed in this section, before Section 7's treatment of the review process, because the review process is where the boundary between developer, QA, and AppSec responsibility is currently blurred — and the security case is the clearest example of why that boundary needs to be drawn explicitly.

7. Review, Governance, and Team Dynamics

7.1 Rubber-stamp risk at the merge boundary

The review process is the layer at which developer speed and QA quality meet. The external evidence is that it has cracked under AI-authored volume.

LinearB's 2026 dataset shows pull request review time up 91% in AI-adopting teams, with AI-generated PRs waiting 4.6× longer for review pickup and reviewed 2× faster once picked up [9][10]. GitHub's own platform telemetry corroborates the review-attention decline from an independent angle: Octoverse 2025 found that while pull requests merged rose 29% year-over-year, comments left on commits fell 27% over the same period — more code moving through the pipeline with measurably less human commentary attached to it [40]. The 32.7% AI PR acceptance rate versus 84.4% for human-authored PRs suggests reviewers are not rubber-stamping in aggregate — but the qualitative pattern in DeviQA's survey shows the reviews that do pass through are catching less than they used to.

The SDET in the sample described the pattern without reference to a specific incident: "Some people don't look carefully at what was generated and then get unexpected problems. Others love to accept the first working option AI gives, without trying to refine it further." An Automation QA with 8+ years' experience gave the concrete version: AI-generated code created a type name that already existed elsewhere in the application, review did not catch the collision, and real logic broke when execution hit the shadowed type.

The economics have shifted. When plausible PRs can be produced in minutes, the marginal review attention per line falls even as the marginal review attention required per line — for the reasons documented in Sections 4 and 5 — rises. The delta migrates downstream to QA.

7.2 The AI-ticket, AI-code, AI-test loop

A distinct 2026 pattern surfaces in the free-text responses: the same underlying LLM is now writing the ticket, writing the code, generating the tests, and being asked to review the PR. Every gate in the pipeline shares an author.

An Automation QA with 8+ years' experience described their team's setup directly: "We synced Git and Jira with Claude Code and it tries to fix what's described in the ticket. The tickets are also generated through Claude. Works well on minor bugs." A Manual QA with 5–8 years' experience described the readability cost: "Now everyone even writes tickets through Claude, and these descriptions are just impossible to read… Sometimes I have to use AI to understand what ticket the AI wrote."

The pattern is not, on its face, wrong. Multiple respondents described the same loop producing net-positive outcomes on minor issues, and Section 4.5 documented cases where AI-generated code helped QA rather than hurt it. What the pattern does eliminate is independent verification. When ticket, code, and test share an author, the disagreements between authors that traditionally surfaced defects at the specification-to-implementation boundary no longer exist. QA is one of the few remaining independent verifiers in the loop.

7.3 The governance gap

The final component of this section is the layer beneath the review process: the formal policy — or absence of it — that would define how AI-authored code is labeled, reviewed, and audited.

The external record on governance is short. JetBrains reports that nearly 80% of companies either allow third-party AI tools or have no formal restrictions [7]. Stack Overflow reports that 73% of developers are unsure whether their company has an AI policy [4]. The 2026 Application Security Standards AI-Generated Code Verification Framework — an early attempt to map controls for AI-authored code to PCI DSS v4.0.1, OWASP ASVS, and SOC 2 — exists precisely because the governance layer has lagged the tooling layer [27].

The operational implication is straightforward. Every recommendation in Section 8 depends on the ability of an organization to distinguish AI-authored change from human-authored change at the moment of review. In most current pipelines, that distinction is not being made. Adoption arrived first. Policy has not caught up. The QA function is one of the first places the consequences land — which is where Section 8 begins.

8. What This Means for QA (and Everyone Downstream)

The preceding sections describe the state of the system. This section describes what the survey data supports as operational conclusions — no vendor recommendations, no prescriptions the data does not warrant, and explicit acknowledgment where the evidence stops.

8.1 The hiring gap nobody is quantifying

LinearB reports 98% more PRs merged in AI-adopting teams [9][10]. DeviQA's survey reports 52% of QA respondents seeing more bugs and 58% seeing more testing work. No respondent, across 300 free-text responses that described numerous operational changes, described additional QA headcount being added in response.

The ratio of QA to development capacity is not holding. The external record does not yet quantify how far it has slipped — the most recent U.S. Bureau of Labor Statistics occupational data for Software Quality Assurance Analysts and Testers is from May 2022 and pre-dates the current AI adoption curve [30], and no public primary source segments QA versus developer headcount trends by AI adoption. The 2027 edition should ask this question directly. In the meantime, engineering leadership should treat the QA-to-dev ratio as a metric that requires explicit management, not a static input.

8.2 Testing depth is a leadership decision, not a QA decision

Section 5.5 documented what QA has already changed: deeper edge-case scrutiny, broader regression scope, requirements re-verification, and adoption of AI as a QA-side tool. These are the adaptations available within an individual QA engineer's discretion. They are not solutions to the volume and review gaps, which are structural.

The macro-level version of this dynamic is documented in DORA's 2024 report, which found that AI adoption improves individual productivity and flow but negatively impacts delivery stability and throughput at the team level [16]. Individual effort — DORA's "flow" — and team-level cost are not incompatible findings. They describe the same phenomenon from different heights.

The next lever is not QA's to pull. Whether AI-authored PRs receive a distinct review process, whether regression suites are expanded in proportion to code volume, and whether QA capacity scales with development velocity are engineering leadership decisions. Reading the survey as evidence that QA needs to work harder misreads it. QA is already working harder. The finding is that individual effort is not a substitute for structural resourcing.

8.3 Reviewers, not writers, are the AI-era bottleneck

The LinearB data on review time — up 91%, with AI PRs waiting 4.6× longer before reviewer pickup [9][10] — and the DeviQA qualitative data on rubber-stamped merges point at the same layer. Tooling investment aimed at making writing faster has outpaced tooling investment aimed at making review more thorough.

Mabl's 2024 State of Testing in DevOps report shows the same imbalance from the test-tooling side: 60% of teams use AI in testing, but the top use case is test summarization rather than test generation or maintenance, and test maintenance registered a 138% year-over-year increase as the top pain point [25]. AI tooling is helping teams summarize the review and test artifacts they already produce faster; it is not yet helping them produce more of them.

The implication is not that AI-assisted review tools should replace human reviewers. It is that the review process needs the same class of infrastructure attention that the writing process received in 2023 and 2024. Pull-request review is currently the least-instrumented step in the AI-adopting SDLC, and it is the step where the survey's evidence indicates defects are escaping.

8.4 Governance to close the visibility gap

Nineteen percent of the QA respondents in this survey could not identify whether the code they test is AI-authored. That is the minimum-viable governance failure. The external record indicates the same pattern one seat upstream: nearly 80% of companies either allow third-party AI tools or have no formal restrictions [7], and 73% of developers are unsure whether their company has an AI policy [4].

Before any organization implements the Application Security Standards AI-Generated Code Verification Framework [27], updates its SOC 2 controls for AI-authored change, or aligns to the EU AI Act's provisions on general-purpose systems [28], it needs to be able to answer a simpler question at the PR level: was this written with AI or without.

PR-level authorship metadata is not a technical challenge. It is a policy choice that most organizations have not yet made. Every downstream governance recommendation depends on it.

Conclusion — The Second Ledger

Every serious claim about AI-generated code productivity now needs a matching claim about AI-generated code quality. Reports on the first without reports on the second describe half of the ledger.

This report has attempted to describe the second half from the vantage point of the QA function that inherits it: 65% of QA respondents work with actively AI-adopting dev teams; 52% see more bugs; 58% see more testing work; zero respondents fully trust the code they test. The defect anatomy is dominated by logic errors, edge cases, duplication, and regression amplification. The security exposure is real but sits with AppSec, not QA. The review process has cracked under volume. The governance layer has not yet caught up.

None of these findings refutes the developer-side productivity research. The 98% PR merge lift reported by LinearB is real [9]. The 26% weekly PR increase in the Microsoft/Accenture/MIT field experiment is real [11][12]. Developer satisfaction with AI tools, documented across Stack Overflow, JetBrains, and DORA [1][16], is real. What this report adds is that these numbers do not describe the full state of the system in which they occur. They describe the code that gets written. The code that survives is measured downstream — by the QA function surveyed here.

The second ledger is not optional. It is the other half of the same ledger.

Methodology

About the survey

DeviQA's State of AI-Generated Code: The QA and Testing Gap 2026 is based on a proprietary internal survey of 300 QA practitioners, fielded in 2026.

Sample composition

• 40% Automation QA

• 40% Manual QA

• 20% SDET

Experience distribution (weighted toward senior practitioners)

• Under 2 years: 16%

• 2–5 years: 32%

• 5–8 years: 26%

• 8+ years: 26%

Fielding. The instrument was distributed through DeviQA's internal QA network and closed once 300 responses were collected. Participation was voluntary. No respondent received compensation. Respondents were told the results would be published in aggregate.

What the survey asked

The instrument covered 12 questions across four areas:

How external research is used

Every external statistic in this report is cited to its primary source or, where the primary source is behind a gated form, to the most credible secondary summary available. The full source list appears at the end of the report.

What this report does not claim

• This is not a population-level study of the QA profession. 300 respondents does not license claims about QA engineers worldwide. Where the sample-level finding converges with much larger external datasets, we note the convergence. Where it diverges, we note the divergence.

• This report does not attribute individual case studies to named client organizations. All incident descriptions are anonymized by design of the instrument.

• This report does not measure escaped defect rates before and after AI adoption. The instrument captured perceived change in bug volume, not measured change. Section 8 flags this as a 2027 priority.

Data gaps acknowledged

Four measurement areas the 2026 instrument did not cover, and which the 2027 edition will:

Sources