AI Writes Code Faster. Audit the Path to Production Before Buying More Seats

If AI helps your developers write code faster but users do not see improvements sooner, do not assume the answer is more AI seats—or more reviewers. Audit the path from request to production. The constraint may be review, but it may just as easily be unclear requirements, unreliable tests, difficult code, or a release process that leaves finished work waiting.

The coding gain is real; the delivery gain is a separate question

Atlassian’s 2026 developer-experience report captures the distinction: 87% of developers say AI helps them ship work faster, yet only 28% report noticeably less day-to-day workflow friction. It also reports that 49% spend at least four hours a week reviewing AI output, correcting prompts, and doing related work. That figure is not a measure of time spent waiting for, or performing, a colleague’s pull-request review. It does suggest that generating an answer and getting a change ready to ship are different jobs.

The evidence does not support a blanket claim that AI slows teams down. In a longitudinal study of one AI-forward enterprise, researchers examined 802 developers and 196,212 pull requests from January 2024 through April 2026. PR throughput eventually met the company’s doubling target. Review load per human reviewer also roughly doubled, while automated review surpassed human review in coverage. Revert rates and post-merge fixes remained flat. The study does not establish that delivery to users slowed, and PR throughput is only a proxy for productivity. Its authors also note that AI adoption was not randomly assigned.

That is the decision-maker’s problem in miniature. A team can produce more changes, ask more of its reviewers, and maintain its existing quality proxies at the same time. None of those observations tells you how long a requested improvement takes to reach production. DORA’s 2025 research likewise reports a positive relationship between AI adoption and delivery throughput alongside a negative relationship with delivery stability. The sensible response is neither to stop using AI nor to assume that greater adoption will clear every downstream queue. Measure where the work goes.

Trace changes before naming the bottleneck

Start an assessment with an investment question: should the next budget go to AI capacity, reviewer capacity, test reliability, documentation, a release-process change, or a targeted code improvement? Without that question, an audit can produce a long defect list but no useful decision.

Take recent feature, bug-fix, and AI-assisted changes from one or two services. For each, reconstruct the path from request and implementation through PR creation, first human review, revision rounds, CI, merge, deployment, and any follow-up fix. Record timestamps and reasons for waiting. A long gap before first review means something different if the PR lacked a clear owner, if the designated reviewer was unavailable, or if the author had not finished verification. Ask the people involved where the record is incomplete rather than treating repository timestamps as a complete account of work.

Separate the intervals. Author-side prompt correction and checking generated code are preparation costs. Time in a queue before a colleague picks up a PR is a scheduling cost. Active review and revision reflect the effort of understanding and changing the proposal. CI waits and merge-to-production delays belong to different systems. Combining them into one ‘review time’ number makes it easy to buy the wrong fix.

Use the change history to test competing explanations. If most elapsed time falls between merge and production, hiring another reviewer will not address it. If PRs repeatedly return because acceptance criteria change, examine the handoff from product to engineering. If reviewers finish promptly but flaky tests block merges, fix the test feedback loop. If a small set of files repeatedly triggers long clarification threads, inspect those files and the knowledge needed to change them safely.

Pair these diagnostic intervals with service-level outcomes. DORA recommends examining change lead time and deployment frequency alongside change fail rate and deployment rework rate, not treating one metric as a verdict. Compare a service with its own history rather than ranking unlike services or individual developers by PR count. A faster merge that creates more production rework is not the delivery improvement you were buying.

Audit the code reviewers must understand

A reviewer does not merely check whether a diff looks plausible. They need to work out what behavior should change, which assumptions the code relies on, how the change was verified, and what might break elsewhere. AI may shorten the author’s path to a first implementation while leaving that context-reconstruction job intact.

Inspect the files that representative changes repeatedly touch. Look for large or tangled methods, unclear module ownership, missing tests, and decisions that exist only in someone’s memory. Then connect each suspected problem to an actual change history: which review question did it cause, what revision followed, and how much of the delay was attributable to the code rather than an unrelated wait? Static analysis can help locate candidates. It cannot, by itself, prove what held up delivery.

There is a useful but narrow piece of evidence here. A pre-registered observational study ran 465 agent-authored PRs from 246 repositories through a fixed five-agent review-and-fix pipeline. Each additional point on CodeScene’s CodeHealth measure was associated with 3.5%–6.1% fewer tokens after accounting for PR footprint; PR size was also a strong cost driver. But the study’s analysis found that adjusting for the size of files agents read absorbed the CodeHealth association. CodeHealth is a proprietary score, the work concerns an automated pipeline, and the observations do not show that raising a score will causally save human review time.

The practical hypothesis is more modest: a change that forces people or tools to read a large, poorly bounded area may be expensive to assess. Test that hypothesis against your own review threads and change histories. A smaller PR is not automatically easier if it hides a cross-service dependency; a well-structured file is not necessarily your bottleneck if release approval accounts for the wait.

Fix the measured constraint, not the most visible activity

Where review is genuinely expensive, start with changes that are cheap to try and easy to evaluate. Make PRs smaller when they can remain independently understandable and testable. Ask authors to state intent, affected behavior, and verification steps rather than leaving reviewers to infer them from a diff. Run appropriate automated checks before requesting review. Make reviewer ownership explicit. Our guide to a useful pull request is a practical companion for that experiment.

These are interventions, not universal rules. Splitting a coherent behavior change into fragments can increase coordination work. A longer PR description will not rescue an untestable change. Automated checks help only when their results are trustworthy; repairing flaky tests may be more valuable than adding another review bot. After each trial, inspect whether the relevant interval moved and whether failures or follow-up fixes increased.

If the evidence instead points to a high-friction code boundary, propose a staged improvement with a named owner, limited scope, risk, and verification criterion. That might mean establishing tests around a repeatedly changed area before separating responsibilities. It should not default to a rewrite. The enterprise study found AI-related gains concentrated in newer repositories and barely present in legacy ones, but that does not mean every legacy repository needs modernization. Change the boundary that demonstrably obstructs valuable work.

An independent code audit and technical assessment is useful when a team needs a defensible diagnosis before committing budget. It should be allowed to conclude that the code is not the primary constraint. If the longest wait is a release handoff, a recommendation to refactor files is a poor answer, however convincing the static-analysis report looks.

A decision checklist for the next investment

Before approving more AI-tool spending or a substantial code project, ask the assessment team to deliver:

• A decision and scope: the investment options under consideration, the services examined, and why the selected changes represent their work.

• A change-by-change timeline: request, author preparation, PR pickup, review and revision, CI, merge, production, and follow-up fixes, with reasons for significant waits.

• Reproducible findings: examples of expensive review or rework tied to specific change histories, plus alternative explanations such as unclear requirements, test failures, or release cadence.

• A prioritized trial: the smallest workflow or code change likely to move the measured constraint, its owner and risk, and how to verify its effect without relying on PR volume alone.

• A spending trigger: the evidence that would justify additional AI capacity after the constraint is addressed, including delivery and stability measures for the same service over time.

If the assessment shows that review capacity is the constraint, invest there. If code structure makes every change costly to understand, improve the demonstrated hotspot in stages. If the queue sits elsewhere, leave review and the codebase alone for now. Buy the capacity that shortens the path to production, not the capacity that produces more work for that path to absorb.