AI Didn't Make Your Team Faster. It Moved the Bottleneck.

The number that should bother you

This is published in the same month the loudest AI jobs forecasts got walked back by the people who made them. That reversal surprised a lot of commentators. It shouldn't surprise anyone who measures systems for a living, and the reason why is what this piece is about. I've been watching machine learning since 2013, back when Coursera Machine Learning courses meant running gradient descent by hand on a laptop that sounded like it was apologizing. So I want to be careful about how I say this, because it would be easy to read it as a complaint. It isn't. AI-assisted development is real, and it's useful. But the story most teams are telling themselves about it is wrong in a specific, measurable way, and the cost of being wrong shows up about ninety days later. Here's the claim I keep hearing: AI made our engineers faster, so we're shipping faster. The first half is often true. The second half usually isn't. What actually happened is that the work got faster at one stage and the bottleneck moved somewhere you weren't watching.

The individual-productivity numbers look great until you put them next to the team numbers. A 2025 study of experienced open-source developers found they were about 19% slower on familiar codebases when using AI tools, after predicting the tools would make them 24% faster. Even after finishing, they estimated they'd been sped up by about 20%. Sit with that gap for a second. Not slower than they thought. Slower in absolute terms, while feeling faster. Junior developers, by contrast, picked up real gains, somewhere in the 10 to 30% range on the kind of well-bounded work they were already doing.

Now zoom out to the team. Coding might improve 30 to 40%, but if planning, testing, and release stay manual, overall throughput often rises less than 10%. The 2026 data circulating right now puts numbers on the side effects: review times stretching, code churn climbing from around 3% to closer to 6%, and AI-generated code carrying materially more security defects, with one analysis citing nearly three times the vulnerability rate. The most common developer complaint isn't "it's wrong." It's "it's almost right, but not quite," which is the most expensive kind of wrong because it survives a casual review. None of this means the tools failed. It means we measured the wrong thing and celebrated.

Why this is a flow-metrics problem, not an AI problem

I ran a quarter where our deployment frequency was high and our customer satisfaction scores were flat. The pipeline was healthy. The problem selection wasn't. The metric was telling the truth; we were asking it the wrong question. AI in the SDLC is the same lesson with a new cause. Deployment frequency and individual coding speed are local optimizations. They tell you how fast one stage runs. They tell you nothing about whether the whole system moves work to "done" any faster. That's what flow efficiency measures, and flow efficiency is where the AI story falls apart.

When you make the coding stage three times faster, you don't speed up the system. You increase the arrival rate at the next stage. If the next stage is human review, and review capacity is fixed, you've just built a bigger queue. Queuing theory has been clear about this since before any of us were writing software: you cannot speed up a system by accelerating a stage upstream of the constraint. You can only move work to the constraint faster, where it waits.

So the question every engineering leader should be asking isn't "how much faster is our coding?" It's "where is our constraint now, and did AI move it?" For most teams I talk to, it moved to one of two places: review bandwidth, or requirements quality.

The constraint moved to review

Review was always a quiet bottleneck. AI made it loud. When a senior engineer reviews human-written code, they're reading the work of someone who had to reason through every line. The reasoning leaves fingerprints. When that same engineer reviews AI-generated code, the fingerprints are gone. The code is plausible, internally consistent, and confidently wrong in places that don't announce themselves. The reviewer can't lean on "would a person have written it this way," because a person didn't. That's why experienced developers slow down. The validation burden went up, even though the typing burden went down, and validation is the harder cognitive task. We optimized the easy part and added load to the expensive one.

The teams handling this well aren't reviewing harder. They're instrumenting the review surface. They treat AI-generated changes as a distinct class with their own telemetry:

• Change failure rate tracked separately for AI-assisted versus human-authored work
• Churn measured on AI-touched files
• A clear policy on what an agent is allowed to merge without a human in the loop

You can't manage a risk you can't see, and right now most teams can't see which of their incidents trace back to code no human fully reasoned about.

The constraint that moved to requirements

The second place the bottleneck landed is further upstream, and it's the more interesting one. When implementation was the slow, expensive step, teams could be vague about requirements and absorb the cost later, during the long build, in hallway conversations and mid-sprint corrections. The build was slow enough to hide a lot of ambiguity. Agents removed that slack. When an agent implements a fuzzy requirement in an afternoon, the fuzziness doesn't get caught during a slow build anymore. It ships, fast, and the ambiguity surfaces in production.

This is why "intent engineering" is becoming a real role rather than a buzzword. The skill that's now scarce isn't writing code. It's writing a specification precise enough that a fast, literal, non-deterministic implementer can't misread it. That's an architecture skill, and it's the one I'd invest in if I were building a team for the next two years.

What the classroom shows that the dashboards don't

I teach at local colleges, and the split in the productivity data matches exactly what I see in a lab. Give a second-year student an AI assistant and they move faster, because they're doing bounded work where "plausible and almost right" is good enough to learn from. Give the same assistant to someone doing genuinely hard, context-heavy work, and it slows them down, because now they're validating output instead of reasoning forward. The tool is a force multiplier on whatever you already are. It multiplies a junior's output and a senior's review load.

That has a direct implication for how we build teams, and it's uncomfortable. The traditional path of "juniors write, seniors review" gets worse under AI, not better, because you've increased the volume of code needing senior review while making each review harder. If your plan for AI adoption is "juniors generate more, seniors check it," you've designed a system that maximizes load on your scarcest resource. The teams that get this right are inverting it: seniors use AI to draft and explore at the architecture level, where their judgment catches the failure early, and juniors learn to review before they learn to generate.

A note on non-determinism, because I've seen this movie

In the past, I built decentralized peer-to-peer communication infrastructure in the Ethereum era, before most of the current AI conversation existed. We shipped redundancy and assumed it bought us resilience. It didn't, because we hadn't instrumented the system well enough to know which node failed, when, or why. Redundancy without observability is just distributed failure with more moving parts.

AI agents in the pipeline are a non-deterministic component, and they deserve the same discipline. The same prompt and the same codebase can produce different output on different runs. That means an AI-assisted SDLC needs its own reliability budget, separate from your deterministic services, because the failure modes are different and the blast radius is harder to predict. If you can't answer "which agent produced the change that caused this incident, and can we reproduce the decision," you're operating the way we were at in my past role, and I can tell you how that ends.

So what do you actually do

You don't slow down adoption. You change what you measure.

• Stop reporting coding speed as a win on its own.
• Start tracking flow efficiency end to end, so the queue that AI created at review becomes visible instead of hiding inside a healthy-looking deployment-frequency chart.
• Separate your change-failure-rate telemetry for AI-assisted work so you can see the real defect cost before it surfaces ninety days out.
• Invest in the specification skill, because requirements quality is your new constraint whether or not you've named it.
• Give AI-generated change its own reliability budget, the same way you'd treat any non-deterministic component running in production.

The honest version of the AI productivity story isn't "it's overhyped" and it isn't "it changes everything." It's that AI made the cheap part of building software cheaper, which means the value, and the risk, both moved to the parts that were always hard: deciding what to build, and verifying that what got built is correct. Those were never the parts a faster typist could fix. I've been wrong about technology timelines before. But I'd bet the teams that win the next two years aren't the ones generating the most code. They're the ones who saw the bottleneck move and re-instrumented for where it went.

This is published in the same month the loudest AI jobs forecasts got walked back by the people who made them. That reversal surprised a lot of commentators. It shouldn't surprise anyone who measures systems for a living, and the reason why is what this piece is about. I've been watching machine learning since 2013, back when Coursera Machine Learning courses meant running gradient descent by hand on a laptop that sounded like it was apologizing. So I want to be careful about how I say this, because it would be easy to read it as a complaint. It isn't. AI-assisted development is real, and it's useful. But the story most teams are telling themselves about it is wrong in a specific, measurable way, and the cost of being wrong shows up about ninety days later. Here's the claim I keep hearing: AI made our engineers faster, so we're shipping faster. The first half is often true. The second half usually isn't. What actually happened is that the work got faster at one stage and the bottleneck moved somewhere you weren't watching.