Why AI Tools Make Some Teams Slower

Brian Zimbelman

— 7 min read
Share
Why AI Tools Make Some Teams Slower

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.

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."

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.

This article is about that split, what causes it, and why naming it is the setup for the rest of this series.

The data shows the dichotomy

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.

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.

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.

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.

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.

Why faster coding can make a team slower

Here's the mechanism. When the front-end coding step speeds up without corresponding upgrades downstream, bottlenecks don't disappear — they move.

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.

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.

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.

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 shifts; if the new bottleneck is worse than the old one, total throughput drops.

The old bottleneck was coding, now it is reviewing or QA or... This is where processes must be adjusted to take advantage of the new landscape. How do we reduce all of the bottlenecks to make the entire process flow faster?

What separates the winners

Coordination and Processes - Coordination and processes make for successful ai adoption

Teams that gain from AI tools tend to have, or rapidly develop, a specific cluster of practices. Vibe Coding calls them foundational skills; similar ideas turn up in DORA's own recommendations and across an increasingly lively literature on AI-augmented development. The core set:

Architectural thinking. Somebody is responsible for the shape of the system, not just the current diff. AI-generated code does not default to good architecture; it defaults to "whatever the prompt implied." Teams that gain from AI have humans who keep the overall structure coherent as the rate of change accelerates.

Fast feedback loops. Tests, CI, and preview environments that run in minutes, not hours. A 45-minute CI cycle that was annoying at human coding speed becomes catastrophic at AI coding speed, because the rate of incoming changes overwhelms the validation step. Kent Beck — the original author of Extreme Programming — has been notably vocal since 2025 that TDD becomes a "superpower" specifically when paired with AI agents (Pragmatic Engineer podcast with Kent Beck). TDD and XP practices that felt like 2005 revivals are getting a second life, because they're the practices that make fast feedback loops real.

Clear communication protocols for agents. What context the agent gets. What it returns. What handoffs look like. Teams that gain treat agent interactions like API calls — versioned, documented, conventional. The teams that struggle treat them like free-form chat.

Dependency management and small, well-bounded work items. AI agents succeed at small, well-specified work and fail at large, ambiguous, multi-step work. The teams that win feed their AI tools the right size of task; the teams that struggle ask one prompt to do three people's jobs.

Independence of action balanced with coordination discipline. Engineers need freedom to explore with the tools. They also need enough shared structure that the explorations don't fragment the codebase. "Everyone uses AI how they want" feels like autonomy but produces a codebase no one can review.

Redefining your team's workflow.(AWS, 2025)
AI-DLC and other modified development lifecycles that incorporate AI as a first class citizen in the process bring some of the best practices that teams are finding into play and help teams to adjust their practices in ways that improve the development lifecycles.

What the losing teams are missing

The mirror image. No clear ownership of architecture. Slow or flaky feedback loops that the AI's increased throughput overwhelms. Ad-hoc prompting with no shared conventions. Work items too big, too vague, or too coupled for anything — AI or human — to make clean progress on. A culture that treats "the engineer uses AI how they want" as autonomy when it is really a refusal to coordinate.

The tool amplifies whatever the team's practices already were. If those practices were weak, the tool makes the weakness more visible, faster.

This is not the tool's fault, and it's not the engineer's

The failure mode is structural. Teams were running their SDLCs at a pace calibrated to pre-AI coding speed. When the front end speeds up and nothing else does, the system gets worse in a way that's hard to see from the inside. The engineer feels more productive (they wrote more code!). The team is less productive (less shipped, more bugs).

Now the engineer is coming into work with a backlog of PRs and feeling overwhelmed with all the changes that are going on, they can't keep them all straight, what is this PR doing anyway? The stress levels keep climbing, all these stories are waiting on me, ugh. Work becomes less fun and more frustrating.

The right tools and the right process

If we can combine tools that accelerate the whole lifecycle with a process that reduces the burden on the team members to context switch and reduces the backlogs, then we can achieve the performance gains as a team that AI is promising.

More code is not more productive. More shipped work is, and shipped work is a whole-team accomplishment. The next generation of AI tooling has to know that.

Coming next

In the next article, The End of Cheap AI, the economic context tightens. Bundled enterprise tokens are being retired. Power prices, memory prices, and hardware supply are all moving the wrong direction for the "just burn tokens" approach. The teams that have been papering over practice gaps with abundant cheap tokens are about to lose that cushion.

Sources

Read more