This is the standout software-quality problem of 2026, and it cuts across SaaS, fintech, healthtech, and e-commerce. AI coding assistants have hit critical mass. A SmartBear survey of 273 software testing and quality decision-makers — fielded January 2026 and released March 18, 2026, with 67% of respondents at director level or above and most at midsize-to-enterprise software/SaaS companies — found that 93% have adopted AI coding tools and 40% use AI to generate more than 40% of their code, with 60% expecting to cross that 40% threshold within 12 months. Tricentis CEO Kevin Thompson similarly noted that over 40% of code written in the prior year was AI-generated.

The core problem is that testing has not scaled with generation. The same SmartBear study found 70% of software experts say application quality has already degraded as AI accelerates development, and 60% already experienced quality issues in the past year because code creation outpaced testing capacity. 65% are concerned about under-investment in application-level testing versus code-level testing, and a similar share worry leadership doesn't recognize the risk.

"The speed of software development, driven by AI, is outpacing the ability of teams to test the resulting applications. It only takes one failure that can tank a customer experience and destroy brand good will." — Dan Faulkner, CEO, SmartBear

Why AI-generated code is measurably worse

Four independent studies from 2025–2026 converge on the same conclusion: AI-generated code is, on multiple measurable dimensions, lower quality than human-written code. Not unusable. Not always dangerous. But meaningfully worse — and the gap widens the more the team relies on it.

1. Defect density rises 1.7x–2.7x

2.7×
More defects in AI-generated code than in human-written code. ShiftAsia's 2025–2026 analysis reports defect-density multipliers ranging from 1.7× to 2.7×, depending on language and project complexity. Source: ShiftAsia AI Code Quality Analysis 2025–2026

2. Duplication and churn explode

GitClear's analysis of 211 million changed lines of code (2020–2024) found a pattern that should worry every CTO:

  • Duplicated code blocks rose roughly eightfold in 2024.
  • Refactoring ("moved" / reused lines) collapsed from about 25% of changes in 2021 to under 10% in 2024.
  • 2024 was the first year copy-pasted code exceeded refactored code — a leading indicator of accumulating technical debt.

Cloned code is correlated with 15–50% higher defect rates in subsequent maintenance cycles. Translation: the productivity win today is the maintenance bill tomorrow.

3. Security degrades the more you "improve" the code

An IEEE-ISTAS 2025 peer-reviewed study (researchers from the University of San Francisco, the Vector Institute, and UMass Boston) tested 400 AI-generated samples across 40 refinement rounds. The result:

+37.6%
Increase in critical vulnerabilities after just five rounds of asking the model to "improve" its own code. The pattern held even when the model was explicitly asked to improve security. Vulnerabilities rose from 2.1 per sample in early iterations to 6.2 by iterations 8–10. Source: Shukla, Joshi & Syed, IEEE-ISTAS 2025

The finding directly contradicts the common developer assumption that iterating with an AI makes code safer. It often makes it worse.

4. Untested code is shipping to production at scale

The Tricentis 2026 Quality Transformation Report — a Censuswide survey of 2,501 respondents fielded April 2026 — found 60% of organisations admit their application developers regularly ship untested code into production. And in a striking shift from 2025, the cause is no longer "accidental quality slips" — it's intentional:

  • 32% cite leadership pressure to prioritise speed over quality.
  • 30% say the sheer volume of AI-generated code has become too overwhelming to test fully.

Financial services (64%), retail (63%), and energy/utilities (58%) are the most affected sectors. As Tricentis VP David Colwell put it: "the volume of code that has not been tested is increasing."

Testing AI-driven features is itself a new discipline

Even if you solve the AI-code-quality problem, there's a second-order one: testing the AI features you ship — LLM-backed chatbots, autonomous agents, GenAI search, recommendation models. Their non-deterministic behaviour, hallucinations, and bias make traditional pass/fail testing insufficient.

The Capgemini / OpenText World Quality Report 2025-26 surveyed 2,000+ senior executives across 22 countries and 10 sectors. The new top barriers are:

  • Data-privacy risks (67%) — training and test data both fall under GDPR, NIS2, and increasingly DORA Act scope.
  • Integration complexity (64%) — agentic systems plug into half a dozen internal APIs and external models.
  • Hallucination and reliability concerns (60%) — there's no test framework on the market that proves "this LLM will never lie about your bereavement-fare policy."

And the kicker: only 15% of organisations have scaled GenAI in quality engineering enterprise-wide despite roughly 90% pursuing it. We have a generation of engineering leaders who believe they're ahead on AI testing because they're doing something — when by industry standard, they're not.

Until 2024, the cost of weak AI testing was theoretical. In 2025 it became a line item on the income statement. In 2026 it became case law.

One in five organisations are losing seven figures a year

$1M+
20% of organisations lose more than $1 million annually to poor software quality, per Tricentis 2026 — driven primarily by security and compliance failures (30%) and technical debt / rework (28%). Another 45% estimate losses between $500,000 and $1 million. Source: Tricentis 2026 Quality Transformation Report

Flaky tests are a quiet but real drag

Google's own engineering-productivity research found that roughly 16% of its test inventory (about 1 in 7 tests) exhibits flaky behaviour, costing over 2% of total coding time. For a 200-engineer team, that's the equivalent of 4 full-time engineers doing nothing but staring at red builds.

Companies now own their AI's mistakes — legally

In Moffatt v. Air Canada (2024 BCCRT 149), a British Columbia tribunal held Air Canada responsible for its chatbot's incorrect answer about bereavement fares. The airline argued that the chatbot was "a separate legal entity". The tribunal rejected that — and in doing so established the legal principle that companies own what their AI says and does.

Less than 18 months later, in September 2025, the FTC issued Section 6(b) orders to seven companies operating consumer-facing AI chatbots (Meta, OpenAI, Alphabet/Google, Character.AI, Snap, X.AI, and Instagram). The orders cover advertising claims, safety, monetisation, and complaint handling. It is the clearest US signal to date that regulators will treat AI failures as enforceable consumer-protection issues.

In the EU, the picture is even sharper: the AI Act, NIS2 Directive, and DORA Act all impose obligations that effectively require demonstrable verification of AI-driven systems in production. "We tested it manually before launch" will not be a defence.

How to close the verification gap: a 5-layer framework

We've worked with engineering teams across DACH and the US in fintech, healthtech, SaaS, and e-commerce. The pattern in teams that do close the gap is consistent. They run all five of the layers below — and the ones that are losing run only two or three.

1

Code-level verification (the table stakes)

SAST, dependency scanning (SCA), secrets scanning, and unit-test coverage thresholds on every PR. This is necessary but not sufficient — it's where most teams stop.

2

Application-level verification (the missing layer)

Contract testing, integration tests with real dependencies, and end-to-end tests against production-like environments. The SmartBear survey found 65% of teams are under-invested here — and it's the layer where AI-generated bugs hide longest.

3

AI-feature evaluation (the new discipline)

Eval harnesses, golden datasets, hallucination detectors, bias and toxicity checks, and adversarial red-teaming for any LLM-backed feature. Treat your prompts and your eval set as production artefacts, version-controlled and reviewed.

4

Continuous risk monitoring (the visibility layer)

Real-time defect density, test pass-rate trends, flake rate, DORA metrics (deployment frequency, lead time, MTTR, change failure rate), and AI-specific telemetry (model drift, prompt-injection attempts, latency p99). If your leadership can't see these on a single dashboard, the verification gap is invisible until it bites.

5

Compliance and audit readiness (the legal layer)

Documented test plans, audit trails, evidence of human-in-the-loop review, and traceability from requirement → test → defect → fix. This is what survives an audit from regulators or a discovery request from plaintiff's counsel after a Moffatt-style incident.

What this means for engineering leaders

If you are a CTO, VP of Engineering, or QA lead reading this, the practical question is: which of the five layers above is your team actually doing systematically? Not which ones do you have a tool for. Which ones produce evidence you'd hand to an auditor tomorrow morning?

In our experience the answer is usually layers 1 and 2 — partially. Layer 3 (AI evaluation) is where the biggest gap sits today. Layer 4 (visibility) is where the second-biggest gap sits. Layer 5 (compliance) is where leadership realises, six months too late, that they should have started earlier.

The teams winning in 2026 aren't the ones generating the most AI code. They're the ones who have built the verification scaffolding to make that code shippable.