Business Insider ran a piece on Monday that should make a few engineering leaders uncomfortable: the hidden cost of the AI coding boom isn’t a technical one. It’s human, and it looks a lot like paralysis.

Tim Paradis and Thibault Spirlet tell it through real engineers. The first reaction to every new tool isn’t “this is exciting,” it’s “I’m behind.” Model releases went from 18 in 2023 to 69 in 2025. Nobody finishes evaluating last week’s release before this week’s lands.

But the paralysis isn’t the AI’s fault. And the fix isn’t another tool either. It’s a system the team owns, with review and ownership built into it. Here’s why.

The bottleneck moved, and almost nobody reorganized around it

Gergely Orosz, who writes the most-read engineering newsletter in the industry, put it plainly: typing speed was never the bottleneck. Writing the code was always the fast part. The slow part was always understanding it, reviewing it, and deciding whether it belongs in production.

So AI shows up and solves the part that was already fast. It generates code at twice the rate it did six months ago. And the slow part? Still just as slow, because review requires a human to load the full context into their head, and that doesn’t accelerate with a larger model.

The outcome is predictable. CIO ran a headline that says it all: “AI killed the code review.” PRs pile up or get rubber-stamped. The review queue is the new bottleneck, and most teams just dumped more output on top of it without touching the queue itself.

This is the same point I make from another angle in the four loops that replaced prompt engineering: the value lives in closing the review-and-correct loop with judgment, not in generating faster. Generation is the easy step. It always was.

What the speed hides

Here’s where the “AI made us 10x more productive” story collides with the data.

METR ran a controlled study with experienced developers working in real repos over a million lines long. The result stings: they were 19% slower using AI. And the most revealing part isn’t the slowdown. It’s that they believed they had been 20% faster. A gap of nearly 40 points between what they felt and what happened.

That gap is paralysis in its purest form. It’s not that the team stops working. It’s that it works with the feeling of flying while moving less, and nobody notices until the calendar doesn’t add up.

GitClear analyzed 211 million lines of code and measured the fingerprint: copy-pasted code went up, duplicated blocks multiplied, and the code that gets moved or refactored (the signal that someone is cleaning up, not just adding) dropped by half. More volume, less care.

Google’s DORA 2024 report confirms it at the delivery level: for every increase in AI use, they measured a drop in delivery throughput and a larger drop in stability. AI pushes the size of each change up, and big batches are harder to review and easier to break.

None of these three numbers says “AI is bad.” They say something more uncomfortable: AI is excellent at accelerating the half of the work that was already fast, and that throws the whole system off balance if you don’t redesign the other half.

Cognitive debt is not technical debt

In the comments under that same Business Insider piece, Jean-François Bernier dropped the best line in the whole thread. He said engineers aren’t overwhelmed by AI itself, but by the expectation that they absorb every new tool, agent, and benchmark the moment it ships. And he named it: that isn’t learning anymore. It’s cognitive debt.

It’s worth separating the two kinds of debt cleanly, because people conflate them and they’re nothing alike.

Technical debt lives in the code. It’s ugly, duplicated, untested. A linter catches it, a refactor pays it down.

Cognitive debt lives in the team. It’s the understanding you lose when you delegate so much that you stop grasping what you ship. No linter catches it. It shows up the day something breaks in production and the person who approved the PR can’t explain why the code did what it did, because they never loaded it into their head. They just let it through.

The MIT Media Lab published a preliminary study (not yet peer-reviewed, so treat it as a signal, not proof) that measured exactly this with EEG: the group that leaned hardest on the model showed lower brain connectivity and worse recall of what they had just produced. They called it, fittingly, cognitive debt.

This connects directly to the line I drew between cognitive delegation and cognitive surrender: delegating execution is fine; surrendering judgment is where the trouble starts. A team approving code it doesn’t understand is surrendering rather than delegating, and it does so very efficiently.

What we do differently at IQ Source

The lesson isn’t “slow the AI down” or “review more carefully.” It’s to build a system instead of buying another tool, which is the same thesis I made when Block built Builderbot instead of buying a chatbot.

A system, here, means concrete things. It means work loops where review isn’t an optional final step but part of the loop. It means everything the agent ships has a human owner who understands it, not just someone who approved it. It means explicit quality criteria defined before anything gets generated, so that reviewing isn’t reading eight pages blind but comparing against a reference that already exists.

And it means changing the metric. As long as you measure how many lines or how many PRs your team produces, you’re measuring the easy thing. The metric that matters is how much of the code reaching production has someone who understands it and answers for it. That measures coherence, not volume. And coherence is the first thing to break when speed goes up without the system changing.

That’s what we design in the first phase of AI Maestro: we don’t plug in an agent and wish you luck. We map your real processes, define the criteria you’ll use to evaluate what the agent produces, and build the review system that turns AI’s speed into real progress instead of a queue of unopened PRs.

If your team feels like it’s producing more than ever but getting less far, the AI isn’t failing. You bolted a race engine onto a review process that still walks. Fix the queue, not the engine.

Let’s fix the review queue, not the engine