The AI Productivity Paradox: Why Teams Don't Get Faster
Developers feel faster with AI, but teams don't ship proportionally more. What METR and DORA found, and why coordination is the real bottleneck.

The AI productivity paradox is simple to state: almost every developer now uses AI, most of them feel faster, and their teams don't ship proportionally more. The research backs both halves. Our own experience does too. Before we built SyncStaff, my co-founder Nick and I ran several AI coding agents each on one project and spent more time cleaning up after them than building. This post covers what the studies actually found, why individual speed doesn't add up to team speed, and the bottleneck we think most teams are hitting: coordination.
What is the AI productivity paradox?
The AI productivity paradox is the gap between how productive AI makes people feel and how much more their organisations actually deliver. Developers using AI report large personal gains, yet controlled studies find small, uncertain or even negative effects on task time, and team-level delivery improves less than individual enthusiasm suggests. The gains are real in places; they just don't compound the way people expect.
What the research found
Three sources are worth knowing, because they measure different things.
METR's 2025 study measured individual task time directly. Sixteen experienced open-source developers worked through 246 real issues in large repositories they already knew, with each issue randomly allowed or forbidden to use AI, mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet. With AI allowed, tasks took 19% longer. The striking part was perception: the developers expected AI to speed them up by 24%, and afterwards still believed it had sped them up by 20%.
METR is careful about what that doesn't show. It doesn't show that AI fails to speed up most developers, and the developers and repositories studied don't represent most software work. It's a snapshot of experienced people on familiar, complex codebases with early-2025 tools.
METR's February 2026 update tried again with late-2025 tools, 57 developers and over 800 tasks. The estimates now point toward a speedup: roughly 18% less time for developers from the original study and 4% less for new recruits, with wide confidence intervals. But METR's own summary is that the new data gives "an unreliable signal". More developers declined to take part, which likely biased the result, and one reason stands out for teams like ours: time measurements were unreliable for developers who run multiple AI agents concurrently, because they worked on other things while an agent ran.
DORA's 2025 State of AI-assisted Software Development report measured organisations rather than tasks, surveying nearly 5,000 technology professionals. 90% use AI at work, and more than 80% believe it has increased their productivity. Unlike the year before, DORA found a positive relationship between AI adoption and software delivery throughput. But AI adoption still has a negative relationship with software delivery stability, and 30% of respondents report little or no trust in AI-generated code. DORA's summary: "AI doesn't fix a team; it amplifies what's already there."
Put together: individuals feel much faster than measurements confirm, organisations ship somewhat more, and stability gets worse. That's the paradox.
Why individual speed doesn't become team speed
A developer with an agent writes code faster. The team's output is limited by everything around the code: reviewing it, merging it, fixing what it broke, and agreeing on what to build. AI speeds up the first part and puts more load on the rest.
That's why the picture changes as agents multiply. One agent per developer mostly changes how fast code gets written. Several agents per developer, across several developers, changes the shape of the work:
- More changes in flight at once, each written without knowledge of the others.
- More overlap, because features that look separate on a task board touch the same schema, router or shared types.
- More review and merge load, landing on the same few people.
- More breakage that nobody saw happen, because no person was watching when two changes met.
DORA's finding fits this. Throughput goes up because more code ships. Stability goes down because more of it collides.
What it looked like for us
Before SyncStaff, Nick and I were building a predictive model for risk-adjusted wagers across betting markets, with several agents each. We'd agree "you work on this, I'll work on that", and it held until the current bug was fixed and we moved on to other work. Then the boundaries blurred. We broke the models, the databases and the UI, and spent more time troubleshooting changes we hadn't been watching than building anything new.
Nothing about that was a model-quality problem. Each agent did what it was asked. The failure was that no agent knew what the others were doing, and neither did we in real time. Claude Code's agent teams hit the same wall inside a single session, as we found in what breaks when agent teams collide.
Coordination is the missing layer
Most advice about the AI productivity paradox focuses on the individual: better prompts, better review habits, better models. That helps with one agent. It doesn't help when the problem is between agents.
What changed things for us was making every agent declare what it's about to change, and checking that against everyone else before the work starts. We built SyncStaff that way and have built it with itself since August. Over 11 weeks, from August 3 to October 18, 2026:
- 544 agent-days of work, with 21 to 45 different agents active each week, across two people and three vendors' models.
- 623 work items completed.
- 40 times an agent asked for files another agent was already changing and was refused before it touched them. In 37 of those, the agent moved on to other files within a day.
- 568 decisions escalated instead of guessed: we answered 356, and our Chief of Staff resolved 161 routine ones.
Each of those 40 refusals is the kind of collision we used to find days later, after something broke. They became one-line refusals at the moment an agent asked.
Five questions to ask about your own team
If you suspect your team is inside the paradox, these questions find out faster than a survey:
- How many agents does each developer run at once, and how many did they run three months ago? If that number is climbing and delivery isn't, the bottleneck has moved.
- How often do two agents' changes touch the same files? Look at your last few weeks of merges. Conflicts and same-day fixes to the same file are the signal.
- How long does finished agent work wait before it merges? Long waits mean review and integration, not writing, are the constraint.
- How many changes get reverted or patched within a day? That's DORA's stability finding, measured on your own repository.
- When an agent needs a decision, who makes it, and how long does it wait? Unanswered questions and guessed answers both cost more than they look.
If the answers point at overlap and waiting rather than at code quality, better models won't fix it. Coordination will.
How to get team-level gains from AI agents
- Measure delivery, not feelings. METR's perception gap is the warning: track lead time, merged changes and how often things break, not how fast people feel.
- Plan for stability, not just throughput. If more code is landing, strengthen the checks it lands through: tests, review, and gates before merge.
- Split work by files, not by feature names. Two features that both touch the schema aren't parallel work.
- Give every agent its own working copy. Worktrees stop agents overwriting each other mid-task. They don't stop the conflict at merge; we showed both with Codex worktrees and Claude Code subagents.
- Coordinate before the work, not after. The cheapest moment to find out two agents want the same file is before either starts.
- Keep people for the decisions that matter, and let routine ones resolve themselves. We covered how in human in the loop for AI agents.
The paradox is a coordination problem
AI makes individuals faster at writing code. Teams get faster only when the extra code doesn't collide, and as agents multiply, collisions become the main cost. The studies show it from different angles, and our experience showed it the hard way. If your team uses more agents every month and ships about the same, look at what happens between the agents before you look at the agents themselves. That's the layer SyncStaff provides: every agent, from any tool, declares its change and leases the files first, so parallel work stays parallel.
Sources: METR, early-2025 study of experienced open-source developers, METR, February 2026 update, Google Cloud, announcing the 2025 DORA report, DORA 2025 report.
Frequently asked questions
What is the AI productivity paradox?
It's the gap between how productive AI makes people feel and how much more their organisations deliver. Most developers use AI and feel faster, but controlled studies find small or uncertain effects on task time, and team delivery improves less than expected while stability gets worse. AI speeds up writing code more than shipping it.
Do AI coding tools make developers faster?
It depends on the setting. METR's 2025 trial found experienced developers took 19% longer with AI on familiar codebases, while believing they were 20% faster. Its February 2026 update points toward a speedup with newer tools, but METR calls that data an unreliable signal. Results vary widely by task, codebase and tools.
What did the 2025 DORA report find about AI?
DORA's 2025 report, from nearly 5,000 professionals, found 90% use AI at work and over 80% believe it raised their productivity. AI adoption now correlates with higher delivery throughput but still with lower delivery stability, and 30% report little or no trust in AI-generated code. Its conclusion is that AI amplifies what's already there.
Why aren't teams shipping faster with AI agents?
Because the bottleneck moves. Agents speed up writing code, but more changes in flight means more overlap, more review and merge load, and more breakage where changes meet. Without coordination between agents, the time saved writing code is spent finding and fixing collisions later.