You Feel 20% Faster With AI. The Data Says You’re 19% Slower.

AI made one step in your workflow faster. Nobody checked what happened to the step right after it.

In 2026, LinearB studied roughly 8 million pull requests across more than 4,800 engineering organizations. Developers using AI tools felt about 20% faster. Measured against what actually shipped, they were closer to 19% slower. That’s a 39-point gap between the speed people believed they were working at and the speed the system was actually running.

Nobody lied on the survey. The tool really did make the writing part faster. That’s exactly the trap: one part of a system can speed up while the whole system slows down, and almost nobody notices, because they’re only watching the part that got faster.

This article isn’t really about AI. It’s about the skill that decides which side of that 39-point gap you land on — and it’s not the skill most people are currently racing to learn.

The 39-Point Gap

Look at the whole pipeline instead of one stage of it, and the mechanism stops being mysterious.

A telemetry study by Faros AI, covering more than 10,000 developers across 1,255 teams, found the same shape from another angle. Teams with the heaviest AI adoption completed about a fifth more work and merged nearly double the pull requests. Good news, on its face. But review time on those same pull requests rose by roughly 90%. The requests themselves grew about one-and-a-half times larger. Bug counts climbed too.

A 2026 benchmark from Opsera, built on a quarter-million developers across more than 60 organizations, found AI-generated pull requests sitting in review queues over four-and-a-half times longer — even as the time it took to produce a pull request dropped by more than half. Google’s own 2026 DORA research, drawn from over a thousand engineers, found something almost identical: heavier AI adoption tracked with higher throughput and higher instability, in the same teams, at the same time.

None of this is mysterious once you ask why. A 2026 developer survey found 96% of engineers don’t fully trust the functional accuracy of AI-generated code, and a CodeRabbit analysis of real pull requests found AI-authored code surfaces roughly 1.7 times more issues than human-written code. Sonar’s 2026 State of Code survey adds the other half of the story: fewer than half of developers say they always check AI-assisted code before committing it. Put those three together and the queue backing up at review stops looking like a glitch. It’s the rational response to code nobody fully trusts yet, moving through a pipeline that was sized for the old trust level.

Multiple organizations, multiple datasets, one pattern. Writing code got cheap. Reviewing it didn’t. The queue simply moved desks — from the person typing to the person checking the work — and barely anyone budgeted for that when they rolled the tools out.

This isn’t a new problem wearing a new name. Eliyahu Goldratt laid it out in 1984, in a book about a factory, not a codebase: a system’s total output is capped by its slowest, most constrained step, and speeding up any other step only makes that constraint more visible, not less real. Coding was never the constraint. It just used to be slow enough to hide that fact.

The Constraint Doesn’t Sit Still

Here’s the part that should really unsettle you: even “review is the new bottleneck” might already be one layer too shallow.

One 2026 industry report found that most engineering teams now believe their constraint shifted from writing code to reviewing it. A separate analysis pushed back on that framing directly, arguing that in plenty of organizations, the real constraint sits one step further downstream — in how many changes get batched into a single deployment. Speed up review without touching that, and you’ve just built a faster on-ramp to the same traffic jam.

That’s the whole game. A constraint doesn’t disappear when you fix it. It relocates to wherever nobody’s measuring yet. Chase only the part you can see, and you can spend years “fixing” a system that never actually gets faster, because you keep optimizing a step that was never really holding anything back.

It’s Not Just a Coding Problem

If you don’t write code for a living, none of this should feel like someone else’s problem. The same shape shows up anywhere a task gets radically cheaper without anyone checking what happens to the step right after it.

Customer support is the clearest example. Plenty of teams made “ticket deflection” — the share of questions a bot resolves without a human ever seeing them — their headline automation metric. But when a bot fails to actually solve someone’s problem and just doesn’t route them to a person, the dashboard logs a win: no ticket. The business logs something else entirely: a customer who quietly won’t be back. That’s Goodhart’s Law, showing up in a support queue. The moment “tickets deflected” became the target, it stopped measuring the thing anyone actually cared about — whether the problem got solved.

And the tickets that still reach a human now are the ones AI couldn’t touch: the ambiguous, the emotionally loaded, the ones with real money or liability attached. Funmi Mide-Ajala, a customer support and digital operations director, made the point plainly in a recent interview: ticket counts can fall while the emotional weight of the job climbs, precisely because the easy tickets are the ones that vanished. Fewer tickets. Harder job. A dashboard that says things are improving, sitting directly on top of a team that’s quietly burning out.

Marketing teams are hitting the same wall from a different angle. AI made publishing cheap — more posts, more ad variants, more social copy, all drafted in a fraction of the time. The bottleneck didn’t disappear; it moved into editorial review, brand-voice checking, and increasingly into whether search engines and social platforms even want to distribute mass-produced AI content in the first place. Speeding up the writing step doesn’t help much if the next step in line — a person deciding what’s actually worth publishing — was the real constraint all along.

What “Systems Thinking” Actually Means

Strip away the jargon and it’s simpler than it sounds. A system isn’t just a list of parts. It’s the parts, plus the connections between them, plus whatever the whole thing is actually for. Behavior comes out of how the parts interact — not from any single part in isolation.

Donella Meadows, who spent a career studying exactly this, made a point worth sitting with: where you intervene in a system matters more than how hard you push. Automating a step that was never the constraint is a low-leverage move dressed up as a high-leverage one. It feels like progress, because a number went up. Whether the system actually improved depends entirely on what that step was connected to.

None of this is new to AI, either. In 1865, William Stanley Jevons noticed that more efficient steam engines didn’t reduce coal consumption — they increased it, because cheaper power meant people used far more of it. Efficiency at the component level doesn’t guarantee slack at the system level. Often it just reveals demand nobody knew was sitting there. Every “AI made X free” story deserves the same question people should have asked about coal in the 1860s: free for whom, exactly, and where does the resulting demand actually land?

Why This Gets More Important, Not Less

If one AI tool can relocate a bottleneck without anyone noticing, multiply that by however many tools now sit inside a single workflow. The agentic tools spreading through 2026 don’t just speed up one task — they chain several together, handing work from one step to the next and looping in a person only at the end.

That’s more leverage, and also more places for a bottleneck to hide. An agent that drafts, an agent that checks facts, an agent that formats, a human who approves at the very end: every handoff in that chain is a spot where volume, error, or risk can quietly pool up while every dashboard still reads green. The more of the pipeline you hand off, the fewer parts of it you’re personally watching — which makes it more important, not less, that someone on the team is watching the whole chain instead of just their one link in it.

That’s the opposite of how most people are approaching AI skill-building right now. The instinct is to get better at directing any single tool. The actual need, as more of the pipeline goes autonomous, is to get better at knowing which part of that pipeline still needs a human pair of eyes.

The Question That Filters for This Skill

You don’t need a framework to start. You need one habit: whenever a task gets radically faster, ask “where does it go now?” before you celebrate.

A short version of that question, in practice:

• What’s the very next step downstream, and can it actually absorb two or three times the volume this step now produces?
• What are we not measuring that would show the real cost — review time, churn, burnout, security bugs — if we looked?
• Is the metric everyone’s celebrating a stand-in for something we care about, or has it quietly become the goal itself?
• If this breaks somewhere nobody’s watching, who finds out first, and how late?

None of these questions require technical depth. They require the discipline to look one step past whatever you just made faster, every single time, even when the number right in front of you looks great.

How to Actually Practice It

This is a skill you build through repetition, not a course you finish. A few ways to actually start:

• Pick one workflow you’ve sped up with AI recently and draw it — boxes and arrows, on paper, marking where volume enters and exits at every stage. Most people have never drawn their own workflow, not once.
• Borrow a page from Wardley Mapping, a strategy technique built for exactly this: before automating a step, map what it actually depends on, so you can see what absorbs the extra load before you find out the hard way.
• Every time you hear “we automated X,” ask what grew as a result and where it landed. Practicing this on someone else’s story is lower-stakes than practicing it on your own.
• Get comfortable saying “the constraint moved” out loud, in a meeting, before someone more senior has to say it for you.
• Instrument the step after the one you just automated, not only the one you automated. If you can’t see backlog, error rate, or morale downstream, you’re flying blind on exactly the part that now matters most.

None of this is exotic. It’s paying attention to the whole pipe, instead of just the one valve you personally control.

The Actual Takeaway

Prompting is the skill everyone’s racing to learn, and it’s genuinely useful. It’s also cheap, fast to pick up, and getting more automatable by the month. Systems thinking runs the other way: slower to build, and it’s the entire reason two people can use the exact same AI tool and get completely different results six months later. One of them made a task faster. The other made a system better — and can actually tell you the difference.

You Feel 20% Faster With AI. The Data Says You’re 19% Slower. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.