Researchers at Wharton and MIT followed more than 500,000 developers on GitHub from 2022 to 2026. With all three generations of AI coding tools in use, those developers made 240 percent more commits. They shipped only 30 percent more releases.
That is still a gain. But it is a small gain for that much more code. Most of the extra code never reached anyone who uses the software.
For some companies it went further: the gain disappeared entirely. McKinsey's Technology Trends Outlook, published in September, reports that in 30 percent of companies, productivity fell after teams started using AI agents to write code. Not stayed flat. Fell.
So how does a team write far more code and ship only a little more, or even less? In my client work I see three things, and they often happen together.
1. Code arrives faster than anyone can check it
Review and testing were sized for the old pace. Nobody changed them when the AI tools arrived. The same few reviewers now face two or three times as much code, and the queue in front of them grows every week.
Developers don't sit still while they wait. They start something new. Soon each person has three or four pieces of work half finished, and every one of them takes longer to finish. The team is busier than ever and delivers less.
2. The AI builds what it was told, not what was needed
A ticket title used to be enough, because people filled in the details by talking to each other as they worked. The AI doesn't ask. It fills the gaps with something plausible and builds it quickly. The mistake shows up in review or after release, and fixing it then costs more than it would have cost to describe the work clearly up front.
3. Many developers don't trust the output, so it gets checked twice
In Stack Overflow's 2025 developer survey, 46 percent of developers said they actively distrust the accuracy of AI tools; 33 percent said they trust it, and only 3 percent trust it highly. Where people don't trust the output and nobody clearly owns what the AI produced, everyone protects themselves. Reviewers check it twice. Developers quietly rewrite the parts they don't trust. Both are reasonable, and both use up the time the tools were supposed to save.
None of these is a tool problem
A better model won't fix any of them. They are about how work moves between people: who decides what to build, who checks it, and who owns the result. The companies that got slower bought a fast tool and kept a way of working built for slow coding.
The teams I've seen get faster changed four things:
- They break work into small pieces and review each one as soon as it's finished, inside the team that wrote it.
- They write a clear description before the AI starts, not after the review fails.
- The whole team owns the result, and checking is part of the work, not a step at the end.
- They change how they work when the tools change, instead of waiting for a reorganization.
Three things to check this week
- Pick five pieces of work your teams finished recently. For each one, find when the code was done and when it reached users. If the gap is longer than the time it took to write the code, you've found where the speed is going.
- Ask a team lead how much of last month's work was redone after review, and why. If the answer is mostly "that's not what they meant," the delay starts before anyone writes code.
- Ask two developers, separately: "When AI-written code breaks in production, whose problem is it?" Two different answers, or a long pause, tells you who is doing the checking twice.
I'm making the full case on October 27: "Agile Isn't Obsolete. It's What Makes AI Work." It's live, free and an hour long, with time for your questions.
Sources
- McKinsey & Company, Technology Trends Outlook 2026, "Agentic software development," p. 10 (30% of companies).
- Stack Overflow, 2025 Developer Survey, AI section (46% / 33% / 3% developer trust; also cited in McKinsey, p. 10).
- Mert Demirer, Leon Musolff and Liyuan Yang, "Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools," NBER Working Paper 35275 (2026). 500,000+ GitHub developers, 2022–2026: https://www.nber.org/papers/w35275