Post-Commit Reviews != Post-Deployment Reviews

Cindy Sridharan · article · 2020-07-14 source ↗ Reader 🖥️

Human-in-the-Loop Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Mandatory pre-commit code review trades developer velocity for a quality guarantee that is weaker than assumed, because review's real value is mostly knowledge transfer rather than defect detection and automated post-commit testing already catches most of what unit tests miss -- so teams should default to post-commit review (reviewing after merge to trunk, but still before or shortly after deploy), which is a distinct and more flexible choice than the commonly conflated 'post-deployment review,' and which preserves the four-eyes control while restoring developer and reviewer focus, provided the team has the trust and automation investment to make reverts safe.

practical · argumentative — Argues for a specific practice choice (prefer post-commit review over mandatory pre-commit gating), built on a mix of cited studies, the author's own experience, and worked examples (Quora, Uber, AWS).

Structure

Part	Role
Opening frame: surprise that AWS's otherwise highly automated CI/CD pipeline still mandates pre-commit review	hook / motivating observation
Code review and developer velocity: citing a 2016 Microsoft study on what review actually delivers, and the latency cost of mandatory pre-commit gating	evidence undermining the default assumption that pre-commit review is costless
Definitional move: post-commit reviews != post-deployment reviews, with the two concrete variants (post-commit/pre-deploy vs. post-commit/post-deploy)	conceptual clarification -- the article's core original contribution
Benefits of post-commit review: developer/reviewer focus, forcing-function toward better development culture, and compatibility with stronger automated pre-review testing	evidence for the practice
Challenges of post-commit review: requires high trust, careful onboarding, and heavy investment in automated revert/monorepo tooling (Uber SubmitQueue example)	qualification -- names the real cost of the practice
Conclusion: both post-commit flavors can improve iteration speed, but require time and investment to get right	conclusion

Key terms

Post-commit review
Code review that happens after a change has already been merged to the trunk/mainline branch, with reviewer comments addressed in follow-up commits -- as opposed to review gating the merge itself.
Post-commit, pre-deploy review
Review happens after merge to trunk but is still the last gate before the code is deployed to production -- review is decoupled from the merge event but not from the deploy event.
Developer focus
The state in which neither the author (waiting for merge approval) nor the reviewer (interrupted every 10-15 minutes) is context-switched by the review process -- achieved by batching small, frequent merges and reviews.

Propositions

explicitMandatory pre-commit code review hinders developer velocity almost invariably, because CI plus review turnaround routinely takes minutes to days rather than the seconds required for review to be effectively free.conf: high
supportsAgentic Code Review · p2 — This 2020 article documents the pre-AI baseline the newer piece names explicitly: review latency (not reviewer overload) was the main cost of pre-commit gating, in a world where a reviewer could still read faster than an author could write. It is the 'before' half of the precondition extract-agentic-code-review says no longer holds.
explicitCode review's actual, measured benefit is mostly knowledge transfer, team awareness, and improved solutions -- not defect detection, which comprises only a small proportion of review comments.conf: high
explicitPost-commit review is not the same thing as post-deployment review: a team can defer review past the merge event while still requiring it before deployment, which is a different and more broadly applicable choice than deferring review past production deployment itself.conf: high
supportsFour Eyes Without Pull Requests · p1 — Both pieces independently make the same structural move: separating the compliance/control objective (four-eyes review, an audit trail) from the specific mechanism (a pre-merge PR gate) that is commonly but not necessarily how that objective gets satisfied.
explicitPost-commit review's primary benefit is developer and reviewer focus: batching frequent small merges and reviews removes the interruption cost on both sides and reduces reviewer nitpicking, because reviewers only comment on merged changes that raise genuine concerns.conf: high
extendsOn Pair Programming · p3 — Sridharan's 'developer focus' case for post-commit review and the pairing article's case for continuous-pairing-plus-trunk-based-development both argue that batching or eliminating a discrete pre-merge review gate is what frees developer attention -- this article supplies the velocity-cost mechanism (CI + review turnaround latency) that the pairing article's argument assumes but doesn't quantify.
explicitA working post-commit review culture requires prior cultural investment -- agreed design documents before implementation, consensus on style/idioms, and strong automation -- and functions as a forcing function toward better development practices rather than a way to skip them.conf: high
explicitAutomated post-commit, pre-review testing (integration, load, soak, shadow tests) can catch more bug categories than pre-commit unit tests alone, which lets the human reviewer focus only on what automation structurally cannot catch -- security bugs and business-logic errors.conf: high
explicitPost-commit review works best in high-trust teams and is not a safe default for new or junior team members, who should be onboarded via pre-commit review until they are familiar enough with the domain, tooling, and CI/CD infrastructure to graduate to post-commit review.conf: high
explicitThe automation required to make post-commit review safe -- automatic revert on failure, commit serialization in a monorepo -- is itself a substantial engineering investment; at scale (e.g. Uber's SubmitQueue) it requires meta-build-system, load-balancer, and speculative-execution-level complexity, not a simple CI tweak.conf: high

Arguments

Teams should default to post-commit review rather than mandatory pre-commit gating when they can make reverts safe. strength: medium

Explicit premises:

Pre-commit review hinders velocity almost invariably.
Review's real measured value is mostly knowledge transfer and team awareness, not defect detection.
Automated post-commit testing already catches the bug categories unit tests miss, before a human reviewer even looks at the change.

Implicit premises:

Since review's value is concentrated in knowledge transfer rather than defect-catching, deferring the review past the merge point does not meaningfully reduce that value, because the knowledge transfer still happens -- just slightly later.
The four-eyes / audit-trail control objective that pre-commit gating is often assumed to satisfy can be satisfied just as well by a post-commit (pre-deploy) gate.

Inferences:

An organization's choice between pre- and post-commit review is really a choice about where it wants to spend its automation and trust-building investment, not a binary quality-vs-speed trade-off.

Narratives

Quora practices full post-commit, post-deploy review -- code is reviewed only after it has already reached production -- for a company operating at meaningful scale.
→ Serves as a concrete existence proof that even the more aggressive post-commit/post-deploy variant is viable in practice, not just a theoretical option, grounding the article's taxonomy in a real organization.
Uber's SubmitQueue keeps a monorepo's main branch 'always green' at scale by combining a meta-build system, load balancer, and speculative executor to serialize hundreds of concurrent commits and handle automated reverts.
→ Illustrates the real cost side of the article's argument: the automation investment required to make post-commit review safe in a monorepo is itself a major systems-engineering undertaking, not a minor tooling add-on.

Questions addressed

✅ Does mandatory pre-commit code review cost more in velocity than it delivers in quality assurance?
Yes, in the author's assessment -- review's measured benefit is mostly knowledge transfer rather than defect-catching, while pre-commit gating reliably slows developers.
✅ Is 'post-commit review' the same thing as 'post-deployment review'?
No -- the article's central clarification: post-commit review can still happen before deployment (post-commit, pre-deploy), and only some teams go further to post-commit, post-deploy.
⭕ What happens when the automated revert/rollback mechanism that makes post-commit review safe itself fails or misses a bad change?
⭕ Does the 'developer focus' benefit of batched post-commit review still hold when the author of a commit is not a single human who can be interrupted at most every 10-15 minutes, but an agent capable of producing many commits per hour?

Gaps

incompleteThe entire safety case for post-commit review rests on automated revert/rollback being reliable, but the article never asks what happens when that automation itself has a false negative -- a bad change that neither the (deferred) human reviewer nor the automated tests catch before other commits build on top of it. The risk isn't addressed as a risk, only as an engineering cost (SubmitQueue-level complexity) to be paid once.
Read next: Corpus material on CI gates and agent-driven churn (e.g. the deterministic-CI-gates argument) addresses exactly this residual-risk question for a world with far higher commit volume than this 2020 piece assumed.
incompleteThe 'developer focus' argument for post-commit review implicitly assumes the author is a single human whose commit rate is bounded by typing speed, so batching reviews relieves interruption for both sides. If the author is a coding agent capable of producing many small, well-formed post-commits per hour, the same batching logic may not relieve reviewer load -- it may simply convert interruption cost into volume overload, since the reviewer side of the equation doesn't scale down just because commits arrived post-merge instead of pre-merge.
Read next: extract-agentic-code-review's finding that reviewer capacity, not author speed, is now the binding constraint directly tests whether this article's focus benefit survives when authorship is agentic rather than human.