AI made code abundant. Delivery is still scarce.

In 2025, developers pushed nearly one billion commits to GitHub, a quarter more than the year before, and merged an average of 43 million pull requests a month. GitHub’s own coding agent authored more than a million of those pull requests in five months. Over the same period, comments on commits fell by 27 percent. More code than ever is being written. Less of it than ever is being discussed.

That is the strange shape of the current moment. For decades, writing code was the constraint in software delivery, so tools that generate it feel like they must be generating speed. But a business does not buy code. It buys working software it can run, trust, and account for. That second thing is produced by a longer pipeline, and when one stage of a pipeline suddenly runs ten times faster, the constraint does not disappear. It moves to the next stage that did not.

More output is not more delivery

The gap between the two is now measurable. Faros AI studied more than 10,000 developers across 1,255 teams and found that teams with high AI adoption merged 98 percent more pull requests. The same study found no significant relationship between AI adoption and company-level improvement in throughput, delivery metrics, or quality. The extra output was real inside the team and gone by the time it reached the business. The study also shows where it went: review time up 91 percent, pull request size up 154 percent, bugs per developer up 9 percent.

Google’s DORA research, drawn from nearly 5,000 technology professionals, reports that 90 percent of developers now use AI at work, and that AI adoption is positively related to delivery throughput but still negatively related to delivery stability. DORA’s conclusion is the useful one. AI does not fix an organization. It amplifies what is already there. Teams with clear priorities and a healthy delivery system get faster. Teams without them get more code.

The queue moved downstream

Follow the new code and you find the new bottleneck quickly. LinearB analyzed 8.1 million pull requests across 4,800 teams and found that AI-generated pull requests wait more than 16 hours for a reviewer, roughly five times longer than unassisted work, and only about a third of them ever merge, against 84.5 percent for manual ones. They are also about two and a half times larger, which is precisely what makes them slow to review.

The machine now writes faster than the organization can read. Something has to give, and Faros AI’s two years of telemetry from 22,000 developers shows what does. Median time to first review is up 156.6 percent. The share of pull requests merging with no review at all is up 31.3 percent. The probability that a pull request produces a production incident is up 242.7 percent. Those numbers are one story, not three. When the queue gets long, the queue gets skipped, and production becomes the reviewer.

When code becomes cheap, everything that certifies code becomes the expensive part.

Confidence is not verification

The pressure to skip the checks is stronger because the code looks good. In a randomized study by METR, experienced open-source developers using early 2025 AI tools took 19 percent longer on real tasks, while believing afterward that the tools had made them 20 percent faster. Perceived speed and actual speed had come apart, and nobody in the room could feel the difference.

The same gap appears at review. In New Relic’s 2026 survey of technology leaders, 94 percent rated AI-generated code as higher quality than human code at review time. In the same survey, 82 percent had experienced at least one production failure tied to AI-generated code within six months.

Veracode’s testing of more than 100 models found that 45 percent of AI-generated samples introduced known security vulnerabilities. Developers already sense this. In Stack Overflow’s 2025 survey, two thirds named “almost right” code as their biggest frustration with AI tools. Almost right is the expensive kind of wrong. It passes a glance and fails in production, and the distance between those two is exactly the verification work the pipeline was built to do.

Spend where the scarcity is

If code is abundant and verified software is scarce, the investment case has inverted. The returns now sit in the unglamorous structure around the code, not in generating more of it.

1. Make requirements decidable. A model can produce five plausible versions of a feature in an afternoon. Only a precise definition of done lets anyone say which one is correct. Vague requirements used to cost a slow rewrite. Now they cost a fast one, multiplied.
2. Treat review and testing as delivery infrastructure. Size them for the new volume the way you would size a network for new traffic. Smaller pull requests, automated checks that run before a person looks, and protected review time are capacity decisions, not culture posters.
3. Keep the security gate honest. Nearly half of generated code carries known weaknesses, so the scan and the dependency check are now in the critical path of every feature, not an audit that happens later.
4. Keep ownership named. Every line that ships needs a person who can explain it in an incident review. The same discipline that governs an agent’s actions applies to its code. Unowned output is not an asset. It is inventory.

The organizations getting real value from AI coding tools are not the ones generating the most code. They are the ones whose delivery system can absorb it, which is the adoption work that a use case alone never covers. Code got cheaper this year and will be cheaper next year. What the business buys has not changed. It buys software that works, and someone who can stand behind it, and both of those are still made the slow way.