Stop Using Pull Requests

Summary

“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.”-- W. Edwards Deming, Out of the Crisis (1982)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.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 al...