Every Layer of Code Review Makes You 10x Slower. Here's What to Do About It.

You fix a bug in 30 minutes. Your peer reviews it in 5 hours. Add an architecture sign-off? That's a week. Need another team's approval? Welcome to quarter-long delivery cycles.

This isn't hyperbole—it's math. And according to Avery Pennarun, CEO of Tailscale and veteran systems engineer, every additional layer of review in your process makes you roughly 10 times slower. Not 10% slower. Ten. Times.

His recent blog post, "Every layer of review makes you 10x slower," struck a nerve across the engineering community precisely because it articulates what so many developers already feel: our review processes have become the bottleneck, not our ability to write code.

The 10x Rule You've Never Heard Of

Pennarun's observation isn't backed by academic research—it's something even more valuable: decades of pattern recognition across real engineering organizations. The progression he outlines is painfully familiar:

The culprit isn't the review itself—it's the wall clock time. Most of those hours are spent waiting, not working. And here's the kicker: this pattern holds remarkably consistent regardless of whether you're at a 50-person startup or a 5,000-person enterprise.

According to research on GitHub PR metrics, the median pull request takes 14 hours to merge, with PRs over 50 lines taking up to 19 hours. That's for a single review layer. Stack another approval gate on top, and you're not adding hours—you're adding days or weeks.

Why We Can't AI Our Way Out

You might think AI code generation solves this. Claude writes your fix in 3 minutes instead of 30, right? Wrong problem.

As Pennarun notes in his post, "you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI... or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you're making them read the slop that you were too lazy to read yourself."

The bottleneck isn't code generation—it's the approval pipeline. Speed up the input and all you've done is create a bigger queue. Some teams are responding by reducing code review rigor, betting that if AI-generated code is 100x cheaper, it only needs to deliver 1% of the value to break even.

That's a dangerous bet. Lower quality compounds. Bugs beget more bugs. Technical debt accumulates interest.

The Quality Paradox

Here's where it gets interesting. Most organizations add review layers specifically to improve quality. More checkpoints mean catching more bugs, right?

Not according to W. Edwards Deming, the quality management pioneer who transformed Japanese manufacturing. Pennarun references Deming's insight that "Quality Assurance" inspection passes actually reduce quality. Why? Because when you separate creation from quality control, you create a system where:

The alternative Deming championed—and that companies like Google and Facebook have adopted—is building quality in at the source. Both tech giants use trunk-based development with mandatory code review, but they've optimized for speed. Reviews happen quickly, PRs stay small, and developers maintain ownership of quality.

What Actually Works: Four Strategies

If you're managing a team or influencing engineering culture, here's how to escape the review layer trap:

1. Ruthlessly Eliminate Unnecessary Approvals

Ask for each review stage: What unique value does this add? If the answer is "oversight" or "visibility," that's not a valid reason. Those are solved with better communication tools, not blocking workflows.

One review layer (peer review) is almost always necessary. Two layers (peer + lead/architect) should require strong justification. Three or more layers are organizational dysfunction masquerading as quality control.

2. Optimize for Latency, Not Just Effort

Track time to merge, not just code review hours spent. A review that takes 30 minutes of effort but happens 2 days after the PR opens is worse than a 1-hour review that happens within 2 hours of submission.

Set team SLAs: first review within 4 hours, follow-up within 2 hours. Make review latency as visible as deployment failures.

3. Build Quality Upstream

Invest in what Deming called "process capability"—making it easy to do the right thing:

4. Match Process to Risk

Not all code needs the same scrutiny. A bug fix in a well-tested utility function is different from a new authentication system. Create lightweight paths for low-risk changes:

The key is being explicit about risk levels, not making developers navigate political judgment calls.

The Trust Problem

Ultimately, excessive review layers signal a trust problem. You either trust your team to make good decisions, or you don't. If you don't, adding process won't fix it—hiring better people and improving your onboarding will.

Pennarun observes that executives above medium-sized teams face 2.5-year cycles for major initiatives when filtering through layers of organizational approval. Those same executives then wonder why their companies can't move fast.

Speed is a feature. Velocity is a competitive advantage. And in 2025, with AI accelerating the code generation piece of the equation, the teams that win will be the ones who solved the review latency problem while everyone else is still stuck in their approval queues.

What You Can Do This Week

If you're an IC: Track your PR turnaround times. When you see delays, ask why—and whether that review layer is actually adding value. Propose concrete alternatives.

If you're a tech lead: Audit your team's approval process. Map out every required sign-off and its median latency. Pick one layer to eliminate as an experiment.

If you're in management: Make review latency a team metric. Celebrate fast reviews as much as good code. Question any process that adds more than one layer of human approval.

The 10x rule is annoyingly true because organizations designed it to be true. The good news? It's also completely within your power to change.