Why your team doesn't need to use pull requests

infrastructure-as-code.com (Kief Morris) · article · 2021-01-02 source ↗ Reader 🖥️

Feedback Loops Pair & Mob Programming Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Pull requests were designed to vet contributions from untrusted outside contributors, so applying them to a trusted team's own code sacrifices Continuous Integration's fast feedback and flow for no corresponding risk-reduction benefit; teams should instead integrate continuously and get code review through pairing, periodic group reviews, or post-integration pipeline approval gates.

practical · argumentative — Argues for a specific team practice (adopt CI over PR gating for trusted team members) using a historical/origin argument plus a flow/feedback-delay comparison.

Structure

Part	Role
Origin story: GitHub built pull requests to let maintainers safely accept patches from untrusted outside contributors.	context
Claim that many teams now apply PRs to their own trusted members by default, including the 'airport security for family' analogy.	thesis statement
Definition and mechanics of Continuous Integration (merge + test at least daily, fast automated feedback).	evidence/context
Side-by-side delay comparison: PR turnaround (~30 min best case, often much worse) vs. CI feedback (minutes) vs. the daily-integration requirement most PR workflows violate.	evidence
Three alternative review mechanisms that preserve human review without delaying integration: pair programming, periodic (e.g. weekly) group reviews, and post-integration pipeline approval gates.	solution / rebuttal to 'but we need review'
Conclusion: review timing can move (synchronous during authoring, or after integration/test) without needing to be a pre-integration gate; a faster loop encourages smaller, more frequent, higher-quality commits.	conclusion

Key terms

pull request Pull Requests & Async Code Review
A batch-and-wait control: a proposed change packaged as a reviewable unit that a human must approve before it is merged into the mainline — originally built to assess unknown outside contributors, not team insiders.
Continuous Integration (CI)
Integrating and automatically testing every team member's code against the mainline at least once a day (not once per finished feature) so that conflicts and defects surface within minutes — a flow/feedback optimization, not merely 'having a CI server.'
trunk / mainline
The single shared integration branch that every team member's work merges into, ideally daily.

Propositions

explicitPull requests were designed to let maintainers vet contributions from untrusted outside contributors, not to review work from trusted teammates.conf: high
supportsFrom Async Code Reviews to Co-Creation Patterns · p13 — Both independently locate the root problem in the same historical mismatch: PR workflows were built for asynchronous strangers (open source), not product teams with shared norms.
explicitUsing pull requests to review your own team's code is like making family members pass through airport security to enter your home — a costly control applied to a problem (untrusted actors) that doesn't exist on your own team.conf: high
explicitA pull request introduces a delay between finishing a change and getting it integrated and tested with the rest of the team's current work, which Continuous Integration is designed to avoid.conf: high
explicitEven an optimistic 30-minute PR review turnaround is slower than CI's near-immediate (minutes) feedback, and most teams don't reliably achieve even that 30-minute turnaround.conf: high
supportsFrom Async Code Reviews to Co-Creation Patterns · p6 — Morris's informal 30-min-vs-minutes delay comparison is the same mechanism the later article formalizes into a ~7.7% flow-efficiency figure under modest async delay.
explicitThe typical PR workflow — one pull request per completed feature or story, taking more than a day — violates Continuous Integration's requirement to integrate everyone's work into the mainline at least daily.conf: high
explicitSwitching away from a change while waiting for PR review, then switching back when a problem is found, disrupts flow in a way that immediate CI feedback avoids.conf: high
explicitA second pair of eyes catches real problems (maintainability, design soundness) that automated tests cannot — this is a genuine benefit of human review, independent of whether review is used as a pre-integration gate.conf: high
explicitPairing, periodic (e.g. weekly) group reviews, and post-integration pipeline-approval gates each provide meaningful human code review without delaying the CI integration/feedback loop, and can be combined.conf: high
supportsOn Pair Programming · p1 — Morris already lists pairing as a review alternative that avoids PR's delay cost; the later, pairing-focused article builds the fuller case for pairing as the default.
explicitA faster, more frequent coding-integration-feedback loop (enabled by CI, discouraged by PR batch-and-wait) encourages smaller, more frequent commits, which improves both quality and flow.conf: high
supportsFour Eyes Without Pull Requests · p8 — Morris's claim that a faster loop drives smaller, more frequent commits anticipates the later article's observation that high performers favour smaller batches and more frequent integration.
implicitReview-as-pre-integration-gate and review-as-quality-practice are separable: you can keep the second while dropping the first.conf: medium

Arguments

A team whose members share norms and trust should default to Continuous Integration rather than pull requests for integrating code. strength: high

Explicit premises:

PRs were built to manage risk from untrusted outside contributors.
PRs introduce an integration delay that CI is specifically designed to eliminate.
That delay disrupts flow (context-switching) and slows discovery of integration problems.
Review quality can be preserved through pairing, periodic reviews, or post-integration pipeline approval instead of a pre-integration PR gate.

Implicit premises:

The risk profile that justifies a pre-integration human gate (unknown contributor intent/quality) does not apply to a team that already shares norms and direction.
The cost of integration delay (slower feedback, flow disruption, bigger inventory/batches) generally outweighs whatever marginal extra safety a pre-integration gate adds for trusted insiders.

Inferences:

If delay-before-integration is the real cost of PRs, any review mechanism that delivers human review without sitting between 'done' and 'integrated' (pairing, post-hoc pipeline approval) should be preferred over a classic PR gate for internal teams.
Teams in regulated contexts that do require a pre-merge human sign-off as an audit artifact face a genuine exception the article doesn't resolve — satisfying that requirement without reintroducing PR's delay is a separate design problem.

Narratives

Making family members go through an airport security checkpoint to enter your own home.
→ Makes vivid, in one image, the proposition that PR-as-default misapplies a control designed for untrusted outsiders to people who have already earned trust.

Questions addressed

✅ Does code need a second human to look at it before it ships?
Yes — but 'needs review' and 'needs a pre-integration approval gate' are treated as separable requirements.
✅ Is the pull request the only (or best) way to get that second pair of eyes?
No — pairing, periodic review, and pipeline approval gates all provide it without CI's delay cost.
⭕ What should a team do when a regulator or compliance framework explicitly requires a second-person sign-off as an auditable record?

Gaps

incompleteThe article flags regulated environments as an exception ('having each change reviewed by a second person is required') but doesn't say how to produce an audit-grade review record without reintroducing the PR gate it argues against for everyone else.
Read next: extract-four-eyes-without-pull-requests.json (Laforgia) resolves exactly this, five years later, with a five-piece composite control (policy, commit trailers, automated enforcement, telemetry, sampling audit) that satisfies ISO 27001/SOC 2 four-eyes requirements without a PR approval artefact.
incompleteWritten in 2021, the piece has no notion of AI-generated code volume — it assumes a human author producing a human-scale rate of changes. It doesn't anticipate that when an agent can produce a day's worth of code in minutes, the CI-vs-PR delay math it relies on (humans reviewing within 30 minutes vs. 'minutes' for CI) changes shape entirely.
Read next: extract-agentic-ai-and-code-reviews.json and extract-dora-2025-state-of-ai-assisted-software-development.json address how review must reorganize when code-generation volume outpaces human attention.

Closes gaps elsewhere

From Async Code Reviews to Co-Creation Patterns · g3 — Morris explicitly describes the trunk-based-plus-light-review hybrid that gap asks about: continuous integration to mainline combined with post-integration review (periodic group reviews, or a pipeline approval gate placed after code is already integrated and tested) — rather than framing Pair/Mob as the only non-PR alternative. Feature flags specifically are still not addressed.