AI Doubles Code Output but Slows Production: A Paradox in 2026

The Illusion of Dashboards in Engineering

During a recent conversation with a founder, I witnessed a revealing scene. During a video call, he shared his engineering dashboard, proudly displaying a notable increase in the volume of commits and pull requests. AI tools like Copilot, Cursor, and Claude were being used by everyone. However, when I asked the crucial question about how many of those pull requests were actually deployed this month, silence fell. After a few clicks, he simply responded with a "Huh," summarizing the current state of engineering productivity in 2026.

This scene is not isolated. The dashboards I have examined this year all tell a similar story. Teams are producing more code than ever, but few leaders check whether that code is actually deployed. And often, the answer is disappointing.

The Reality Behind Flattering Numbers

The tech industry faces a paradoxical reality. According to the 2026 CircleCI Software Delivery Report, based on over 28 million CI/CD workflows, the average number of daily workflows surged by 59% compared to the previous year, a record high. AI has undeniably changed the game. However, the same report reveals that for the median team, the throughput of feature branches increased by 15%, while that of the main branch decreased. More code is being integrated, but less is actually delivered.

The top-performing teams, representing 5% of the total, nearly doubled their output. In contrast, the bottom quartile saw no significant gains. Thus, AI has not benefited everyone equally; rather, it has accentuated the differences between well-structured teams and those that are not.

The Adoption of AI Assistants and Its Consequences

I observed this phenomenon at a client startup whose engineering team fully embraced AI coding assistants. The monthly report for the board showcased impressive commit velocity. Yet, the pace of deployments slowed down. Each AI-generated pull request still had to go through the same two reviewers who had been conducting traditional code reviews for three years. These reviewers did not speed up their pace simply because the code arrived faster. On the contrary, each pull request required more time to be reviewed, as a larger portion of the code needed to be checked for typical AI tool errors.

The bottleneck did not disappear; it simply shifted. If your team has adopted AI tools and your velocity numbers have increased, but you feel greater confusion, you are not alone. This pattern is repeating across the industry.

Reevaluating Productivity with AI

In light of this observation, many CTOs make the mistake of investing in another AI tool to speed up code writing, when that is not where the constraint lies. The constraint has shifted downstream, towards review, testing, or other obstacles that separate written code from shipped code. Kent Beck aptly expressed this idea, emphasizing that when everyone can build anything, knowing what is worth building becomes crucial. I would add that knowing what is safe to ship is equally essential, and few organizations account for this in their budgeting.

To effectively measure developer productivity with AI coding tools, we must stop viewing throughput as a simple aggregate number. It is crucial to break it down based on where it occurs in the pipeline. Activity in the feature branch indicates the team's experimentation speed, while activity in the main branch shows delivery speed. These two elements used to evolve in tandem, but that is no longer the case since AI has made experimentation almost free.

The gap between these two lines is the most honest signal you can get, but it is often obscured by a single "velocity" graph. The 2026 Pragmatic Engineer survey, conducted with over 900 engineers, confirms that most companies do not track this gap. A senior engineer described how code review has evolved in his company: "I used to do thorough code reviews, but I no longer have the motivation to do so for massive pull requests where even the original author hasn't taken that effort." This is not a productivity gain, but a debt that quietly accumulates.

The True Shift of the Bottleneck

It is crucial to clarify that AI does not simply create messy code. Data from CircleCI and the Pragmatic Engineer survey show that AI amplifies the existing engineering culture. Teams with good testing, clear architecture, and rigorous code review have become faster while maintaining quality. In contrast, teams lacking these elements have become faster but also messier.

For teams already lax on process, the solution is not to reduce AI usage, but to correct what AI has highlighted. A key indicator to monitor is the success rate of the main branch, with a healthy target of around 90%. Currently, the industry average is 71%. This gap, rather than the number of commits, is the true indicator of AI-related productivity for most teams.

The Metrics That Really Matter

Commits and the volume of pull requests are easy numbers to inflate with AI, but they do not necessarily add value. They are also the metrics that beautify reports for boards, explaining their persistence despite their loss of meaning. If I were to rebuild an engineering dashboard today, I would highlight the success rate of the main branch, followed by other relevant indicators to assess true productivity.