Faster code, slower teams
How the rush to automate coding has made software teams slower than ever
The realisation struck during what should have been a routine sprint retrospective. Sarah, tech lead at a mid-sized fintech company, stared at velocity charts that made no sense. Despite her team's shiny new AI coding assistants producing twice as much code, their project had somehow fallen three weeks behind schedule.
"I don't understand it," muttered Sarah, scrolling through endless pull request queues. "I'm writing code faster than ever. The AI is incredible. But every PR takes forever to review, and we keep finding weird edge cases nobody anticipated."
Sarah's experience isn't unique. Across the software industry, teams armed with large language models and AI coding assistants are discovering a troubling paradox: the faster they generate code, the slower they seem to deliver working software. This isn't the productivity revolution that was promised—it's something far more complex and considerably more expensive.
The seductive promise
The narrative surrounding AI coding tools has been intoxicating in its simplicity: generate code faster, ship features quicker, outpace the competition. Industry surveys trumpet productivity gains of 25% to 50%. Developers share screenshots of AI assistants writing entire functions in seconds. Venture capitalists pour billions into companies promising to eliminate the "coding bottleneck" once and for all.
Yet in early 2025, researchers at METR conducted a rigorous randomised controlled trial that shattered these assumptions. Sixteen experienced open-source developers using cutting-edge AI tools like Cursor Pro with Claude 3.5 Sonnet were actually 19% slower at completing real-world tasks compared to working without assistance.
The psychological disconnect was even more revealing: developers estimated they had been 20% faster when using AI tools. They felt more productive whilst actually being less productive—exposing something profound about how we measure efficiency versus how we experience it.
This perception gap reveals something profound: the industry has confused the sensation of productivity with its substance. The assumption that faster code generation equals faster software delivery is as flawed as believing that faster typing creates better novels.
When faster becomes slower
To understand why AI coding tools often hinder rather than help, consider what actually happens when a development team adopts these technologies. Initially, individual developers experience a genuine rush of capability. Complex algorithms that once required hours of careful crafting now appear in seconds. Boilerplate code materialises instantly. The psychological satisfaction is immediate and addictive.
But software development has never been primarily about individual productivity. It's about team coordination, shared understanding, and collective problem-solving. The moment AI-generated code enters this ecosystem, it disrupts established patterns of collaboration in ways that advocates rarely acknowledge.
Code reviews, already the primary bottleneck in most development workflows, become exponentially more burdensome. Where senior developers once reviewed 20-30 lines of thoughtfully written code and could quickly grasp the author's reasoning, they now confront 200 lines of AI-generated code whose purpose and approach remain opaque.
The mathematics are unforgiving. When AI tools double code output, the review bottleneck doesn't simply double—it detonates. Complex AI-generated code demands more scrutiny precisely because reviewers cannot decode the machine's reasoning process. Meanwhile, developers who submitted the code often struggle to explain their own pull requests. Responses like "the AI suggested this approach" or "I'm not entirely sure why it works, but the tests pass" become disturbingly common.
The mathematics of coordination debt
Fred Brooks identified this problem nearly fifty years ago in his seminal work "The Mythical Man-Month." Adding more people to a software project, Brooks observed, often makes it slower rather than faster. The reason is mathematical: communication overhead scales exponentially with team size. A team of four people has six communication channels; a team of eight people has twenty-eight.
AI coding assistants don't eliminate this dynamic—they accelerate it. Each AI-generated code block effectively represents another "team member" whose output must be coordinated, verified, and integrated. The AI doesn't attend planning meetings, doesn't understand the broader system architecture, and doesn't consider the maintenance implications of its suggestions. It simply generates code that humans must then wrangle into a coherent system.
Consider the hidden costs that emerge:
Prompt engineering time: Developers spend increasing amounts of time crafting precise prompts to get useful output, often through multiple iterations. This meta-programming overhead frequently exceeds the time saved in actual code generation.
Verification effort: AI-generated code requires extensive testing and validation. Unlike human-written code, where the author can explain the edge cases they considered, AI output comes with no inherent understanding of its own limitations.
Context switching costs: The cognitive burden of constantly evaluating AI suggestions disrupts the deep thinking required for complex problem-solving. Many developers report feeling more scattered and less focused when relying heavily on AI assistance.
Technical debt accumulation: AI tools excel at generating code that works immediately but may be poorly suited for long-term maintenance. The full cost emerges months later when features need modification or debugging.
These coordination costs don't scale linearly—they compound. The faster teams generate code with AI assistance, the more coordination debt they accumulate, creating a vicious cycle where apparent productivity gains mask growing systemic inefficiency.
History's expensive lessons, forgotten again
The software industry suffers from collective amnesia, rediscovering every generation that writing code was never the bottleneck. In the 1980s, fourth-generation languages made identical promises to today's LLM evangelists. Tools like Focus and PowerBuilder would eliminate traditional programming, allowing business users to specify requirements in near-natural language.
The pattern proved depressingly familiar: initial excitement, genuine gains in narrow domains, then growing coordination costs that negated the benefits. 4GLs succeeded brilliantly at report generation and simple database queries but became unwieldy for complex systems. Computer-Aided Software Engineering tools in the 1990s generated thousands of lines of code overnight—and created integration nightmares that lasted for years.
Each cycle optimises for code generation whilst ignoring the coordination challenges that actually determine delivery speed. Large language models represent merely the latest iteration, excelling in specific domains whilst struggling with complexity—just like their predecessors.
The work that can't be automated
The persistent myth that coding is the bottleneck stems from a fundamental misunderstanding of what software engineers actually do. Studies consistently show that developers spend more time reading code than writing it—often by a factor of ten to one. The bottleneck isn't creating new code; it's understanding existing code well enough to modify it safely.
This insight explains why LLM productivity claims often fail to materialise in practice. The tools accelerate the easy part (initial code generation) whilst making the hard part (comprehension, integration, maintenance) significantly more difficult. AI-generated code often lacks the conceptual clarity that makes human-written code maintainable. It optimises for functional correctness rather than human understanding.
Consider a typical enterprise development scenario: a team needs to add a feature to an existing system. The actual typing of new code might represent 10-20% of the total effort. The remainder involves understanding the existing architecture, identifying the right integration points, considering backward compatibility, writing comprehensive tests, updating documentation, and ensuring the change doesn't introduce regressions elsewhere.
LLM tools can certainly accelerate that initial 10-20%. But they often increase the remaining 80-90% of the work. The generated code may require extensive refactoring to fit existing patterns. The lack of clear documentation about AI-generated logic makes future modifications more difficult. The speed of generation can lead to inadequate consideration of architectural implications.
Sarah's team discovered this reality the hard way. Their velocity metrics looked impressive—they were closing tickets faster than ever. But their technical debt was accumulating at an alarming rate. Features that should have taken days to modify were requiring weeks. Bugs were appearing in unexpected places as AI-generated code interacted poorly with existing systems.
"We optimised for the wrong thing," Sarah reflected months later. "We focused on how fast we could write new code instead of how fast we could deliver working, maintainable solutions to our users. The AI made us feel productive whilst actually making us less effective."
The real coordination trap isn't technical—it's psychological. It's the seductive belief that faster code generation will solve our delivery problems. Yet software engineering's fundamental constraints remain stubbornly human: the need for understanding, coordination, and judgment.
The sooner we accept this, the sooner we can focus on what actually accelerates software delivery: clearer communication, better architecture, and more thoughtful collaboration. The distinction matters more than the industry cares to admit.