Why AI Is Slowing Down Companies (And It's Not the AI's Fault)

There’s a pattern in the 2025-2026 productivity reports that’s hard to ignore.

METR ran a controlled study where experienced developers using AI coding tools were measurably slower than the control group, despite the developers themselves feeling significantly faster. GitClear’s analysis of repos with heavy AI usage shows more code churn, more duplication, and less reuse than pre-AI baselines. Internal studies leaked from large engineering organizations all share the same shape: shipped lines of code up 3-5x, business KPIs flat or down, on-call burden through the roof, customer satisfaction sliding.

The reaction in every comments section is predictable: “AI doesn’t work. It’s overhyped. The emperor has no clothes.”

The reaction from engineers actually using AI every day is the opposite: “Are you serious? I’m twice as productive. There’s no way the data is right.”

Both groups are looking at real phenomena. Both are missing the actual diagnosis.

The studies aren’t wrong. The engineers aren’t lying. The question almost nobody is asking is the right one: what exactly are these studies measuring?

The Wrong Patient

The productivity reports measure “AI productivity” by giving AI tools to engineers in companies where only the engineers got the tools. That’s not measuring AI. That’s measuring what happens when you install a Formula 1 engine in a road car without upgrading the brakes, the chassis, the tires, or the steering.

The car goes faster on the straights. It crashes harder in the corners. The lap time gets worse on any track that has corners.

The studies are accurate symptoms. The diagnosis is wrong. AI didn’t slow down those companies. Asymmetric AI adoption did. And once you see what’s happening downstream, upstream, and around the engineering team, the data stops looking confusing — it starts looking inevitable.

What follows is the radiography of what actually happens, team by team, when AI lands in only one part of the organization. This isn’t theory. This is what’s playing out right now in companies that have been in production for six to twelve months with this approach.

The Engineering Team Splits Into Three Species

The first thing that happens is that the engineering team itself fractures into three groups that no longer understand each other.

The “done in an hour” group. They finish their tickets by mid-morning, deliver them, and by the afternoon there’s nothing left to do — because “find the next thing” was never actually their responsibility. They’re not lazy. They’re proof that their job was never what the company thought it was. We spent years paying for hours, measuring by story points, while telling ourselves we wanted “ownership.” When AI eats the mechanical part, you discover that the developer was an executor, not an owner. Nobody trained them to find the next problem because “find the next problem” was never in the job description. Take away the ticket and what’s left is silence. The silence isn’t theirs. It’s the management’s, for never being clear about what they actually wanted.

The resisters who keep coding manually and discover that the AI rejects their code in review. These are the most painful cases in the picture, and in some ways the most respectable. They’ve spent ten or fifteen years building their professional identity on “I write good code” — and suddenly the bar is set by a machine that has worse taste than they do but more consistency and zero ego. The rejection itself isn’t what hurts. What hurts is that they no longer set the bar: they go from judge to defendant, judged by something they consider inferior. The frustration is legitimate, but the war they’re fighting is already lost. The problem isn’t that AI writes better than them. It’s that the battlefield moved, and they’re still defending the wrong hill.

The bored group, which splits into two. Some quietly start working on personal projects or doing freelance work for other companies during work hours. Others begin building things inside the company that nobody asked for and that aren’t priorities. The first group isn’t betraying anyone — they’re telling you they have surplus capacity and you don’t know where to point them. The second group is even more interesting: that’s entrepreneurial energy with no channel. In a startup running on Founder Mode, those same people would be the heroes who spot the opportunity before anyone else. In a structured company, they generate lateral chaos because they build outside priorities and create extra work for product, ops, support, and sales. Same person, same impulse, opposite outcomes depending on the organization they land in.

The end of this first movie is predictable: the good engineers discover they no longer need the traditional company. The traditional company takes two years to realize it needed them.

DevOps and QA: The Structural Bottleneck Nobody Saw Coming

This is where the entire promise breaks, and it breaks for one very specific reason: AI accelerates code generation but doesn’t accelerate code integration. Deploying, testing, monitoring, supporting, rolling back, planning capacity — all of that is still done by the same humans, with the same tools and the same minds.

For every feature a developer would have taken two weeks to build and now takes two days, DevOps and QA receive the same tsunami: more deployments, more test surface, more incidents, more alerts to filter, more data that can break in production. The consequence is almost comically cynical. The company believes it’s accelerating value delivery to customers when in reality it’s accelerating the rate at which things enter a queue that’s getting more clogged by the day. Developers produce 5x, but the percentage that reaches production safely drops, and what does reach production breaks more things. Real throughput flat or negative, with the difference that now you have two entire teams burning out trying to contain a chaos the company itself generated.

And it’s not just a load problem. It’s a qualitative change in the work, which is the saddest part. When QA had to validate five polished features a week, they could do exploratory testing, think about edge cases, be a real guardian of user experience. When fifty AI-generated features arrive — features whose authors don’t fully understand the business domain — the QA role degrades to firefighting and verifying obvious regressions. The intellectual, valuable part of the job evaporates. DevOps experiences exactly the same: they stop doing platform engineering and become full-time firefighters, reactive, with no time to think three months ahead. The good DevOps and QA professionals were good precisely because they thought three months ahead.

What this reveals about management is the most uncomfortable part of the story. When someone upstairs decided “let’s put AI in engineering to go faster,” nobody in the room asked what happens to everything that comes after a developer. The role was treated as if it were just the moment of typing code. But typing was the cheap part. The expensive part of engineering has always been understanding the problem, integrating it into a living system, sustaining it as the system changes, and responding when something breaks at 3 AM. That’s exactly what AI doesn’t do — and exactly what has now become the real bottleneck, occupied by exhausted people that the company also owes a serious conversation about why their workload multiplied without anything changing in their team.

There’s also a fourth, secondary effect that’s quietly devastating: internal trust breaks. DevOps starts distrusting the code that lands on their plate. QA starts distrusting developers. Product distrusts the real state of features (“they say it’s done but we haven’t been able to deploy in three weeks”). And developers, offended, defend that they are delivering. Everyone has a piece of the truth and nobody sees the whole system.

The Cascade Across Every Other Team

If this only affected engineering, it would already be expensive. The part almost nobody is reporting is that every adjacent team experiences its own version of the collapse, and each one reveals a different fracture in the system.

Product is exposed first. Before, while engineers built a feature in two weeks, the PM had those two weeks to discuss, refine, and validate the next one. It was a chain with a buffer. When engineers start delivering in two days, the buffer disappears and the PM suddenly becomes the slow one in the room — a brutal inversion of the implicit hierarchy that existed before. Pressure to write specs faster degrades spec quality, engineers build the wrong things in less time, and the waste cycle accelerates instead of shrinking. The “broken telephone” between customer and product doesn’t get fixed — it gets amplified. There’s a deeper second layer: when a developer with AI can prototype the idea in thirty minutes, who actually decides what gets built? The person with the working prototype, not the person with the Confluence doc. The PM’s authority erodes without anyone declaring it, and many PMs find out about the new geography of power too late.

Design suffers a slower but deeper version of the same problem. Tools accelerate screen production, but the expensive part of design was never drawing — it was thinking through experience, maintaining brand coherence, defending the design system when everyone wants to skip it. When engineers prototype UIs with AI and ship them straight to production, the design system breaks silently: the brand drifts, three different versions of the same modal appear in the same app, the product starts feeling broken without anyone knowing exactly why. Good designers see it and despair. Less confident ones settle for “polishing” AI-generated screens, which is probably the saddest version of the role. Design debt doesn’t show up in any dashboard until the customer notices it, and by then it’s expensive to undo.

Support is probably the team that suffers the most, and almost nobody talks about it. Support eats the consequences of every bug QA didn’t catch and every UX inconsistency Design didn’t defend. Ticket volume explodes, and worse — the tickets are weirder than before. AI-generated features have edge cases no human anticipated, fail in creative ways, and support agents end up reverse-engineering the product in real time to figure out what’s happening. Response times collapse, NPS drops, churn rises. All of this happens far from the developers’ radar and from management’s, because support has always been the most invisible team in the company, and AI doesn’t change that — it amplifies it.

Sales and Marketing live the same movie from opposite angles. Sales starts selling faster because “we can build that for you now” — but the QA and DevOps queue is jammed, the promised features arrive late, unstable, or arrive broken. Sales loses credibility with the customer and decouples from the real state of the product, and that burns a salesperson because their capital is trust. Marketing has the inverse problem: features ship so fast there’s no time to build narrative around them. Launches stack up, blur together, dilute. The market doesn’t perceive the company’s real velocity. Lots of internal noise, external silence.

Finance and Operations see three things at once: a cloud bill that’s spiking (more deployments, more rollbacks, more wasted builds, more incidents), a headcount they no longer know how to plan (do we hire more DevOps? more QA? fewer devs?), and a CFO staring at the numbers asking what exactly the ROI of the AI bet is. Internal engineering KPIs are up, but business KPIs are flat. Engineering leadership tries to justify the investment with activity metrics and falls flat on its face, because activity was never the problem.

Legal, Compliance, and Security are the great forgotten ones, and they become the next time bomb. Ten times more features means ten times more privacy reviews, open-source licenses the AI may have introduced without anyone noticing, new attack surfaces, audits. Either these teams become another visible bottleneck, or they get bypassed and engineering ships without them. The second option is the most common and the most expensive: regulatory and security debt accumulates silent interest until the incident, the fine, or the audit arrives.

HR and People face an almost philosophical problem. Performance reviews stop making sense: how do you evaluate a developer whose code was 80% AI-generated? How do you compensate a QA team that just had a tsunami land on them with no change in their salary band? The compensation and career structure, which assumed for decades that “produce more, earn more,” stops working overnight. And burnout — especially in QA, DevOps, and Support — turns chronic. But because those teams aren’t the CEO’s favorites, nobody reacts in time.

The Time Bomb: Where Are the 2030 Seniors?

And then there’s the long-term strategic problem, which is the most serious of all and the one getting the least attention: the junior pipeline breaks.

The path from junior to senior was always doing the boring code and learning the systems from the inside while you did it. Implementing CRUD number 47 implicitly taught you how the pieces connected, where the gotchas lived, how the team reasoned, what decisions had been made badly in the past and why. If AI does that code, juniors stay frozen as prompt operators without ever understanding the systems deeply. In three to five years, where do seniors come from?

The company that put AI only in engineering isn’t just burning out today’s teams — it’s mortgaging the next generation of talent. And nobody on the executive committee is watching that clock because it doesn’t show up on the quarterly dashboard. The cost curve of this decision doesn’t manifest until three years later, when today’s seniors leave, juniors haven’t matured, and your engineering team is left with a hole no recruiter knows how to fill.

The Thesis: AI Doesn’t Accelerate. It Exposes.

The conclusion that ties all three blocks together (the three species of developers, the structural collapse of DevOps and QA, the cascade through the rest of the company) is always the same seen from different angles: putting AI in only one function doesn’t accelerate the company. It exposes it.

It surfaces which roles were executors and which were thinkers. It surfaces which teams absorbed friction created elsewhere and which teams generated it. It surfaces which processes were theater and which were real. It surfaces which KPIs measured value and which only measured activity. All of that information was already there, hidden under layers of human buffer that management never fully understood. AI doesn’t do anything new — it just removes the buffers.

What’s left visible when the buffers come off is the company you actually had, not the one on the org chart. They’re almost never the same.

What the Productivity Studies Are Really Measuring

This brings us back to the reports. METR’s study, GitClear’s data, the leaked internal numbers — they’re not measuring AI’s potential. They’re measuring AI’s effect inside companies that did the partial adoption move. Which means they’re measuring the cost of asymmetry, not the cost of AI.

A study that gave AI tools only to a soccer team’s strikers and then measured whether the team scored more goals would also produce confusing data. The strikers feel faster. They take more shots. The team somehow concedes more goals because the midfielders can’t keep up with the new tempo and the defense is exposed. A naive reader would conclude “more shots makes you lose.” The accurate reader would conclude that one position changed speed and the rest of the system didn’t.

The reports showing slowdowns aren’t a verdict on AI. They’re a verdict on a strategy. The strategy of “let’s give the engineers AI and see what happens” is the one that’s failing — quite predictably, once you see the full picture.

The companies that will see the productivity gains the early hype promised are the ones rebuilding the entire pipeline around AI: product discovery accelerated, design systems hardened against AI-generated drift, QA augmented with intelligent test generation, DevOps with AI-native incident response, support with AI summarization and triage, legal and compliance with continuous policy checks. Not “AI in dev” — AI as a layer through the whole company, with the org structure, metrics, and incentives redesigned to match.

That’s a much harder, much slower, much more political move than buying every developer a Copilot license. Which is why most companies won’t do it. Which is why the productivity reports will keep showing the same confusing data for another year or two. And which is why the companies that do make the harder move are about to open up an unrecoverable lead on the ones that didn’t.

The Mirror, Not the Engine

Sun Tzu wrote two and a half thousand years ago that knowing yourself was half of winning the war. AI, without intending to, is forcing companies to know themselves — team by team, decision by decision, KPI by KPI. That’s good news, but only for companies willing to look at what they see in the mirror.

The ones that aren’t will keep producing more code, faster, all the way to the cliff.

The productivity reports will keep showing it. The engineers will keep insisting they feel faster. Both will be right. And both will keep missing the actual story: AI isn’t an engine. It’s a mirror. It only accelerates the companies that already knew where they were going.