The same week Info-Tech Research Group published a survey finding that 94% of developers report AI productivity gains, GitClear released the most comprehensive code quality analysis of the AI coding era. The two reports measure different things and reach conclusions that are hard to hold in your head at the same time.
The Info-Tech number is self-reported and survey-based. It asks developers how they feel. The GitClear number is behavioral, drawn from 623 million code changes across thousands of repositories tracked from 2023 through mid-2026. It asks what actually happened to output.
The GitClear finding: daily AI users out-produce non-users by approximately 4x on raw output metrics. But when you compare those same developers to their own output a year earlier — before heavy AI adoption — the real gain is around 12%. GitClear CEO Bill Harding is explicit that even that 12% carries selection bias: the developers who adopted AI tools earliest and most aggressively were disproportionately the most productive developers before AI.
The 4x and the 12% are answering different questions. Only one of them tells you what AI is likely doing to your velocity specifically.
Why the 4x Number Is Real and Also Wrong
The between-group comparison — heavy AI users produce 4x more than non-users — is based on accurate data. It is also measuring the wrong thing if you want to know what AI tools did to any individual's output.
The developers who adopted AI daily and earliest are not a random sample. Early heavy adoption requires specific things: comfort with workflow disruption, time to iterate through prompting patterns, and enough baseline productivity to absorb a period of lower output during the learning curve. This describes, roughly, a senior developer with discretionary time and high baseline output. The group that adopted AI daily was already producing more than average before AI existed.
When you compare this self-selected group to the average non-user — who may include developers at very different skill levels, in very different codebases — you are measuring a population difference, not a tool effect. The output gap existed, in part, before these developers touched AI tools.
The 12% within-group comparison controls for that. It asks: what happened to the same developer's output before and after? The answer is smaller, noisier, and much more honest about what you're actually buying when you subscribe to Cursor or route through Claude Code for the majority of your work.
Harding's point about selection bias within the 12% is worth taking seriously. If the developers who saw the biggest pre-to-post gains were also the ones most capable of using the tools effectively, the real average gain for a developer adopting AI at median skill level is probably lower still. Nobody knows the actual number with confidence. What GitClear established is that the headline number — the 4x — is not it.
What the Code Actually Looks Like
The 12% velocity gain would be easier to accept if the quality signals were moving the other direction. They are not.
Duplicated code blocks climbed from 40.3 per million changed lines in 2023 to 73.0 in the first half of 2026 — an 81% increase and the highest level in GitClear's dataset. Copy-pasted code rose from 9.4% of new code in 2022 to 15.7% in 2026. The refactoring rate — code being moved and consolidated rather than just added — fell to 3.8%, down from around 21% earlier in the decade. Cross-file function calls, the signal of code reuse across modules, are down 35%. Two-week code churn is up 15%.
These numbers describe a specific trade-off. Output is increasing by 12% per developer. Code structure is deteriorating significantly faster. More code is being written; less of it is being organized into reusable, maintainable form.
This is not irrational in the short term. 12% faster delivery is 12% faster, and the structural costs — harder-to-understand modules, hidden duplication, accumulated debt in places nobody is looking — are deferred costs. They don't show up in next week's sprint. They show up when the team tries to build something adjacent to what the AI wrote six months ago and finds the structure doesn't accommodate it cleanly.
GitClear's earlier analysis found that AI-generated code runs about 12% higher long-term bug rates than human-written code reviewed to the same standard. This isn't usually because the AI's initial output was wrong in an obvious way. It's because the AI wrote for the prompt rather than for the system — generating code that works in isolation but collides with distant constraints nobody modeled at generation time. The 81% duplication increase is the structural version of the same problem: more copies of the same logic in more places, each one carrying its own version of any assumptions baked into the original.
Why 94% Still Feel It
The self-report data makes more sense when you understand what's being measured. The Info-Tech survey, and the METR self-report study from May 2026 (which found a median 3x self-reported speed change), are both capturing real subjective experience. Developers using AI tools genuinely feel faster. The tasks feel easier. The friction of writing boilerplate, drafting initial implementations, and generating test scaffolding decreases noticeably. That experience is real.
The perception gap isn't that developers are lying. It's that "feeling faster" and "producing 12% more measured output" are compatible descriptions of the same workflow. The fast, vivid wins — code appearing instantly, tests generated in seconds — are memorable and feel like proof of acceleration. The slower, invisible costs — reading what the AI generated, catching the constraint it missed, reorganizing around the code it dropped into the wrong module — feel like normal development work, not like overhead the AI created.
JetBrains' HAX team published research at ICSE 2026 analyzing 151 million logged IDE events alongside developer self-reports and found exactly this: AI redistributes and reshapes developer workflows in ways that consistently elude developers' own perceptions. The generation is fast and satisfying. The verification is normal-feeling. Your intuition gives you credit for the first and doesn't charge you for the second.
So 94% report gains and 12% is measured. Both numbers are real.
The Measurement You Can Actually Do
The reason any of this matters is practical. If you're allocating subscription cost, deciding which tool to route expensive tasks through, or trying to understand whether your AI setup is actually improving your work — the 4x number gives you the wrong prior. So does the 94% self-report.
The comparison that would tell you something useful is: your own cycle time on similar work, before and after. Pick a specific class of task — a category of feature or PR you ship regularly. Find the median time from branch creation to merge for six months before your current AI setup, and compare it to the same metric over the past six months. Don't use lines of code. Don't use commit count. Use the time from work start to work done on work types you can actually compare.
Most developers cannot answer this question with data right now. They could — the data exists in their git history and their tools — but it requires correlating sources that are almost never looked at together. The cognitive experience of faster work is not a substitute for that correlation. JetBrains analyzed 151 million events and found that the subjective experience of AI tool use consistently misrepresents the behavioral reality. The only way around that is external data.
At xeve, cycle time from first commit to merge is one of the cleaner within-person signals we track. It doesn't require a control group. It doesn't require comparing yourself to other developers. It just requires your own history to exist somewhere and be readable.
The GitClear finding is not an argument against AI tools. It's an argument about which comparison you should trust when you're trying to evaluate them. The 4x number compares different people. The 12% number compares the same people to themselves. The second comparison is the one you're actually asking about when you want to know whether your AI setup is working.
That number is smaller than the one in the product announcement. It's also the accurate one.