Ninety-three percent of developers now use AI coding tools. Aggregate productivity gains from that adoption sit at around 10 percent, according to telemetry from 121,000 developers across more than 450 companies, tracked by developer-metrics firm DX through February 2026 (shiftmag.dev).
That gap is the whole story. Nearly everyone bought the tool. Almost nobody got the return the tool promised.
We have spent nine years building and modernizing systems for organizations that cannot afford downtime or a botched rollout. The pattern above is one we have watched play out inside engagement after engagement, long before it had a name in a research report. The organizations that get more out of their people, their process and their tools together are not the ones with the newest stack. They are the ones that fixed the order.
The order most organizations get backwards
The instinct, when delivery is too slow, is to buy something. A tool is the fastest lever a budget holder can pull: it is easy to procure, easy to announce, and easy to point to as evidence that something is being done. Process and people feel slower and harder to act on, so they get treated as things that will "catch up" once the tool is in place.
The 2025 DORA State of AI-assisted Software Development report, based on nearly 5,000 respondents, found that causality runs the other way. Its core conclusion: AI "amplifies the quality of the engineering system it operates within" (dora.dev). Organizations with mature process and strong platform foundations turned AI adoption into real delivery gains. Organizations without those foundations saw the same tools accelerate the accumulation of technical debt instead.
Put plainly: the tool does not fix what is broken underneath it. It makes whatever is already there move faster, in whichever direction it was already heading.
This is not only an AI-era finding. A McKinsey lab study from June 2023 measured genuinely large speedups on bounded tasks — documentation time roughly halved, new code written in nearly half the time — but only on low-to-medium complexity work, and only after developers received prompt-engineering training and ongoing coaching. On high-complexity tasks, the gain fell below 10 percent. Developers with under a year of experience were sometimes 7 to 10 percent slower with the tool than without it (mckinsey.com). McKinsey's own conclusion was blunt: "tooling alone is not enough."
Read next to DX's field data, the gap makes sense. Controlled, task-level speedups on trained participants do not automatically aggregate into organization-wide gains once you add real coordination overhead, review burden and uneven adoption. Capturing the speedup requires the process to be able to absorb it.
Process debt is a people problem wearing a process costume
If tools are not the bottleneck, the temptation is to assume process is — write better runbooks, formalize the workflow, add a stage gate. That is half right.
A November 2025 study out of Karlstad University and the University of Gothenburg, surveying 191 developers across two organizations, found that "process debt" explains roughly a third of the variance in developer job satisfaction. But the two strongest contributors were not documentation gaps or missing automation. They were process that does not match how the organization actually works, and ambiguity about who owns what — what the researchers called "roles debt" (rdel.substack.com).
Both of those are people questions dressed up as process ones. A process built for a team that no longer exists, staffed by people who were never told what they are accountable for, will not be fixed by a new tool, and it will not be fixed by a policy document either. It gets fixed by deciding, specifically, who owns what, and by checking that the process still fits the team doing the work today, not the team that existed when it was written.
What happens when the order is skipped: a composite scenario
Picture two mid-market organizations, each rolling out the same AI-assisted development tooling to a team of thirty engineers. This is a composite drawn from patterns we have seen across engagements, not a specific client.
The first organization rolls the tool out to everyone at once. Role ownership on the platform team has been genuinely unclear for over a year — three people each assume someone else owns the deployment pipeline. Code review still routes through a single senior engineer, now facing triple the pull requests because the tool makes everyone write more code, faster. Six months in, throughput on paper is up, but the senior engineer is a bottleneck, technical debt is climbing, and nobody can say who is responsible for fixing it. This matches what DORA's report calls acceleration of debt rather than delivery.
The second organization spends six weeks first: clarifying who owns each part of the pipeline, and rewriting a review process that had been designed for a team half its current size. Then it rolls out the same tool to the same size team. Review load is distributed across four trained reviewers instead of one. Ownership questions have a documented, current answer. The tool produces more code, and the organization can absorb it.
Same tool. Same team size. Different order. That ordering difference is, in our experience, the single biggest variable in whether a technology investment pays for itself or adds to the pile. We won't put a specific multiplier on it here — every engagement is different, and we would rather understate this than invent a number. What we will say plainly: the mechanism the research above describes, AI amplifying whatever foundation is already there, is the same one we have watched shape delivery outcomes for nine years, long before AI tools existed to amplify anything.
What to do about it, starting Monday
Three things, in this order, before the next tool purchase gets approved:
Write down who owns what. Not a RACI chart nobody reads — a plain list of the five or six decisions your team makes weekly (what ships, who reviews, who owns the pipeline, who owns the data model) and one name against each. Roles debt does not survive being written down.
Check whether your process still fits the team you have, not the team you had when the process was designed. If the team has doubled, or the review load has tripled, the process from eighteen months ago is not the right one anymore, whatever the runbook says.
Only then, evaluate the tool. Ask what it needs from your process to pay off — faster review capacity, clearer ownership of what it touches — and confirm you have that in place before you roll it out past a pilot team.
Tool sprawl data backs up why this order matters financially, not just operationally: one investment-banking sector survey found more than half of IT leaders with budgets over £10 million reported wasting over a quarter of that budget on underutilized or redundant software (itpro.com). Getting the order right is not just about speed. It is about not paying twice.
If you are looking at a modernization effort, a cloud migration, or a rollout of AI-assisted engineering and you are not sure whether your process can absorb it yet, that is a conversation worth having before the purchase order goes in. Get in touch.