Why AI coding tools didn't increase velocity, and how to fix it

The licenses are bought. The usage dashboard is green. Your engineers are using the tools — some of them constantly. And the roadmap is landing at roughly the pace it landed at last year.

The reasonable conclusion is that the tooling was oversold. It’s the wrong conclusion, and it leads to the wrong next move: buying something better, or mandating harder.

Here is what actually happened. You made one stage of your delivery pipeline faster, and it was almost certainly not the stage that was limiting you. The work now arrives sooner at whatever was limiting you, waits there instead, and comes out the other end at about the same rate it always did. The gain is real, but it can’t show up in delivery, because a pipeline moves at the speed of its slowest stage no matter how fast you make the others.

Adoption is not the variable

It’s worth killing the adoption theory first, because it absorbs an enormous amount of leadership attention that could go somewhere useful.

DORA’s 2025 research puts AI use among technology professionals at around 90%, with over 80% believing it has made them more productive. Adoption is effectively universal and belief in the tools is high. Neither of those is the thing distinguishing the teams that pulled ahead from the teams that didn’t, for the simple reason that both groups have them.

DORA’s framing is the useful one: “AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” An amplifier does not add anything of its own. It makes what you already have louder.

What actually got faster

Something real did change, and it’s worth being precise about what.

Generation got faster. The first draft of a change now arrives in minutes instead of hours, and the friction of starting — the blank file, the unfamiliar API, the boilerplate — largely went away. DORA finds this shows up in the numbers: higher AI adoption is associated with increased delivery throughput. More changes are moving through your system than before.

That is a genuine gain, and if velocity meant “code written,” you’d have your 2-3x.

But the same DORA research finds higher AI adoption is also associated with increased delivery instability. Both went up together. More change volume arriving at systems that were sized for the old volume, and were not necessarily good at catching problems even then.

The saved time did not disappear. It was reallocated — out of creation and into verification.

Turning saved time into capacity

The time saved in generation is real. Velocity only follows when the rest of the pipeline gains the same capacity, which means applying AI across every stage rather than one.

The leverage sits either side of generation. Upstream, in how work is specified, so there is less ambiguity for a model to resolve wrongly. Downstream, in how output is checked, released and learned from, so code that is almost right gets caught by a machine in seconds rather than by a person hours later.

Every place AI touches the pipeline should either reduce the ambiguity going into generation or shorten the time it takes to find out whether the output is correct.

Don’t start on all seven at once. Start with the stage where work waits longest. Improving any other stage first repeats the original mistake one step further along the pipeline: work reaches the constraint sooner and waits there longer.

Which means you need to know where work waits — and, once you’ve made changes, whether they worked.

How to know capacity actually increased

The measure is lead time: total elapsed time from decision to customer value, broken down by the stages above. It is deliberately wider than DORA’s lead time for changes, which starts at commit, and wider than cycle time, which starts when someone begins the work. Both miss specification and the wait before anyone picks the work up.

Decision is the moment the work was committed to — prioritized and ready to be picked up. Customer value is the moment it is in customers’ hands: enabled, not merely deployed. Everything between is the clock, and each stage on the path to the customer owns a segment of it:

1. Specification — decision to ready-to-build, with the spec written and acceptance criteria agreed on
2. Writing code — ready-to-build to PR opened for review
3. Code review — PR opened to approved
4. Testing & QA — approved to passing and merged
5. Release — merged to available for customers
6. Rework — time spent returning to the item after it reached customers, attributed back to the original piece of work rather than logged as new work

Within each stage, whenever possible, separate working time from waiting time. AI shortens working time. A stage whose elapsed time is mostly waiting — for a reviewer, an environment, a release window — won’t get faster however quickly the work inside it gets done, and the table above is only doing its job if the waiting shrinks too.

None of this needs new tooling. The tracker, the version control history, the CI logs and the deploy record already hold the timestamps. The information rarely gets surfaced because measuring workflow is nobody’s job, while measuring adoption comes free in a vendor dashboard.

What “it worked” looks like

You took a baseline before changing anything. Reconstruct stage timings for recently completed work first. Without a before, there is no after — only a story about one.

The total fell, not just a stage. One stage getting faster while lead time holds steady is the exact problem this article opened with. A faster stage is a means; a shorter lead time is the result.

Throughput rose and rework didn’t. Count work delivered per period alongside rework time. DORA’s data associates higher AI adoption with rising throughput and rising instability. Capacity bought with escaped defects isn’t capacity — it’s borrowed from next sprint, and the rework segment is where you see the loan being repaid.

The slow end moved, not only the average. Look at the items that took longest, not just the median. An average can improve while the work that waits longest waits just as long.

You re-measured after each change. Relieve one constraint and it relocates — that is how systems behave. The stage that was fine at the old volume may not be fine at the new one, and the only way to know is to look again rather than reason forward from the last diagnosis.

What doesn’t count as evidence

Suggestion-acceptance rates, tokens consumed and lines generated all move without delivery improving, which makes them worse than useless when the question is whether delivery improved.

Capacity is a property of the pipeline

The teams DORA identifies as pulling ahead — strong internal platforms, robust testing, quality workflows — didn’t get there by generating more code. They had a pipeline that could absorb faster generation when the tools arrived. The amplifier found something worth amplifying.

That is the work: apply AI across the pipeline, not only at generation; start with the stage where work waits longest; and judge the result by one number — lead time, from decision to something a customer can use. The license was the easy part. This is the part that moves the number.

Common questions

Why didn't our AI rollout increase engineering velocity? +

Because writing code was almost certainly not the constraint on your delivery, so making it faster moved the queue rather than shortening it. Around 90% of technology professionals now use AI at work, which means adoption is not what separates teams seeing real gains from teams seeing none. DORA’s 2025 research finds higher AI adoption is associated with increased throughput and increased delivery instability — more changes moving into review, testing and release stages whose capacity did not change. Lead time, the total elapsed time from decision to customer value, stays flat because the time saved in generation is reallocated to verification rather than removed.

How do you use AI to increase engineering capacity rather than just code output? +

Apply it across the whole delivery pipeline, not only to code generation. Upstream, use AI to turn a ticket into a specification and surface its ambiguities and edge cases before code is written, so a model isn’t left to resolve them wrongly. Downstream, use it for automated review passes with different models before human review, for generating tests from acceptance criteria and triaging failures, for release checks and post-release monitoring, for keeping documentation and retrospectives current, and for feeding escaped defects back into specifications, review rules and tests. Every use of AI in the pipeline should either reduce ambiguity going into generation or shorten the time to find out whether output is correct.

Which stage of the delivery pipeline should we apply AI to first? +

The stage where work waits longest, which is rarely code generation — work more often sits waiting for a reviewer, an environment or a release window. Improving any stage other than the constraint means work reaches the bottleneck sooner and waits there longer, so lead time does not fall. Find the constraint by measuring lead time, the elapsed time from decision to customer value, broken down by stage and separated into working time and waiting time. AI shortens working time, so a stage whose time is mostly waiting will not get faster until the wait itself shrinks.

How do we know whether AI has increased engineering capacity? +

Measure lead time — total elapsed time from decision to customer value — broken down by stage: specification, writing code, code review, testing, release and rework. This is wider than DORA’s lead time for changes, which starts at commit and misses specification and the wait before work begins. Compare it against a baseline taken before any changes, using timestamps already held in the tracker, version control, CI logs and deploy record. Capacity has increased when the total falls, not just one stage; when throughput rises without rework rising alongside it; and when the slowest items get faster, not only the median. Suggestion-acceptance rates, tokens consumed and lines generated are not evidence, because all of them can improve while delivery does not. Re-measure after each change, because relieving one constraint moves it to another stage.

Should we buy better AI tools or mandate that everyone uses them? +

Usually neither, because both address adoption and adoption is not the constraint. DORA’s 2025 research puts AI use among technology professionals at around 90%, so the teams pulling ahead and the teams standing still both already have the tools. A better tool changes what generates the code, not where work queues in your delivery pipeline, so it layers a faster first draft onto the same unchanged process. DORA describes AI as an amplifier of the organization it lands in. What moves delivery is applying AI across the pipeline — specification, review, testing, release, documentation and rework — starting with the stage where work waits longest, and confirming the result through a fall in lead time.

---

Finding the stage that’s holding your delivery, applying AI where it relieves that stage, and measuring whether it worked is the substance of an AI transformation engagement. If the constraint turns out to be that too much of the work needs a human sitting in the loop, how to build AI automation for your SDLC covers moving that work to agents that run unattended.