Reviewing AI Code Is the New Bottleneck

Last quarter I tracked my time across three consulting engagements. I spent 11 hours a week reviewing AI-generated code and under 8 writing my own. The ratio surprised me, and it changed how I think about developer productivity.

I track my time religiously on consulting engagements. Partly for billing, partly because clients like data when I tell them their process is broken. Last quarter I was juggling three projects — a fintech API rewrite, a healthcare data pipeline, and a developer portal for a mid-size SaaS company. All three teams had adopted AI coding tools within the past year. Claude Code, Cursor, Copilot — the usual stack.

When I tallied up my hours at the end of June, one number stopped me cold. Across all three engagements, I'd averaged 11.2 hours per week reviewing AI-generated code. I'd spent 7.8 hours writing code myself. The ratio had flipped without me noticing.

The old bottleneck versus the new one

Two years ago, code review was slow because humans write code slowly. A senior engineer might review three or four PRs a day between their own work. The bottleneck was throughput — not enough code, not enough reviewers, PRs sitting in queues.

Now the throughput problem is solved. A developer with an AI coding tool can produce a working PR in twenty minutes that would have taken half a day. The queue isn't empty because nobody's writing code. It's overflowing because everyone's writing code five times faster.

But the review still takes the same amount of time. Sometimes longer.

Why AI-generated code takes longer to review

This surprised me at first. You'd think code that passes tests and lints clean would be quick to sign off on. In practice, three things slow it down.

It looks plausible at every line. Human-written code has tells. You can spot a junior developer's PR by the variable naming, the function length, the places where they weren't sure and left a comment. AI-generated code is uniformly polished. Every function is a reasonable length. The naming is consistent. It reads like it was written by a competent mid-level engineer. That smoothness makes it harder to spot the places where something is subtly wrong — a missing edge case, a race condition, a query that works fine with 100 rows and will fall over at 100,000.

It doesn't know your system's history. On the healthcare project, an AI-generated service was doing date parsing with a clean, well-tested utility function. The problem: the team had a shared date library that handled the three different timestamp formats their upstream providers used. The AI's version handled two of them. It would have worked in every test we had. It would have failed in production on data from one specific lab provider that sends timestamps with timezone offsets in a nonstandard format. The only way to catch that is to know the system's history, which means a human reviewer who's been around long enough to remember the incident from nine months ago.

It makes confident architectural choices. When a human developer isn't sure whether to use a queue or a direct API call, they'll often ask in Slack or leave a question in the PR description. AI just picks one. Confidently. Sometimes it picks well. Sometimes it introduces a synchronous dependency where the team had deliberately kept things async, or adds a caching layer that conflicts with the invalidation strategy three services away. These choices don't show up as bugs. They show up as architectural drift that compounds over weeks.

What I changed

By the middle of the quarter, I'd adjusted my review approach. Three things helped.

First, I stopped reading AI-generated PRs line by line. Instead, I start with the diff summary and ask one question: does the shape of this change match what I'd expect? If someone asked for a new endpoint and the PR also introduces a database migration, a new caching layer, and a utility module, that's a red flag regardless of whether each piece is well-written.

Second, I started asking contributors to include a one-paragraph "intent statement" at the top of every PR: what problem does this solve, and what approach did you choose? Not what the AI chose — what you chose. If the developer can't articulate the approach independently of the generated code, they probably don't understand it well enough to own it in production.

Third, I pushed for architecture decision records on all three projects. Short documents — half a page — that capture choices like "we use event-driven communication between the billing and notification services" or "all date parsing goes through the shared temporal library." These give both humans and AI tools something to anchor against. They don't eliminate the review problem, but they make it faster to spot when generated code diverges from established patterns.

The productivity question

Here's what I keep turning over. The teams I worked with last quarter shipped more features than they would have without AI tools. That's not in dispute. But the total engineering effort didn't drop the way everyone expected. It shifted. Less time in an editor typing, more time in a review tool reading. Less time writing tests, more time wondering if the tests actually cover the failure modes that matter.

A recent developer survey found that the median developer now spends more hours per week reviewing code than writing it. That tracks with what I'm seeing on the ground.

I don't think this is a reason to stop using AI coding tools. But I do think we're in a transition period where the industry's productivity narrative is ahead of the reality. The bottleneck didn't disappear. It moved. And the new bottleneck — careful, context-aware review of plausible-looking code — is the kind of work that's genuinely hard to speed up.

What worries me is that most teams aren't measuring this shift. They see PRs getting merged faster and call it a win. Nobody's asking whether the review quality held up, or whether the architectural coherence of the codebase is drifting. Those are slower-moving metrics, and by the time they show up in incident rates or onboarding friction, the damage is months old.

If you're leading a team that's adopted AI coding tools, track the review hours. Not just how long PRs sit in the queue — how long humans actually spend reading them. That number might surprise you the same way it surprised me.