AI made code cheap. Confidence in code did not get cheaper. When development output climbs and test capacity stays flat, the backlog quietly decides what ships tested.
Most organizations did not fund a QA initiative. They funded faster development, and it worked. AI coding assistants are producing more pull requests, more features, and more releases than the teams that adopted them expected. The stage nobody put on the roadmap is what happens to all of that output at the test gate, where design, execution, and maintenance still run at last year's speed.
Every gain on the left side of the delivery pipeline stacks up as a queue on the right, and the queue starts deciding which work gets a real test pass and which gets a smoke test and a release date.
The throughput problem, measured
Forrester's framing is the cleanest statement of the problem. AI applied to one stage of the software lifecycle produces a local gain that the unchanged stages absorb. Coding may improve 30 to 40 percent with AI assistants, but if planning, testing, and release remain manual, overall team productivity often increases by less than 10 percent.[^1]
It is Amdahl's law applied to a delivery pipeline. Speed up the part that was already fast and the slowest part still sets the pace. In most organizations the slowest part is now verification.
Faros AI measured the same thing from telemetry rather than survey. Across 10,000 developers in 1,255 teams, those using AI completed 21 percent more tasks and merged 98 percent more pull requests, but pull request review time rose 91 percent, average PR size grew 154 percent, bugs per developer rose 9 percent, and at the company level there was no significant correlation between AI adoption and improved delivery metrics.[^2]
Individual output surged. Organizational outcomes did not move. The report names downstream review and testing as the constraint that neutralized the gains.
SmartBear surveyed 273 software leaders, two thirds of them at director level or above. Ninety-three percent had adopted AI coding tools. Seventy percent said application quality had already degraded as AI accelerated development. Sixty percent had hit quality problems in the past year specifically because development outpaced testing, and 68 percent expected faster AI development to create testing bottlenecks. Ninety-two percent still test manually.[^3]
That last figure is the one to hold onto. The gap is not a future risk for a few early adopters. It is the current state for most teams that adopted AI coding tools, and most of them are trying to close it by hand.
What the queue decides
A test backlog is not a neutral waiting room. When more changes arrive than the team can verify, someone decides which ones get a full pass, which get a smoke test, and which ride the release on the strength of a green unit test badge. In practice that decision is made by whoever is nearest the release train, under time pressure, with no record of what was skipped.
The organization ends up with a quality posture it never chose and cannot describe, which is exactly the condition an auditor, a customer, or an incident review will eventually ask about.
AI is an amplifier
Google's DORA program is the delivery benchmark most engineering organizations already use on themselves. Its most recent report found that higher AI adoption is associated with higher software delivery throughput and higher software delivery instability at the same time, and states plainly that AI adoption "not only fails to fix instability, it is currently associated with increasing instability."[^4]
DORA's own explanation is that AI acts as an amplifier and a mirror of the organization that adopts it. If change failure rate has crept up since the coding assistants arrived, that is the mechanism. Instability under AI adoption is not evidence that the assistants are bad. It is evidence that the verification step was already thin, and that AI has made the thinness visible by raising the volume passing through it.
The fix is not to slow development down. It is to give verification the same acceleration development got.
Adoption is broad, scale is rare
The World Quality Report surveyed over 2,000 senior executives across 23 countries. Eighty-nine percent of organizations are piloting or deploying generative AI in quality engineering, yet only 15 percent have achieved enterprise-wide implementation. Forty-three percent describe their use as experimental. Reported productivity gains average 19 percent, and a third of respondents saw minimal gains.[^5]
The top barriers to scaling are data privacy risk (67 percent), integration complexity (64 percent), and hallucination or reliability concerns (60 percent). Half of organizations say they lack the AI and machine learning expertise to proceed.
The pattern is a pilot that works and a program that does not follow. The 15 percent who industrialized did not buy a platform first. They proved one workflow, measured it, and expanded from evidence.
The cost of a defect moved
The famous curve showing defect cost rising exponentially through the lifecycle is not new. What changed is the arithmetic in front of it: more code per week, the same test capacity, and therefore more defects arriving at the stages where each one costs the incident, the rollback, the customer conversation, and the support queue.
The most widely shared version of this curve, attributed to the IBM Systems Sciences Institute with 100x at the end, has no traceable study behind it. Laurent Bossavit ran the citation chain back to a 1987 textbook citing IBM internal course notes. Nobody has produced the underlying data.[^6]
The version that holds up is Barry Boehm's 1976 data as reported in NIST's economic study of software testing. Finding and fixing a problem after delivery is often 100 times more expensive than during requirements and design, with the honest caveat that small, non-critical systems sit closer to 5 to 1.[^7][^8]
The 2002 NIST study estimated that inadequate testing infrastructure cost the US economy $59.5 billion a year, with $22.2 billion of that being avoidable. CISQ put the cost of poor software quality in the US at $2.41 trillion in 2022, with about $1.52 trillion of it being accumulated technical debt. ITIC found that over 90 percent of mid-size and large enterprises put the cost of downtime at over $300,000 per hour, with 41 percent putting it at $1 million to over $5 million.[^9][^10]
None of these figures is about AI. That is the point. The cost of a defect that reaches production has been documented for decades. What changed is the volume reaching its far end.
Why existing automation is the first casualty
Automation built for a codebase that changed at human speed does not survive a codebase that changes at assistant speed. AI-generated code changes more surfaces per week: more UI, more API contracts, more data shapes. Every one of those changes is a chance for an existing script to break, so the suite breaks more often, and the people who should be designing tests for new work spend the week repairing tests for old work.
The suite the team is proud of becomes the maintenance tax that eats the capacity they needed.
Rainforest QA surveyed over 112 startup teams on open-source frameworks and found 60 percent spending at least 11 to 20 hours a week on test maintenance, and about a quarter spending 31 hours or more, which the authors describe as approaching a full-time hire.[^11] That was measured before AI coding assistants multiplied the rate of change. The maintenance tax scales with churn, and churn just went up.
There is a second-order effect that rarely makes it into the budget conversation. When maintenance consumes the automation team, coverage for new work is the first thing dropped, so the newest and least understood code, which is now the AI-generated code, is the least tested. The suite keeps reporting green because it is testing last year's application. The organization reads that green as confidence.
Sequencing QA for later is the expensive choice
The AI development program has a sponsor, a budget, and a deadline. QA modernization has none of those, so it gets sequenced for after the rollout. The arithmetic of later is what the cost curve describes: every defect that clears the gate in the interval is paid for at the far end, and the automation suite the faster codebase has already broken must be rebuilt on top.
Doing verification alongside the development program costs a fraction of that, and it makes the development program look better in its own numbers, because realized throughput is whatever ships tested, not whatever the assistant produced.
What matching test velocity to dev velocity looks like
Move quality to where the code is written now, and let AI carry the parts of testing that scale with volume. It is not "automate QA." Most teams already did. It is a different placement of the work.
At an FDA-regulated digital health device maker, release evidence preparation dropped from roughly 80 hours per cycle to about 6, and audit packages that used to take days now assemble in minutes. One QA tester spending one to two hours a week keeps pace with roughly a week of development output.
The same approach has supported release testing at a global open-knowledge platform. That is what the gap looks like when it closes: not fewer testers, but testers whose week is spent on judgment instead of repair.
Five questions for your own team
Take one user story and its test cases. Put them next to the code that implements the story. Compare how long the code took to write against how long the tests took to design, run, and maintain. That ratio is your velocity gap, and it is the number worth putting in front of whoever sponsored the AI development program.
Here are five questions to ask:
- How many hours went to repairing existing tests last quarter, versus adding coverage for new work?
- What share of AI-assisted code changes gets meaningful verification before production, and who decides which ones do not?
- Has change failure rate or incident volume moved since the coding assistants arrived, and does anyone own that number?
- If an auditor or a key customer asked for release evidence tomorrow, how many days would assembling it take?
- If your best QA mind got 30 hours a week back, where would that judgment be pointed?
The organizations that industrialized AI in quality engineering did it one proven workflow at a time, measured, then expanded.
Get the full picture
This post adapts findings from our white paper on the AI Velocity Gap. The full version includes detailed field results, implementation patterns, and the complete adoption path from one proven workflow to enterprise-wide scale.
Download the free white paper at /resources/ai-velocity-gap (or the short link: /velocity-gap).
If you want to see what the gap looks like in your own pipeline, we run a 30-minute teardown: bring one user story and its test cases, leave with a written read on where testing falls behind, then a proof run on two of your own cases. Email ai@proticom.com if that would be useful.
Sources
[^1]: Forrester, Agentic Software Development Takes The Lead: From Code Assistants To Orchestrated SDLC Agents, Forrester blog, 2026.
[^2]: Faros AI, The AI Productivity Paradox Report, 10,000+ developers across 1,255 teams, July 2025.
[^3]: SmartBear, Closing the AI Software Quality Gap, survey of 273 software leaders (67% director level or above), March 2026.
[^4]: Google Cloud DORA, State of AI-assisted Software Development, 2025.
[^5]: Capgemini, Sogeti, and OpenText, World Quality Report 2025-26, survey of 2,000+ senior executives across 23 countries, November 2025.
[^6]: Bossavit, L., The Leprechauns of Software Engineering, and The Register, July 2021, on the untraceable IBM Systems Sciences Institute cost curve.
[^7]: Tassey, G., The Economic Impacts of Inadequate Infrastructure for Software Testing, NIST Planning Report 02-3, 2002.
[^8]: Boehm, B. and Basili, V., Software Defect Reduction Top 10 List, IEEE Computer, January 2001.
[^9]: CISQ, The Cost of Poor Software Quality in the US: A 2022 Report.
[^10]: ITIC, 2024 Hourly Cost of Downtime Survey, 1,000+ firms.
[^11]: Rainforest QA, The unexpected costs of test automation maintenance and how to avoid them [Data], rainforestqa.com/blog/test-automation-maintenance, survey of over 112 startup software teams in the US and Canada.