The Illusion of AI Coding Speedup: Coding Accounts for Only 15% of Delivery Time

AI coding tools are spreading at a remarkable pace, but a fact that most teams overlook is this: writing code was never the real bottleneck in software delivery. If coding accounts for only 15% of the delivery cycle, then doubling coding speed yields just a 7.5% improvement in overall delivery.

Coding: A Bottleneck No One Measures

Over the past six months, one engineering leader kept asking engineering managers the same question: Of your delivery time, how much is spent writing new code? The answers clustered between 10% and 20%, sometimes lower.

Where does the rest of the time go? Understanding constantly shifting requirements, aligning with stakeholders who changed their minds, debugging production incidents, coordinating three teams moving at different rhythms to lock down a single integration date, reading codebases others wrote. GitHub's developer experience research backs this up — developers spend roughly as much time waiting on builds and tests as they do writing new code, and that's before counting meetings, code reviews, and security work.

DORA's ROI of AI-Assisted Software Development report reaches the same conclusion from a financial angle: returns come from the organizational system surrounding the tool, not the tool itself; gains reach 35-40% on simple tasks but only 10% or less on complex legacy code. The gains shrink precisely where the real work lives.

Yet most AI coding benchmarks measure exactly code generation — isolated greenfield tasks, clean problem statements, well-defined success criteria, no human in the loop. Real delivery hands you self-contradictory Jira tickets and a downstream service team that shipped a breaking change without telling anyone. No benchmark captures that.

DORA stands for DevOps Research and Assessment. It was originally founded by Nicole Forsgren, Jez Humble, Gene Kim, and others, and became a Google Cloud research program after Google acquired it in 2018. It is known for its annual State of DevOps Report, which established quantitative benchmarks for software delivery performance through tens of thousands of practitioner surveys, proposing four core metrics: deployment frequency, lead time for changes, change failure rate, and time to restore. DORA's methodology links engineering practices directly to organizational performance, making it a common reference point for engineering leaders deciding whether tool investments are worth it. The ROI of AI-Assisted Software Development report cited in this article continues that tradition, evaluating the marginal returns of AI tools from both financial and process perspectives.

A Misread "AI Productivity Win"

One team once announced their "first AI productivity win": a shared service used daily by twenty-odd developers had cut build time by more than 50%. The slides looked great, but digging deeper revealed a story far more interesting than the headline.

A senior engineer traced the execution path through the containerized test infrastructure and discovered that PostgreSQL's JIT compilation feature — beneficial for large production databases — imposed catastrophic overhead on small JUnit test databases. Turning it off dropped SQL execution time from 62 minutes to 6 minutes.

AI helped them locate the configuration faster once they knew what to look for. But knowing which question to ask required a person who understood how the layers interacted, someone who had been burned by similar problems and had intuition about where to poke. That is the work benchmarks cannot measure, and it is the work that actually produced the win.

Requirements and Alignment: Where Delivery Actually Happens

In one entire sprint, the single most impactful engineering activity was a 40-minute conversation with a product owner. It stopped the team from building the wrong thing. No code was written, sprint velocity didn't budge, but that conversation saved days or even weeks of wasted effort.

The hardest part of most projects was never implementation. The hardest part is getting five stakeholders with different priorities to agree on the definition of "done," and communicating trade-offs — explaining that shipping a feature quickly might come at the cost of something they value more. AI coding tools are astonishingly good at answering "how do I implement X," but they cannot help you decide whether X is the thing to do at all. That question lives in a human context of organizational politics, business strategy, and regulatory constraints — none of which fit in a prompt window.

Andrew Diamond points out in Software Engineering in the Age of AI: AI cannot know whether the code it just generated violates the legal constraints your product is subject to, nor whether it conflicts with a feature another team plans to ship next quarter. That knowledge lives in human institutional memory — accumulated context that exists at decision time but was never written down.

An unexpected finding: the time saved by AI coding assistants is not reinvested into better requirements analysis or deeper thinking, but into reviewing generated code, fixing suggestions that missed important context, and switching back and forth between tools. The cost of building the wrong thing never dropped; we just got faster at it.

Production Debugging: The Ultimate Context Problem

Ask any senior engineer where their most stressful hours go, and the answer won't be "writing new features" — it will be "figuring out why something that worked yesterday doesn't work today."

Production debugging demands understanding system interactions across service boundaries, reading incomplete logs — "incomplete" not because they haven't been indexed yet, but because nobody thought that information was worth recording. Then you need institutional knowledge: this service deployed last Thursday, and that team quietly changed a retry policy without updating the runbook. Good luck finding that in a prompt.

AI tools are genuinely useful for specific debugging tasks — log pattern matching, hypothesis generation, explaining unfamiliar code. But the hard part is knowing where to look, which requires cross-system context the model doesn't have. Speeding up code generation does nothing for the engineer at 2 a.m. chasing a timeout through four services and a message queue, trying to figure out which of the day's seventeen changes introduced a subtle ordering dependency.

Cross-Team Dependencies: The Silent Killer

I've never seen a project delayed because someone typed too slowly, but I've seen dozens delayed by dependencies on another team. Waiting for an API contract to be finalized — it got reprioritized and nobody told you; a shared library update pushed back sprint after sprint; a platform team requiring a ticket to allocate an environment, with the approver on vacation until next week; a security review backlog; a decision stuck because it needs input from someone who's in back-to-back meetings until Thursday.

Theory of Constraints applies equally to software delivery: improving a non-bottleneck does not increase system throughput. If coding accounts for 15% of the delivery cycle and cross-team coordination accounts for 40%, doubling coding speed saves only 7.5%, while improving coordination efficiency by 25% saves 10%. The math isn't complicated; we just don't want to look at it, because coordination problems are messy, political, and have no clean solution you can put on a slide.

A survey commissioned by Harness covering 700 practitioners and managers underscores the same point: 94% of engineering leaders say critical factors like technical debt, verification time, and developer burnout are entirely absent from their productivity metrics. We measure what's easy to measure, then call it the whole picture.

Theory of Constraints was proposed by Israeli physicist Eliyahu M. Goldratt in his 1984 book The Goal. Originally applied to manufacturing, it was later adopted in project management and software delivery. Its core claim: every system has a bottleneck that constrains overall output; accelerating non-bottlenecks not only fails to increase system throughput but may generate more work-in-progress and waiting queues. Goldratt's improvement sequence is: identify the constraint, exploit the constraint's potential, subordinate everything else to the constraint's pace, then consider elevating the constraint itself. Apply this to software delivery: if coding accounts for 15% of the cycle, optimizing around coding is like widening a highway entrance outside a narrow tunnel — traffic still jams at the same spot.

The Constraint Has Shifted to Review

A rebuttal worth taking seriously is this: AI agents no longer just type — they run test suites, trace failing tests, open PRs. But look at where the queue forms. Everything an agent produces still lands in front of a human who must decide whether to trust it, and that is exactly where teams are stuck today: review and verification have become the constraint that build time once was.

Some researchers are rethinking the code review model from scratch, and engineering leaders describe the same dilemma in the same words — a review model that worked when humans wrote code is collapsing under the volume produced by bots. DORA describes this mechanism as a J-curve: a dip first, then a rise, with the dip coming from verification overhead rather than learning the tool. Automating the 15% more thoroughly only pushes more volume into the queue behind it.

The J-curve is a classic model describing gains in the early stages of technological or process change: after introducing a new tool, short-term performance dips, then recovers and eventually surpasses the prior level. DORA uses it to explain AI-assisted development's impact on delivery — the dip isn't because the team is unfamiliar with the tool, but because AI dramatically increases code output volume, flooding review, testing, and verification stages with pending work while their capacity hasn't expanded in step. Understanding this mechanism is critical for engineering leaders: if you fixate only on local metrics in the coding stage, you'll mistake the curve's trough for tool failure, or credit the subsequent recovery entirely to the tool itself, missing the verification capability investments that are truly needed.

What to Measure

If you're an engineering leader reading this on a Monday morning, don't measure how long it takes code to go from PR to merge — measure how long it takes an idea to become something a customer can use. Most organizations already have this data; it's buried in Jira tickets, Slack conversations, and calendar invites.

When you discover that six weeks passed and writing the code took three days, the bottleneck becomes obvious. You don't need another tool to find it — you just need to look at the whole journey, not one small segment of it.

The key question isn't whether AI is useful — it is, and I use it every day. The real question is: does our investment distribution match our constraint distribution. From what I've observed in my own practice, it does not.

One-line Summary

AI coding speedup only touches a small segment of the delivery cycle; the real bottlenecks are requirements, coordination, and review.

Paragraph Summary

The article argues that coding accounts for only 10% to 20% of the software delivery cycle, with the rest consumed by requirements alignment, production debugging, cross-team coordination, and code review — so doubling coding speed yields only about a 7.5% overall improvement. DORA reports and the Harness survey together show that returns from AI-assisted development come from organizational systems, not the tools themselves, with gains reaching 35-40% on simple tasks but falling below 10% on complex legacy code. A case where one team "halved build time" illustrates that real wins come from senior engineers' understanding of system interactions, not the code generation capability benchmarks measure. As AI agent output grows, the constraint has shifted from build time to code review and verification — what DORA calls the dip phase of the J-curve.