Adoption rate is the wrong metric for AI coding tools, and the ACM paper published last week is the clearest evidence yet. Eighty percent of developers now use them. Twenty-nine percent trust the accuracy of the output.
That 51-point gap is where the productivity story actually lives — not in the adoption dashboard, but in the verification behavior that follows every suggestion a developer doesn't fully trust.
The paper — "Eight Myths on Software Engineering and GenAI," published in ACM Queue on August 5 — was co-authored by five Microsoft researchers and Margaret-Anne Storey of the University of Victoria. Most coverage focused on the 14% figure: developers spend only 14% of their working hours actually writing code, which means AI code generation tools are optimizing a small slice of the job. That finding is real and worth taking seriously. But the trust number is the one with direct behavioral consequences.
What Adoption Numbers Have Been Telling You
For two years, the primary signal organizations have used to evaluate AI tooling investment is adoption rate: how many developers have the tool installed, how often they use it, whether the acceptance rate on Copilot suggestions is trending up.
These numbers are easy to collect and easy to report. They are measuring the wrong thing.
Adoption tells you whether developers clicked install and keep opening the tool. It tells you nothing about what happens after a suggestion appears on screen. The ACM paper is explicit about this: usage statistics don't capture the hidden costs of evaluating suggestions that turn out to be wrong, the context switch from writing mode to review mode, or the debugging session that follows when a plausible suggestion introduces a subtle bug two functions downstream.
None of that shows up in an adoption dashboard. All of it is real work.
What 29% Trust Means Operationally
When 71% of developers don't trust the accuracy of what their AI tool produces, there is a specific behavior that follows: they check.
Not every suggestion, not in the same way. But the baseline cognitive mode of working with a tool you distrust is verification mode, not production mode. You read what comes back, you run a mental simulation of whether it's correct, and often a real simulation — spinning up a test, tracing through the logic manually, searching the docs to confirm the API exists and behaves the way the model assumes it does.
This is not irrational. The tools produce plausible code that is sometimes wrong in ways that are hard to spot at a glance. The 29% who report trusting the output have either calibrated their trust through experience — they know which categories of suggestions to accept and which to verify — or they're working in domains where failure modes are obvious enough that the cost of checking is low.
The other 71% are doing something that looks like productivity in aggregate. They're using the tool. Some suggestions get accepted. But they're paying a verification tax on every session, and that tax is invisible to the metrics being used to evaluate whether the tool is working.
The Invisible Overhead
The reason this overhead is invisible is a measurement problem, not a behavior problem.
Time tracking at the tool level tells you how many minutes were spent in VS Code. It does not tell you how many of those minutes were spent writing, how many were spent reading AI output, and how many were spent debugging a problem that the model created but your eyes didn't catch at acceptance time.
The ACM paper makes a related point about lines-of-code as a productivity metric. LoC goes up when AI tools generate more code. Generated code also has a higher churn rate than code a developer writes deliberately — it gets written, partially accepted, edited, abandoned, or re-debugged. The metric reads as productivity. The underlying behavior may be adding rework.
Verification overhead works the same way. Active editor time increases. Acceptance rates track upward. And somewhere in those hours is a significant chunk of time that is not building anything — it's auditing whether what was generated is correct. The gap between what the metric says and what the day actually contained can be substantial. You cannot close that gap without measuring at a finer granularity than most tools provide.
The Trust Problem Concentrates on Hard Work
The 29% figure is an average. The paper's actual finding is more nuanced: trust, and accuracy, depends heavily on task type, developer experience, and familiarity with the codebase.
On familiar tasks in well-trodden territory, AI tools are genuinely reliable, and experienced developers have built the domain knowledge to evaluate suggestions quickly. This is where the 29% who say they trust the output mostly live. They're probably right to.
The trust problem concentrates at complexity: unfamiliar codebases, new feature domains, cross-system integrations, architectural decisions. These are also the tasks that matter most for product velocity. They're the ones where developers are most likely to accept a suggestion that looks correct but isn't — because they don't yet have the mental model to run a fast verification.
This is where the verification tax gets expensive. Not on the boilerplate. On the novel work.
Why Adoption Is the Wrong Goal
Organizations that made adoption the success metric have backed themselves into a measurement trap. Adoption is easy to hit: roll out the tool, make it convenient, developers install it and keep it installed. The dashboard turns green.
The relevant question — does the tool reduce total time to complete a given class of work, including verification and downstream debugging — is harder to answer. It requires knowing what the baseline looked like before AI, not just how many suggestions were accepted after. Most organizations do not have that baseline. They adopted the tools before they set up the measurement.
The paper makes this explicit as one of its core myths: that acceptance rate or usage hours translate to productivity. They translate to usage. Productivity is what happens across the full day, including the hours where developers are fixing problems the tool created but no telemetry captured.
What the Data Actually Looks Like
At xeve, we track application switches, session lengths, and the rhythm of how developers move between tools throughout their working day. One consistent pattern from that data: developers working with AI coding tools tend to have shorter, more fragmented coding sessions — 5 to 15 minutes of focused writing, interrupted by documentation, terminal, browser, then returning — compared to what the same developer's sessions looked like before heavy AI use.
That fragmentation is not necessarily bad. Verification looks like context switching. Checking a suggestion against the docs looks like a browser session. The pattern is the signature of verification behavior in practice.
What it does not look like is the "40% productivity gain" headline. It looks like a different distribution of the same total hours, with more interruptions concentrated around the code editor.
The trust number — 29% — is the honest signal. It tells you how often developers believe, at the moment of accepting or rejecting a suggestion, that what the model produced is right. Every session where trust is lower than that, verification overhead is higher. Multiplied across 70% of developers on every session, that overhead is not a rounding error.
Measuring it is the thing worth doing. Not to indict the tools, but to understand where the productivity gains are actually landing and where the verification costs are absorbing them. That picture looks materially different from "80% adoption" — and knowing the difference is the first step toward closing it.