# Stop Using Pull Requests

[[andrea-laforgia-blog|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:

1. **Optimize PRs** — small (<200 lines), 4-hour SLA, automated style/lint, one required approver.
2. **[[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).
3. **Pair programming + TBD** — pair on production code, multiple trunk merges/day, post-commit review for unpaired work.
4. **Ensemble programming + TBD** — whole team co-creating, continuous review, direct trunk commits, feature flags.
5. **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.