The Local Velocity Paradox of AI-Assisted Development

Every team I’ve worked with on AI-assisted development learns the same thing: giving developers AI coding assistants makes them faster at writing code, and that speed shows exactly where their delivery pipeline is limited.

The bottleneck was already there

A developer with an AI assistant can turn out a feature’s worth of code in a fraction of the time it used to take. That part is real. The coding itself gets faster, no question.

But “coding” was rarely the bottleneck to begin with. Review capacity, integration, testing, and deployment usually were. Making the fastest part of the pipeline faster without touching anything downstream just lengthens the queue in front of whatever was already the actual constraint.

I’ve watched this happen more than once. On one recent engagement, the ticket data made it concrete. Roughly 30 cards reached the last verification gate before release, and all but two of them were still sitting there weeks later. The intake pattern showed the same thing from another angle. One week brought in around 40 new cards and closed out barely a dozen. The next week brought in about as many again and closed out none. Then intake dropped to almost nothing, and around 20 cards cleared the backlog together in one push.

The clock was measuring the wrong thing

There’s a second failure mode that compounds the first: sizing stories by how long they take to write, rather than by their complexity. Complexity here means how much there is to understand, integrate, test, and review.

Before AI, that shortcut mostly got away with itself, because “time to write” was never about typing speed in the first place. It was thinking time, working through the design, the edge cases, the parts of the problem that weren’t obvious yet. The typing was a rounding error against that. Gnarlier problems took longer to write because they took longer to think through. We’ve always been paid to think through problems and solve them, not to type code, so that’s what the clock was measuring. That’s why the old shortcut worked well enough: the estimate came out close by accident.

AI breaks that correlation. On a project that needed a large automated test suite written from scratch, numbering several hundred tests, AI drafted the whole thing in about a day’s worth of wall-clock effort, running many sessions in parallel. Review didn’t compress anywhere near as much. Something like eighty hours of human judgment were still needed regardless of how fast the drafts arrived. One reviewer working alone took roughly three and a half weeks end to end. That dropped to about a week once six people reviewed in parallel. The clearest tell was in the mix. The tests that took the fewest AI sessions to draft were often the hardest to review, because they were the novel, foundational pieces where no one had an established pattern yet. The tests that took the most sessions were frequently the easiest, once the pattern was established. How fast something got written and how hard it was to review barely tracked each other at all.

Teams that were already sizing by complexity keep an honest estimate. “Time to write” was never the basis, so AI doesn’t distort their points. That doesn’t mean AI does nothing for them. A pipeline that was already estimating and flowing well is exactly the one positioned to turn that speed gain into real completed work, because nothing about how the team measures or absorbs it has to change. Teams that were quietly using time-to-write as a stand-in for complexity get the opposite: the shortcut breaks badly, and the gap shows up later as missed sprint commitments that are hard to explain after the fact.

What has to change

AI coding tools deliver on their promise once the rest of the delivery system is rebuilt around the bottleneck they expose:

• Estimate by complexity, not by how long something takes to write. If a story that clearly needs heavy review or wide test coverage keeps getting pointed small because the draft came together fast, that’s the sign you’re still measuring the wrong thing.
• Put a WIP limit in front of that bottleneck. Full integration and review columns are the signal to stop generating new code and go help clear the queue, not to open five more AI-assisted branches.
• Force short-lived branches. Code that sits unmerged for days doesn’t just add to the same queue in front of review. It drifts further from mainline every day it waits, so the diff keeps growing and the eventual merge gets harder, not easier.

The teams that get real throughput out of AI-assisted development are the ones that treated “developers can generate code faster now” as pressure to finally fix the parts of their delivery pipeline that were always going to be the actual constraint.