Stop Using Pull Requests

Andrea Laforgia's March 2026 substack essay assembles two decades of peer-reviewed research, large-scale industry data (DORA, Microsoft, ThoughtWorks), and practitioner consensus to argue that the standard pull-request workflow is Deming's "inspection after the fact" — and that better practices already exist. The piece is not anti-review; it is anti-blocking-async-PR-as-default.

The category-error origin

git-request-pull (Torvalds, 2005) and GitHub's web PR (2008) were designed as a gatekeeper mechanism for untrusted contributors submitting code to repositories they do not own. That was a genuine innovation for open source. The category error is teams of trusted colleagues importing the same model internally — they get the friction without the trust mismatch the friction was solving.

Thierry de Pauw's framing: "Pull requests are designed to make it easier to accept contributions from the outside world, from untrusted people we do not know about." When applied to a team that hired each member for trusted competence, the model imports the wrong assumption.

This is the same structural critique i-dont-want-your-prs makes from the maintainer's side, except Laforgia's piece pre-dates the LLM angle and grounds the case in classical software-engineering research.

The bug-catching myth

The most common stated justification for code review is "to catch bugs." The peer-reviewed evidence says this is largely wrong:

Microsoft Research 2015 ("Code Reviews Do Not Find Bugs"): only a small percentage of review comments relate to bugs; most are structural and style issues.
Bacchelli & Bird 2013 ("Expectations, Outcomes, and Challenges of Modern Code Review"): <15% of issues discussed in reviews relate directly to bugs. The primary benefits are knowledge transfer, team awareness, and alternative solutions.
One unnamed major tech company, after analyzing 9 million code reviews: knowledge transfer is the primary source of ROI. Up to 75% of comments affect evolvability/maintainability rather than functionality.

The piece is careful: this doesn't make code review worthless. It locates its value in code-review-knowledge-transfer — and a blocking async queue is one of the worst possible mechanisms for that.

The waiting-time math

If a change takes 10 min to write but waits 1 hour for review, the code waits for 86% of its lead time. If review takes one working day, the code spends 99% of its existence waiting for a human.

Fowler's client number that anchors the piece: 130,000 hours in 2020 waiting for 7,000 PRs that received no comments at all (91% of their PRs). The vast majority were rubber-stamped, yet still imposed the delay.

The damage compounds via context switching: developers wait an average of 4 days; 86% of PRs are handled under context-switching conditions; context-switching PRs are 223% slower than non-context-switching ones. Rebuilding mental context after a PR opens takes 30-60 minutes if it happens at all.

Reinertsen's lens (Principles of Product Development Flow): PRs create a perverse incentive toward larger batches. Because the transaction cost of getting a review is high, developers batch more changes into each PR to amortize it. Larger PRs review worse. Cycle reinforces.

Dragan Stepanovic's observation across 30+ repos: teams with small async PRs sometimes have lower throughput than teams with large PRs, because waiting → high WIP → less review availability → more handoffs → more waiting. The team becomes "N teams of one person."

The DORA evidence

Accelerate (Forsgren, Humble, Kim, 2018) and successive DORA reports across 36,000+ professionals:

Trunk-based development correlates with higher delivery performance across every metric.
Elite performers meeting reliability targets are 2.3× more likely to use trunk-based-development.
The DORA capabilities framework explicitly names "heavyweight code review processes" as a barrier.
Accelerating code review alone improves software delivery performance by 50% (2023 report). The problem is the speed, not review itself.

Caveat the piece makes honestly: DORA is correlational. High-performing teams that adopt TBD may be better-funded or better-cultured. But consistency across years and tens of thousands of respondents makes it the strongest industry evidence available.

The T*D alternative

Laforgia coins T*D as the union of three practices sharing the same initials and the same shift-left philosophy:

Test-Driven Development — Microsoft/IBM studies: 40-90% defect reduction at 15-35% more dev time. Every line satisfies a test before it reaches anyone; no human gatekeeper needed for "does it work."
Trunk-Based Development — daily integration to mainline, branches under a day, feature flags for incomplete work. See trunk-based-development.
Team-focused Development (pair-programming, ensemble/mob programming) — review happens during creation, not after.

The crucial empirical claim is Muller & Tichy (2005): pair programming and solo programming with peer review achieve equivalent cost at equal quality. The review phase for solo work adds enough overhead to match pairing. So pairing doesn't add cost; it relocates QA from after development to during it.

Laforgia is honest about a gap: no peer-reviewed study has directly proven teams can safely eliminate post-hoc review when practising pair programming. The full claim is practitioner consensus extending the cost-equivalence finding.

The five-stage transition

The piece is unusually careful about teams that aren't ready to drop PRs:

Optimize PRs — small (<200 lines), 4-hour SLA, automated style/lint, one required approver.
ship-show-ask (Wilsenach) — categorize changes: ship (merge without review for routine), show (merge immediately, review post-merge), ask (open PR and wait for complex/uncertain).
Pair programming + TBD — pair on production code, multiple trunk merges/day, post-commit review for unpaired work.
Ensemble programming + TBD — whole team co-creating, continuous review, direct trunk commits, feature flags.
Full T*D — all three practices together, fast automated pipeline.

Thierry de Pauw's "non-blocking continuous code review" sits between stages 2 and 3: reviews happen on mainline post-merge, on a per-feature level, no hierarchical requirements (juniors review seniors and vice versa), unreviewed code may reach production if automated tests pass. One organization's internal auditors found this superior to traditional checkbox-based compliance.

The trust gradient

Laforgia rejects the binary framing his own argument seems to imply. Trust is a gradient:

Small co-located team that pairs daily → case against async PRs is strongest.
Large org with many teams → cross-team contributions may still warrant lightweight PRs with fast SLAs.
Inner-source / platform teams accepting semi-external contributions → some gatekeeping remains defensible.
Distributed teams with timezone overlap → pair during overlap, non-blocking review outside it.
Minimal-overlap distributed teams → async PRs may be least-bad, but should still be optimized aggressively.

The antipattern diagnosis applies most strongly to same-team, same-context work where async blocking PRs replace trust that should already exist.

Connections in the wiki

i-dont-want-your-prs — Ciężarkiewicz attacks the maintainer side of OSS PRs from the post-LLM angle; Laforgia attacks the internal-team side from the classical-SWE-research angle. Different premises, same target.
agent-principal-agent-problem — Crawshaw on how agents collapse the effort signal that made review-then-commit work; Laforgia's piece doesn't go there but the two stack neatly (agents kill review-as-effort-signal, but the signal was already weak per Bacchelli & Bird).
stacked-prs / billjings-git-not-fine — Jings argues git lacks the primitives PRs need; Laforgia argues the workflow itself is wrong. Both arrive at "the PR ceremony is overhead."
no-silver-bullet-llms — Bennett's piece, separately, on DORA's recent inversion under LLM-assisted coding.
cult-of-vibe-coding, clean-code-coding-agents — adjacent threads on what review is for in a post-LLM world.

What's new vs already known

The arguments aren't novel — Fowler, Farley, Kerr, de Pauw, Stepanovic, Hammant, and the Minimum CD initiative have been writing this for years. What Laforgia adds is a single document that:

Cites the actual peer-reviewed studies (rather than the practitioner blog chain).
Names the bug-catching myth concretely (<15%, 1.5M comments, 9M reviews).
Quantifies the waiting cost (the 130,000-hour number).
Lays out an honest five-stage transition that doesn't pretend trust is binary.
Acknowledges where the evidence has gaps (no direct study replacing PRs with pairing).

The piece is a good single-link reference when someone asks "why are PRs bad for an internal team?" without committing to read four blog posts and a DORA report.