Stop Using Pull Requests - by Andrea Laforgia

Andrea’s Substack

SubscribeSign in

Stop Using Pull Requests<br>Your team’s code review process is probably an expensive illusion of quality. Here’s what the evidence says, and what to do instead.

Andrea Laforgia<br>Mar 19, 2026

228

20

Share

“Inspection is too late. The quality, good or bad, is already in the product. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”<br>-- W. Edwards Deming, Out of the Crisis (1982)

Abstract

Pull requests have become the default code review mechanism in software teams everywhere. But the pull request was invented for open source projects, where strangers contribute code to repositories maintained by people who don’t know them. When private teams of trusted colleagues adopt the same process, they import a model designed for low trust into an environment that should operate on high trust. The result is a post-development inspection system that the evidence says catches few bugs, introduces enormous waiting time, incentivises large batches, and fractures teams into isolated individuals. Academic research, large-scale industry data from DORA, and a growing practitioner consensus all point in the same direction: there are better ways to build quality into software than inspecting it after the fact. This article examines the evidence and proposes an alternative — T*D, the union of Test-Driven Development, Trunk-Based Development, and Team-focused Development — as a path from slow, inspection-heavy workflows to fast-flowing teams that produce high-quality, safe systems.

TL;DR

Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.

Peer-reviewed research shows code review’s primary value is knowledge transfer, not bug detection. Less than 15% of review comments relate to actual bugs.

Async PR workflows mean your code spends 86-99% of its lead time waiting. One organisation spent 130,000 hours in a single year waiting on PRs that received zero comments.

DORA research across 36,000+ professionals shows trunk-based development correlates with dramatically higher software delivery performance, and faster code reviews alone improve performance by 50%.

The alternative is T*D: Test-Driven Development (build quality in), Trunk-Based Development (integrate continuously), and Team-focused Development (review during creation, not after).

The transition is gradual: optimise PRs first, adopt Ship/Show/Ask, then move to pairing and trunk-based development as trust and automation mature.

Deming wrote those words about manufacturing in 1982, but they describe what happens in most software teams today with uncanny precision. A developer writes code in isolation, on a branch, for hours or days. Then they open a pull request. The code sits in a queue. Someone eventually looks at it, leaves a few comments -- mostly about naming and formatting -- clicks approve, and the code merges. The whole process feels thorough. It feels like quality control. But the evidence suggests it is mostly theatre.<br>This article is not against code review. Code review has real value -- but that value is knowledge transfer and shared understanding, not catching bugs. And a blocking, asynchronous pull request is one of the worst possible mechanisms for achieving it.<br>What follows is a synthesis of peer-reviewed academic research, large-scale industry data, and practitioner experience spanning two decades. The picture that emerges is consistent and, for many teams, uncomfortable: the way most organisations practice code review is an expensive ritual that slows delivery, encourages large batches, fractures team cohesion, and produces a false sense of security. Better alternatives exist, and they aren’t theoretical -- they are practised successfully by high-performing teams around the world.

A Solution Designed for Strangers

Pull requests have a specific origin story, and understanding it explains why they are a poor fit for most teams.<br>Linus Torvalds created the git-request-pull command in 2005, shortly after releasing Git. Before that, open source projects used email-based patch workflows: contributors mailed diffs to a mailing list, and the maintainer decided whether to apply them. In 2008, GitHub launched the web-based pull request, making it dramatically easier to accept contributions from the outside world -- from people the maintainers did not know.<br>This was a genuine innovation for open source. The pull request was designed as a gatekeeper mechanism for untrusted contributors submitting code to repositories they don’t own. It solved a real problem: how do you safely accept code from strangers?<br>But then something happened. Git became the dominant version control system. GitHub became the dominant platform. And teams everywhere adopted the pull request as their default workflow --...