When AI Speeds Up Coding and the Bottleneck Moves

A CTO I have known for years pinged me earlier this month with a chart attached. Lead time per feature, plotted over the last four quarters. The line was flat. He had finally rolled out Copilot, Cursor, and an AI test-generation tool across his engineering org. Developers reported feeling faster. Pull-request volume had roughly doubled. The number his board cared about had not moved by a measurable amount, and his next quarterly review was in three weeks.

I knew exactly what was on his chart because it is the same diagnosis that recurs once structured tooling lands at scale in a delivery org. The cycle-time numbers per individual ticket: down. Developer self-reported speed: up. Aggregate lead time from request to production: flat. The same shape, every time the constraint is left where it landed.

This is the pattern the rest of this article is about. It is not a hypothesis. It is the diagnostic I gave him, grounded in per-stage delivery telemetry and corroborated by the peer-reviewed research on AI-assisted development that has landed in the last twelve months. The headline number stays flat because the constraint moved. AI assistance did its job at the stage it was pointed at, which is local code generation. The bottleneck that used to sit on coding migrated downstream. Until the operating model recognizes the new location and redesigns around it, the rollout will keep buying more of the wrong solution.

Lead time is what the business sees. Cycle time is what AI shrinks.

The two metrics get used interchangeably in casual conversation. They are not the same metric, and the gap between them is exactly where AI productivity goes to die.

Cycle time, in the lean and Kanban tradition that DORA work draws from, measures the active hands-on duration of a piece of work once it is started. For a developer it is the time from when they pick up a ticket and begin coding to the moment the work-in-progress is functionally complete. AI coding assistants compress this window on controlled tasks. The peer-reviewed GitHub Copilot randomized controlled trial (Peng et al., 2023) measured a 55.8 percent reduction in time-to-complete on a standardized JavaScript HTTP-server task. The Stack Overflow Developer Survey 2024 reports that 76 percent of professional developers use or plan to use AI tools, with code-writing as the most-cited use case. Developers themselves consistently report feeling faster.

The complication is that controlled-task gains do not necessarily survive contact with real production code. METR's early-2025 randomized controlled trial (Becker et al., 2025) studied sixteen experienced open-source developers completing 246 real issues in repositories they already knew intimately, averaging twenty-two thousand stars and over a million lines of code. The measured result was that AI tools made these developers nineteen percent slower, not faster. The same developers' own ex-post estimate was a twenty percent speedup. On controlled, well-scoped, greenfield tasks, AI assistants compress cycle time. On production-grade work inside large existing codebases, the cycle-time effect can disappear or invert. The gap between Peng's RCT and METR's RCT is, in microcosm, the bottleneck-migration phenomenon the rest of this article unpacks. The kind of work AI tools were benchmarked against is not the kind of work that fills a real delivery pipeline.

Lead time is a different animal. DORA defines lead time for changes as the duration from code commit to code successfully running in production. That is already a strict definition, and many organizations measure something broader: the calendar time from when a user request is first captured to when the value lands in front of a user. Decomposed, this broader lead time contains the following stages, only one of which is coding:

• Time the request waits in backlog before it is prioritized
• Time spent on requirement clarification, story slicing, and acceptance-criteria definition
• Time spent on architectural review or design decisions
• Active coding time
• Time the pull request waits for review
• Time spent in review iteration
• Time the merged code waits in a QA queue
• Active QA time, including test design and execution
• Time in the deployment pipeline, including any release-management gating
• Time in any release window or staging soak

If active coding consumes twenty percent of total lead time in your delivery system, then a 30 percent reduction in coding time produces a 6 percent reduction in lead time. The math is not flattering. And the math is also conservative, because the speedup at the coding stage often pushes additional work into the downstream stages, which absorbs the gain and then some.

The flat lead-time chart the CTO sent me was not a failure of AI. It was what happens when you accelerate one stage of a system without redesigning the stages it feeds.

The Theory of Constraints didn't go away because the model got bigger.

Eliyahu Goldratt published The Goal in 1984. The book describes a manufacturing system in which throughput is determined entirely by the slowest workstation. Speed up any other workstation and throughput is unchanged. Speed up the slow workstation, and the bottleneck moves to whichever workstation is now the slowest. This is the Theory of Constraints, and software-delivery flow inherits the structure cleanly, as Reinertsen documents at length in The Principles of Product Development Flow.

The constraint in a delivery system is the stage whose effective throughput is lowest relative to demand. Before AI assistance arrived, the constraint in most engineering organizations sat squarely on the coding stage. Developers were the most expensive resource, their hours were finite, and demand for code consistently exceeded supply. Every adjacent stage was tuned around this assumption. Code review existed as a quality check, not a throughput stage, and was sized accordingly: a senior reviewer might be expected to handle a handful of pull requests per day on top of their own coding load. QA test design was treated as a long-tail activity that ran alongside development. BAs and PMs assumed a steady-state arrival rate of stories that the team could absorb without ambiguity-removal turning into a crisis. SAs reviewed architectural decisions on a cadence that matched the pace at which new components were being designed and built by hand.

When AI assistance compresses coding time without changing any of those adjacent assumptions, the constraint moves to whichever adjacent stage is now structurally weakest. The new bottleneck is not a tooling problem. It is a capacity-allocation problem inherited from a pre-AI operating model. The tools are doing what they were designed to do. The org has not done what it needs to do.

Where the constraint went, role by role.

The migration is not random. Between the per-stage telemetry and what the CTO walked me through on his side, five downstream locations absorb the released constraint in predictable proportions.

Pull-request review. This is the first stage to break, and it breaks the hardest. When a senior developer writes a 400-line PR by hand over two days, the cognitive cost of reviewing it spreads naturally over their colleagues' attention. When the same developer scaffolds the same 400 lines in four hours with an assistant, the review queue receives the same volume of code in a fraction of the time. If review capacity was already at 85 percent of what was needed, it is now at 130 percent. PRs age in the queue. Reviewers triage by criticality and ignore the rest. Quality erodes silently, because the visible signal at the dashboard level is not a bug count but a flat lead-time line that nobody connects back to the review queue.

QA test design. Test execution speeds up under AI assistance, and that part is visible. Test design does not. Faster-arriving code in PR review means QA receives more change-sets per week, and each change-set needs a test plan that matches its actual surface area. AI-generated tests are not a substitute for AI-generated test design: a Claude-written unit test that lacks the edge case a QA engineer would have invented is a unit test that gives false confidence. The QA backlog grows. The release cadence slows by exactly the amount the team is unwilling to ship without a complete test plan, which is to say, almost the entire amount.

Business analysis and product management. This one surprises people. AI assistance does not just accelerate coding; it changes what the team can absorb upstream. A senior developer working with an assistant can implement a story 40 percent faster, which means the team's appetite for stories grows. Stories arriving from PM or BA at the old cadence now feel slow. Worse, the assistant amplifies any ambiguity in the story: where a human developer would have stopped, written a clarifying question on the ticket, and waited a day for the BA to respond, an assistant will happily generate something plausible that satisfies the surface of the story while missing the intent. The downstream cost is rework discovered in review or QA, which lands back on the BA's desk as a clarification request, which sits in their queue alongside the new stories the team is asking for. The ambiguity-removal workflow that was sized for the old code-arrival rate is undersized for the new one.

Solution and software architecture. AI assistants generate more code, but they do not generate more architectural decisions. They are also, in practice, optimistic about the cost of fitting new code into the existing architecture. When developers using assistants ship more features per sprint, they generate more architectural decisions per sprint that need an SA to ratify. If the SA team is sized for the old generation rate, the architectural-review queue starts to lag. Either decisions get made tactically by developers in the moment, accumulating into structural debt that costs five times as much to unwind later, or features wait for SA bandwidth and lead time grows on a different axis.

DevOps and release management. Faster code arrival also means faster pipeline arrival. CI/CD systems that ran comfortably at the old commit cadence now queue. Release windows planned around weekly throughput need to handle three times the velocity of merged change-sets. The constraint here is sometimes infrastructure capacity, but more often it is release-management policy: change-advisory boards that meet weekly, deployment freezes tuned to a slower pace, on-call rotations that cannot absorb a higher rate of post-deploy incidents.

The pattern is consistent. AI assistance moves the constraint to whichever downstream stage was already running closest to capacity, and the new constraint is structural, not tooling-shaped.

How to find your new bottleneck.

The diagnostic procedure is not exotic. It uses signals every delivery organization is already collecting in Jira, GitHub or GitLab, Linear, or the equivalent. The reason most organizations have not done this diagnostic is that pre-AI, the bottleneck sat on coding and was assumed, so the downstream signals were treated as second-order. They are now first-order, and where they belong on the leadership surface is an honest AI adoption dashboard.

Pull a six-week sample of completed work items from the start of AI tool rollout and a comparable six-week sample from twelve weeks before rollout. For each sample, compute the following:

Time-in-review distribution. For every pull request, the duration from PR open to PR merge, broken down into time-with-author and time-with-reviewers. If the post-rollout sample shows the same total open-to-merge time but a higher fraction spent waiting on reviewers, the constraint moved to review. If you see PRs aging past three days more often, the queue is saturated.

Time-in-coding versus time-in-review ratio. Calculate the ratio of active coding time on a ticket to time in PR review. If the pre-rollout ratio was four-to-one and the post-rollout ratio is one-to-one, the entire productivity gain at the coding stage is being absorbed by the review queue.

QA backlog age. The number of merged-but-not-tested commits at the end of each week. A growing trend is an unambiguous signal that the QA stage is now the constraint. The count alone is sufficient; you do not need to weight by complexity.

Story rework rate. The percentage of stories that get returned from review or QA to development with a "this is not what the spec asked for" comment. A rising rate post-AI rollout indicates that ambiguity which used to be caught at the human-coding stage is now slipping through and landing in downstream stages, which usually means the BA/PM stage is undersized for the new arrival rate.

Deploy frequency lag. If active coding gets faster but commits-to-production lead time is flat, the constraint sits between merge and deploy. Investigate CI/CD queue times, release-management policies, deployment freezes, and the cadence of any change-advisory body.

Reviewer concentration index. Count how many PRs each senior reviewer touches per week. If the post-rollout sample shows the same handful of senior names absorbing a higher and higher fraction of reviews, you have a single-point-of-failure constraint that will not resolve through capacity addition alone.

Run this in a spreadsheet. The signals are not subtle once you decompose lead time by stage. The reason most leadership teams have not done this is not technical difficulty; it is that they are still looking at the aggregate lead-time line and inferring backwards.

Three patterns that recur once AI assistance lands at scale

These three patterns recur in AI-enabled delivery orgs that introduce structured AI tooling. They tend to appear in sequence as adoption deepens - first in smaller AI-focused groups where the patterns are unambiguous, then across the wider delivery organization as tooling extends. The same three patterns came up again unprompted in the CTO conversation that opens this article. None of them are exotic. They are what falls out of the math once coding gets cheap.

Pattern A: review queue collapse. Within six weeks of giving developers structured Claude Code access for production work, the average time a PR spent waiting on first review went from under a day to over three days. The team had not changed. The volume of PRs had roughly doubled, because every developer was finishing in one day what had previously been two-day tasks. Senior reviewers were still treating review as a 90-minute-a-day activity. The review stage had not been redesigned as a first-class throughput function. The result was a steadily growing PR queue and a quality drift that was only visible at the bug-rate level six weeks later.

Pattern B: QA test-design backlog explosion. Two months after the review-queue intervention landed, the constraint moved one stage downstream. Test execution time fell as the QA team adopted assistant-generated automation. Test design time did not. A QA engineer designing tests for a refactor of an existing service still needs to map the change against the actual user surface, the contract guarantees, and the historical bug pattern of the module, and an assistant cannot do that for them at quality. The test-design backlog grew faster than the team could absorb it. QA productivity had been treated as if it was bounded by execution speed, when it was actually bounded by design throughput.

Pattern C: requirement-ambiguity rework spike. The third pattern tends to land a few months in, and it is the one teams least expect. A measurable rise in returned stories appears - stories that are merged, sent to QA, and then returned to development with a comment that the implementation does not match what the BA had intended. The root cause was consistent: developers using assistants were generating plausible-but-not-quite-right implementations of ambiguous stories more often than they used to, because the assistant was happy to fill in any ambiguity with a confident default. Pre-AI, the developer would have stopped, written a question on the ticket, and waited. Post-AI, they shipped, and the ambiguity surfaced two stages later.

None of these patterns required a new measurement system to detect. They required looking at the per-stage signals already in place and no longer treating coding as the canonical bottleneck.

What changes in the operating model when you take this seriously.

Once you accept that the constraint moves, the operating-model implications follow.

Reviewer capacity becomes a first-class resource. Senior developer hours allocated to review need to be modeled with the same rigor as any other capacity. Rotation, backup coverage, throughput targets, and explicit review-stage SLAs land in the ops playbook. PR review is no longer a side activity; it is a stage that needs ownership and instrumentation. The CTO I was helping ended up reserving roughly a quarter of senior-engineer capacity explicitly for review, monitored at the stage level rather than buried inside individual time tracking. An effective allocation in AI-enabled delivery orgs converges on roughly the same number from the same direction.

QA test design moves upstream of coding. Spec-driven development becomes a structural requirement, not a methodology preference. If the test plan exists before the code does, the assistant generating the code has a concrete contract to fulfill, and the QA backlog does not blow up downstream. Spec-driven workflows are the operational form of the upstream shift; the SDD Starter Kit framework I published earlier this year covers the per-stage gates in detail and connects directly to this article's argument.

Ambiguity-removal becomes a measured workflow. BA and PM throughput needs to be sized against the new code-arrival rate, not the old one. The signal "how long does a clarification request sit in the BA queue" goes from a soft metric to a hard one. If your ambiguity-removal cycle takes 36 hours and your assistant-aided developer finishes the surrounding work in 12, you are guaranteeing rework on every ambiguous story. The fix is not faster BAs; it is making ambiguity-removal an explicit, prioritized stage with capacity allocated to it.

Architectural review becomes a scheduled service. The SA team needs a cadence that matches the new decision-arrival rate, not the old one. In practice this means a published architectural-review SLA, a queue that is monitored, and clear escalation paths when a decision needs to ship faster than the SLA allows. The alternative is silent structural debt.

Release management aligns to merge cadence, not weekly meetings. If merges arrive three times more often, the change-advisory cadence either matches that velocity or it becomes the constraint. CI/CD investment also moves up the priority list. The investment is not the constraint; the policy around it usually is.

The role-level mechanics of all this map cleanly onto the L1–L4 maturity frameworks I have been writing about for each delivery role, and the diagnostic signals above are what you would expect a level-3 organization to be tracking by default. Companies stuck at level 1 or level 2 are typically still running the pre-AI operating model around a post-AI coding stage, which is the exact mismatch this article describes.

A tools-only AI rollout cannot solve a constraint that moved off the tool.

Public reporting on AI tool spending in 2024–2025 (GitHub's Octoverse 2024, the Stack Overflow Developer Survey, vendor earnings disclosures from the major coding-assistant providers) shows budgets concentrating on the coding stage: more licenses for assistants, bigger context windows, better IDE integration. The same default choice is easy to make at the start, and the CTO I have been writing about did exactly that. The stage that is already faster than its neighbors gets more investment; the stages that have absorbed the released constraint get none. The lead-time line stays flat. The board asks where the ROI is. The procurement-shaped instinct is to buy more of the tool that worked the first time, not to look at the operating model the tool exposed.

The intervention is not another tool. The intervention is to instrument the downstream stages, find where the constraint moved, and redesign the role-level capacity and workflow around it. Dashboard metrics that distinguish coding-stage signals from review-stage and QA-stage signals are part of this; the companion piece on what an honest AI adoption dashboard actually contains develops the measurement side in detail. The maturity-ladder framing of where this lands organizationally is in the L0–L4 article on adoption maturity. Both anchor to the same operating-model premise as this one: tools live at the bottom of the stack, the unlock lives at the top.

If your AI rollout has been running for more than six months and your lead-time number has not moved, the diagnostic procedure in section five is where I would start. The signal will be in the data you already have. The fix will be in the part of the operating model you have not yet redesigned.

Frequently Asked Questions