Engineering managers are currently staring at dashboards that look like a victory lap. Across the industry, the rollout of AI coding assistants has triggered a surge in quantitative metrics that would make any traditional project manager cheer. Lines of code are climbing, pull request volumes are spiking, and acceptance rates for AI suggestions are holding steady. On paper, the return on investment for expensive LLM licenses seems undeniable. However, a dangerous disconnect has emerged between these activity-based metrics and the actual health of the software being produced. The industry is currently confusing the speed of typing with the speed of delivery.
The Mirage of the Acceptance Rate
Recent data suggests that after integrating LLMs into their workflow, some developers have seen a 40% increase in the number of lines of code they produce. In a traditional reporting structure, this is framed as a massive leap in output. In reality, this trend often signals a shift toward verbosity rather than value. Software engineering is frequently an exercise in subtraction; a senior developer who replaces 2,000 lines of tangled, legacy logic with 200 lines of clean, maintainable code has provided immense value, yet current productivity metrics would record this as a significant loss in productivity. When AI tools encourage the generation of expansive, boilerplate-heavy code, they are not necessarily accelerating the product, but rather inflating the codebase.
This inflation is further masked by the acceptance rate. Reports indicate an average suggestion acceptance rate of 33%. While this number is often used to justify the utility of the tool, it is a measure of developer behavior, not code quality. Under the pressure of tight deadlines, developers frequently hit the tab key to accept a suggestion that looks plausible, even if it is not optimal. This creates a facade of efficiency that hides a growing mountain of technical debt. An analysis of 300,000 AI-generated commits revealed that over 15% contained at least one quality issue, and a quarter of those errors were never corrected, remaining in the codebase as latent bugs.
This quality gap persists even as models evolve. In evaluations conducted across five major LLMs in 2025, not a single model was able to consistently generate web application code that met industry security standards. The result is a paradoxical environment where the quantity of code is expanding while the security and stability of the system are potentially degrading. This phenomenon perfectly illustrates Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. When companies track commits or pull requests as performance indicators, developers naturally adapt by splitting tasks into smaller, artificial increments to inflate their numbers, ensuring that activity rises while actual business value remains stagnant.
The Gap Between Toy Tasks and Production
The discrepancy between perceived and actual productivity is most evident when comparing controlled experiments to real-world engineering. In a controlled task where developers were asked to build an HTTP server from scratch using JavaScript, GitHub Copilot users completed the work 55% faster than those without the tool. This is a greenfield project—a toy task with no legacy constraints and no external dependencies. In this vacuum, AI excels because the primary bottleneck is simply the speed of writing syntax.
However, the picture changes entirely in a professional environment. A randomized controlled trial involving experienced open-source developers found that those with access to AI tools actually saw their task completion time increase by 19%. Real-world software engineering is rarely about writing new code from scratch; it is about navigating massive, unfamiliar codebases, interpreting ambiguous requirements, and coordinating with human teammates. In these complex scenarios, the AI often introduces noise that the developer must then spend time filtering or correcting.
This productivity dip is closely tied to the review burden. As AI increases the volume of code being submitted, the load on senior developers—who must review and approve these changes—has increased by 6.5%. This creates a systemic bottleneck. If the coding phase is optimized but the review phase is overwhelmed, the overall cycle time for a feature to reach production does not decrease; it may actually increase. The system is failing because it optimizes a single step in the pipeline while ignoring the downstream consequences. AI tools increase the output of junior contributors, but they simultaneously tax the cognitive load of the most experienced engineers, shifting the bottleneck from writing to verification.
Longitudinal studies of large IT organizations further complicate the narrative. Tracking Copilot users over two years revealed that early adopters were already more active developers before the tool was ever introduced. This suggests a strong selection bias in many industry reports; the perceived gains are often a reflection of the user's existing drive and skill rather than the tool's inherent capability. Furthermore, the common statistic that 87% of developers feel more productive is likely a result of the Hawthorne effect—the tendency for people to perform differently when they know they are being observed—combined with a social desirability bias to provide the answers management expects to hear.
Most AI productivity research is limited to short-term windows, often just four weeks. This timeframe captures the initial honeymoon phase of a new tool but fails to capture the long-term erosion of the codebase. Technical degradation, the atrophy of critical thinking skills due to over-reliance on AI, and the accumulation of subtle architectural flaws only become visible over several months. A tool that makes a developer 30% faster at typing but increases the long-term maintenance cost of the software is not a productivity tool; it is a debt generator.
Ultimately, if the lead time from a ticket's creation to its production deployment remains unchanged despite a 30% increase in coding speed, then the coding phase was never the bottleneck. True productivity in software engineering is not measured by the volume of the output, but by the efficiency of the entire flow. When we prioritize the speed of the individual's keyboard over the health of the systemic pipeline, we risk building faster, larger, and more fragile systems that will eventually collapse under the weight of their own AI-generated verbosity.
