Back to blog
AI Is Creating More Work Than It Solves
AI ProductivityEngineeringWorkflowTech TeamsManagement

AI Is Creating More Work Than It Solves

2026-04-107 min readPrince Kumar

The most misunderstood finding in AI productivity research is buried in the middle of Faros AI's 2025 report, and almost no one is discussing it. Developers on teams with high AI adoption complete 21% more tasks and merge 98% more pull requests per day. That's the headline most people share. What they skip is the next line: PR review time increases 91%. For every doubling of output at the code-writing stage, review time nearly doubles too. The bottleneck didn't disappear. It moved downstream. And in many organizations, the downstream capacity hasn't grown at all.

Developers merge 98% more pull requests and PR review time has increased 91%. AI is shipping more work than humans can review. That's not productivity. That's a pipeline crisis.

The Paradox in the Numbers

Amdahl's Law a principle from computer science states that a system moves only as fast as its slowest component. You can make one part of a pipeline infinitely faster; if another part doesn't scale, overall throughput is bounded by the constraint. AI coding tools have dramatically accelerated one specific stage: writing implementation code. They have done nothing for the stages that follow: code review, security assessment, QA testing, integration, deployment, and post-deployment monitoring. When you double the volume going into a pipeline without expanding its capacity, you don't get more output. You get a longer queue.The Faros research found that developers on high AI-adoption teams touch 9% more tasks and 47% more pull requests per day. The word 'touch' matters here. More context switching historically correlated with cognitive overload and reduced quality is being reframed as a productivity indicator. That reframing deserves scrutiny.

Where the New Work Is Coming From

  • AI-generated code requires review that human-written code does not always require because the failure modes are different and less predictable. A human engineer who writes buggy code tends to understand the bug. An AI that generates buggy code may have no recoverable reasoning path.
  • Only 30% of GitHub Copilot's suggested code is accepted after developer review. The 70% that is rejected still had to be read, evaluated, and discarded a form of work that has no prior equivalent in the development process.
  • Junior developers using AI tools generate, per the 2025 State of Engineering Management Report, 'significantly more buggier, lower-performing code' because AI accelerates the generation of code that looks syntactically correct but lacks architectural soundness. This creates a maintenance burden that compounds over time.
  • Documentation, one of the most consistently neglected parts of engineering work, is now being generated by AI at volume but AI-generated documentation requires the same review and accuracy verification as AI-generated code. Volume has increased without quality assurance scaling to match.
  • Meeting notes, summaries, and internal communications are increasingly AI-generated, creating a new category of work: verifying whether AI-generated internal content is accurate before it influences decisions.

The Survey Data on Burnout

The 2025 State of Engineering Management Report found that while 62% of engineering teams are seeing at least a 25% productivity increase from AI tools, burnout and organizational complexity are rising in parallel. AI adoption is no longer optional 90% of engineering teams now use AI coding tools, up from 61% the prior year. The expectation of productivity gains has been internalized into headcount decisions and roadmap timelines. Engineers are now expected to deliver at AI-augmented velocity even when the AI tools underperform or introduce rework.The McKinsey finding that developers using AI tools are twice as likely to report feeling happy and experiencing 'flow' states is real but it applies to the subset of developers who are AI-fluent and working on well-defined tasks. For the developer who is spending their day reviewing AI-generated code they didn't write, debugging AI-introduced edge cases, and managing the downstream consequences of AI output quality variation, the experience is different.

The Organizational Gap Nobody Budgeted For

When companies decided to invest in AI coding tools, they budgeted for the tools. Almost none of them budgeted for the organizational changes required to handle the volume those tools produce. Review processes designed for a team generating 100 pull requests per week are not equipped to handle 200 without either adding reviewers or degrading review quality. Most teams chose the implicit third option: accepting faster delivery with less rigorous review and learning about the quality gap in production.The DORA 2025 report found that teams without solid CI/CD practices, fast feedback loops, and strong existing engineering culture see little benefit from AI adoption. AI amplifies existing strengths and existing weaknesses in equal measure. The companies advertising 10x productivity gains from AI are, in essentially every documented case, already strong engineering organizations with mature practices. For everyone else, AI acceleration without infrastructure investment produces more technical debt faster.

What Would Actually Help

  • Invest in review capacity before deploying AI generation tools the constraint is downstream, not upstream
  • Measure PR review time, not just PR volume the metric being optimized determines what the team actually optimizes for
  • Separate 'AI accelerated the individual' from 'AI improved the system' these are different claims requiring different evidence
  • Build AI literacy into engineering culture before mandating adoption the productivity gains are real for fluent users and negative for reluctant ones
  • Treat AI-generated code with the same security review as third-party code because the failure modes are more similar to imported libraries than to internally reasoned code