AI Coding Agents Write 30% More Code, So Why Is Software Output Stagnant?

AI coding agents are generating vast amounts of code, but a study covering more than 700 enterprises reveals a surprising fact: writing more doesn't mean delivering more.

The Numbers Behind the Code Explosion

According to a Harvard study reported by Ars Technica, AI coding agents increased lines of code by 30%, commits by 20%, and pull requests by 23%. By these metrics, AI appears to significantly boost development efficiency.

But the metric that truly measures software output—the number of features completed—barely budged. This means teams are indeed "writing" faster, but not "delivering" faster.

Commits and pull requests are two fundamental metrics for measuring software development activity. A commit refers to a developer recording local code changes to a version repository (such as Git)—a fine-grained operation that may contain only a few lines of modification. A pull request is a formal proposal by a developer to merge changes from a branch into the mainline, typically containing multiple commits and triggering code review, automated testing, and other processes. An increase in both indicates more "actions" but does not directly equate to more "value"—a single feature may consist of dozens of commits and multiple pull requests, or may generate repeated commits due to rework. Therefore, the divergence in the study between "commits +20%, pull requests +23%" and "features completed nearly unchanged" is precisely the statistical illusion that arises when activity metrics substitute for output metrics.

Bottleneck Shift: Code Review Becomes the New Chokepoint

The core of the problem lies in the code review process. The study found that review time surged 49%, change requests nearly doubled, and comments per pull request rose 35%.

To cope with review pressure, enterprises added 14% more reviewers, but this did not fundamentally solve the problem. AI-generated code requires human line-by-line scrutiny, and the time saved on writing code is offset by the downstream review burden.

This is a classic bottleneck shift phenomenon: AI accelerates upstream code production but concentrates pressure on the downstream quality control stage.

Bottleneck shift originates from the Theory of Constraints: in any system, there is always one stage that determines overall throughput. Locally accelerating a non-bottleneck stage does not increase system output—it only causes work-in-progress to pile up in front of the bottleneck. In the software delivery pipeline, writing, review, testing, and deployment form a serial chain. When AI increases writing speed by 30%, if the review stage is not correspondingly scaled or automated, it becomes the new constraint point—manifesting as longer review queues, a 49% increase in review time, and doubled change requests. This also explains why adding 14% more reviewers yields limited results—if review still relies primarily on manual line-by-line reading, the marginal returns of adding manpower diminish rapidly unless the review approach itself changes (e.g., tiered review, front-loading automated static checks).

Why Can't AI Take Over Review?

The study provides a key data point: AI handled only 23.3% of review comments, with the vast majority of inspection work still done by humans.

This shows a clear capability gap between "generation" and "verification" in current AI coding tools. Models can rapidly produce code, but humans remain the primary force in judging whether code is correct, conforms to team standards, and introduces hidden risks. Review itself requires contextual understanding, business judgment, and accountability—precisely what AI struggles to handle independently.

AI code review typically refers to using large language models or specialized static analysis tools to automatically inspect pull requests, including style consistency, potential defects, security vulnerabilities, and more. The capability boundary of such tools today is that they excel at pattern matching and common error identification but struggle with judgments requiring business context, architectural intent, and accountability. For example, whether a piece of code conforms to an undocumented business rule or whether it will fail under specific concurrency scenarios often requires an engineer who understands the requirement background to make the call. Additionally, review serves a social function of knowledge transfer and team standard maintenance that AI cannot replace—interpersonal design discussions have no substitute. Therefore, "AI handles only 23.3% of review comments" in the study is not surprising—the remaining portion is precisely the high-value segment of review that most requires human judgment.

Practical Impact on Teams and Employment

The study found no evidence of significant increases in software output, nor any signs of job losses. This contrasts with some narratives of "AI replacing programmers." A more accurate picture is: AI has changed the distribution of work, pushing human effort from writing toward review and decision-making, but overall delivery pace is constrained by the human gatekeeping stage.

For engineering teams, this study suggests a pragmatic direction: if you only invest in code generation tools without transforming the review process, efficiency gains will be diluted downstream. What truly needs optimizing is the review mechanism, automated test coverage, and the division of labor in human-AI collaboration.

AI makes writing code faster, but getting software actually shipped is still another matter.

Features completed is an output metric closer to delivery value than lines of code or commit counts, typically measured in user stories or requirement items. The reason it "barely budged" in the study is that feature delivery requires the complete chain of writing, review, testing, and integration—throughput constraints at any stage drag down the whole. This also shows that when evaluating the ROI of AI coding tools, one should not look only at generation-side efficiency data but should track end-to-end cycle time from requirement to launch and work-in-progress (WIP) counts. If review and testing stages are not transformed, generation-side acceleration only translates into larger queues rather than faster delivery.