The Info-Tech Research Group published a study on July 20, 2026 — 578 responses from engineering and product leaders actively using AI across the software development lifecycle. Two numbers sit side by side in the findings and contradict each other in a way the report does not resolve: 94% of respondents report productivity gains from AI. 67% of respondents agree that AI-generated code requires more testing than human-generated code.
Both numbers come from the same population. The people claiming the gains are largely the same people acknowledging the extra testing burden. Those two things can coexist — but only if the testing time is not being subtracted from the productivity estimate. And it isn't.
Where the Productivity Measurement Happens
When a developer reports that AI made them more productive, they are almost always describing the code generation phase. Claude produced a working implementation in 30 seconds. Copilot autocompleted the boilerplate I would have spent 20 minutes on. The generation is fast, and the speed is visible in the moment it happens. It registers as time saved.
What does not register the same way: the time spent verifying that code before it ships. The time writing tests that should have been easier because you wrote the code, but are harder because you did not write this code — you generated it and are now trying to understand what it actually does. The extra review cycle the senior engineer puts on AI-heavy PRs because they have learned to distrust the first read.
SmartBear surveyed 273 software leaders and found that 70% say application quality has already degraded as AI accelerates development. Separately, senior engineers in 2026 report spending 20 to 35% more time on code review when junior developers are using AI assistants heavily. Test suite maintenance is now a bigger burden than writing code for 70% of respondents in the same survey — a complete inversion of how software delivery economics used to work.
The productivity claim is real. The testing burden is real. They measure different points in the same workflow.
Why the Accounting Error Is Systematic
This is not individual self-deception. The structure of how AI assistance works makes the accounting error almost guaranteed.
When you use AI to generate code, the speed signal is synchronous. You ask, you receive, you feel fast. When you test that code — finding that it handles the edge cases you specified but not the ones you forgot to specify, that it calls an API the way you described but in a way that fails at scale, that it passes the test you wrote but for reasons that do not generalize — the slowdown is distributed across days and attributed to the normal difficulty of software rather than to the thing that created the need for extra validation.
The code churn data bears this out. Faros tracked 22,000 developers over two years and found that code churn — lines deleted from merged PRs — increased 861% as teams moved to high AI adoption. The code shipped. It passed review. Then it was removed. The time that removal cost was never credited against the productivity gain from writing the original code fast.
When 67% of developers acknowledge their AI-generated code needs more testing, they are describing a cost that is present in their actual workflow. But that cost is not in the numerator of the productivity calculation they reported in the previous question.
The Phase Problem
Software delivery has a generation phase and a validation phase. AI compresses the generation phase significantly. It does almost nothing for the validation phase — and according to the evidence from multiple independent datasets, it likely expands it.
The Info-Tech study found that 84% of respondents use AI in the Build phase, meaning design, development, and testing. That sounds comprehensive. But the specific breakdown matters: AI is used to write code at a dramatically higher rate than it is used to write tests, and the tests that exist for AI-generated code are frequently the tests the developer wrote before they understood what the code was actually doing. Testing after the fact requires understanding the implementation's actual behavior, not its intended behavior.
The phrase "AI-generated code fails differently than human-written code" appears in multiple QA research reviews this year. Traditional testing processes miss AI failure patterns because those processes were designed around the failure modes of code written incrementally by someone who understood the system deeply. AI-generated code fails at edge cases that were not in the prompt, at integration points that were not described, and at scale characteristics the generating model had no visibility into. Finding those failures requires more testing, not less.
What This Means for the 94% Number
The 94% figure is not wrong. Developers are genuinely faster at the part they measured. The question is which part of the workflow that speed gain belongs to and whether it holds when you account for everything downstream of generation.
If you write code twice as fast but spend 40% more time testing it before it can ship, the net gain is smaller than twice as fast. If you ship faster and the code is removed at a higher rate three weeks later because it was not robust — Faros's 861% churn increase — the throughput gain at generation time did not translate to delivery velocity at the project level.
None of this is a reason to stop using AI coding tools. A genuine 1.4x value increase, which is what METR's May 2026 survey found when asking about contribution rather than speed, is real and worth having. The problem is that 94% productivity gains and 1.4x actual value are not the same number, and the difference mostly lives in the testing and validation work that AI-heavy workflows create more of.
The Measurement Gap
The structural issue is that generation speed is easy to measure and feel, while validation cost is diffuse and invisible. It shows up as "we had a rough sprint," as "this ended up being more complex than expected," as "we needed another review cycle." It does not show up as "the AI productivity gain from three weeks ago came with a testing overhead we did not account for."
At xeve, we track time at the application level — including which tools developers are actually in, how much time lands in IDE sessions versus in test running, in terminals, in PR review. The pattern that shows up in high-AI-usage periods is not just more code commits. It is also more time in testing infrastructure, more review cycles visible in the data, more late-sprint compression as validation work that was deferred accumulates.
You cannot fix the accounting error with better feelings about how productive you are. You fix it by tracking the whole workflow — generation, review, testing, rework — and computing the gain on the full cycle rather than the first step.
The 94% who say AI makes them more productive and the 67% who say the code needs more testing are not describing a contradiction. They are describing different parts of the same process. The productivity estimate is accurate for one of those parts. The question is whether it was supposed to cover both.