Why AI Tools Make Some Teams Slower

Sign in<br>Subscribe

This is Article 2 of Beyond the Coding Assistant, a multi-part series on AI-assisted software engineering at enterprise scale. The full series is available free of any paywall at https://articles.zimetic.com. Previously: Article 1 — Your AI Coding Assistant Is Not Enough. Coming next: Article 3 — The End of Cheap AI.<br>Two teams roll out the same AI coding assistant in the same quarter. Same vendor, same model, same seat count. One team ships more, with fewer incidents and happier engineers. The other team ships less than they did before the tool arrived. Pull requests pile up awaiting review. Tests flake. Deploys stall. Engineers context-switch more, sleep worse, and start writing LinkedIn posts about "AI fatigue."<br>The difference between those two outcomes is not the AI. It's everything the AI is pushing faster against — everything the AI didn't change but that now has to keep up.<br>This article is about that split, what causes it, and why naming it is the setup for the rest of this series.<br>The data shows the dichotomy<br>The most credible single data point here is the 2024 DORA Accelerate State of DevOps Report. DORA is an industry-standard framework for measuring software delivery performance — throughput, stability, time-to-restore, change failure rate. The 2024 report dedicated a substantial section to AI adoption, with a genuinely uncomfortable finding.<br>On the individual level, AI looked like a clear win. 75.9% of respondents reported relying on AI for part of their job, and 75% reported personal productivity gains (DORA 2024). Flow improved. Job satisfaction improved. People liked the tools.<br>On the organizational level, the picture inverted. DORA's modeling found that "a 25% increase in AI adoption is associated with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability" (InfoQ summary of DORA 2024). Individual developers felt faster. Teams shipped less reliably. Both statements came out of the same survey of the same teams.<br>Recent research from MIT Sloan and Microsoft offers a theoretical frame for exactly this gap. In Chaining Tasks, Redefining Work: A Theory of AI Automation, Shahidi and colleagues argue that AI's value emerges at the workflow level, not the task level — and that there is a threshold effect on the way to capturing it. "Up until reaching that threshold, the costs of adopting AI dominate the gains," lead author Peyman Shahidi told MIT Sloan's Ideas Made to Matter in April 2026 (MIT Sloan: How AI is reshaping workflows and redefining jobs). Only after teams have restructured around AI do measurable benefits appear. The DORA anomaly is what that pre-threshold zone looks like in production: individual tasks accelerate while the team-level workflow, still calibrated using old processes, drops behind.<br>Gene Kim and Steve Yegge's Vibe Coding (2025) calls this out as the "DORA anomaly" and treats it as one of the central motivating observations for why their framework — FAAFO (Fast, Ambitious, Autonomous, Fun, Optionality) and the surrounding practice set — is needed in the first place (IT Revolution / Vibe Coding) (The Register book review). They are not saying AI is bad. They are saying AI without the right practice scaffolding reliably produces the exact pattern DORA measured.<br>Why faster coding can make a team slower<br>Here's the mechanism. When the front-end coding step speeds up without corresponding upgrades downstream, bottlenecks don't disappear — they move.<br>More code means more review load. More review load means more latency on pull requests. More PRs waiting means more context-switching for reviewers. More context-switching means more mistakes slipping through, because human attention is a finite resource and Gloria Mark's 23-minute recovery-from-interruption figure is still true whether the interruption comes from a notification or from a new AI-generated PR that needs a second opinion (Mark, CHI 2008). More mistakes means more incidents. More incidents means more on-call interruptions, more post-mortems, more time rebuilding trust in the pipeline. Each amplifies the others.<br>The MIT Sloan paper sharpens this point. Each handoff between AI and human carries a coordination cost — review, validation, adjustment — and AI-task-then-human-task workflows accumulate those costs at every step. End-to-end workflows that keep adjacent AI-friendly steps clustered together avoid the handoff tax. The "more code, more review, more context-switching" cascade is the handoff tax made visible.<br>The "coding" part of the job was already a small fraction of total throughput before the AI arrived. Accelerating it in isolation moves the ceiling almost not at all — and can lower it by starving the downstream steps of capacity.<br>This is not a new mechanism. It's Amdahl's Law applied to software delivery, and it's Theory of Constraints applied to coordination work. Speed up one non-dominant stage and the bottleneck...