My previous piece was about code review: a human reading code before it ships. This one is narrower, and blunter. It is about the merge gate, the specific act of requiring a human to click “approve” before code can land in a codebase.
People treat review and approval as the same thing. They are not. You can review code without being able to block it. You can approve code without reading it. The valuable act (reading) and the gating act (merging) have been fused by our tooling, and that fusion is worth pulling apart.
Most arguments for keeping a human in the merge loop collapse once you ask a single question. What does the approval click certify that the automated gates did not?
What the Approval Click Actually Certifies #
Watch what happens when a pull request gets approved.
The approver sees a green checkmark from CI. They see a passing test suite. They scan the diff for a few seconds. They click approve.
Ask them, afterward, what they certified. They will struggle to answer.
They did not re-run the tests; CI already did that. They did not verify the implementation against the spec; they assumed someone else did. They did not reason about every edge case; the diff was too long to reason about in three minutes. They did not assess whether the change could be undone; that is not what diffs show.
The approval click, in most teams, certifies exactly one thing: that a specific human was awake and present at the moment the PR was merged. That is a low-information event, and it is doing almost no safety work.
The actual safety is being produced by the systems around the gate. The test suite. The linter. The static analyzer. The deployment pipeline. The rollback path. The human approval is layered on top, taking credit for safety it did not generate.
The Cost of the Gate #
A gate that does little safety work still extracts a cost. Several costs, in fact, and they compound.
Latency. Every pull request waits for a human. That human is in a meeting, asleep, on another team, or simply not looking at their inbox. Cycle time stretches from minutes to hours to days. Work that could ship this morning ships next Tuesday.
Batch amplification. This is the subtlest and most damaging cost. When approval is expensive to obtain, people batch. They hold three small changes until they have a fourth, because each approval is a fixed-cost interruption. The gate incentivizes the exact thing it should discourage: larger, riskier changes. A mechanism designed to keep changes safe ends up making them less safe, because the unit of review grows to fill the cost of getting reviewed.
Context switching. Every approval is an interruption for the approver. Their work is paused, their context is swapped, their focus is fractured. You are taxing your most experienced engineers to perform a low-information ritual.
Single point of failure. If only two people can approve a given area and both are out, the pull request stalls. Approval authority concentrates, and concentration creates bottlenecks and bus factors.
Soft target. The approver is the cheapest attack surface in the entire pipeline. You can harden CI, pin dependencies, and scan for secrets, but a tired approver who clicks approve on a social-engineered change defeats all of it. A human gate is a human vulnerability.
What Actually Makes a Merge Safe #
Strip the ritual away and ask what keeps a merge safe. It is a short list, and the human approver is not on it.
A comprehensive test suite that runs on every change. Static analysis that catches the classes of bugs tests miss. A deployment pipeline that canaries before it fully rolls out. Feature flags so new behavior can be disabled without a redeploy. A rollback path that has actually been tested, not assumed. Blast-radius limits that cap how much any single change can touch.
Each of these operates on reality, not on a human’s prediction of reality. A canary either surfaces the problem or it does not. An approver might notice the problem, or might be thinking about lunch.
The gate is taking credit for safety the system produces. Once you see this, you cannot unsee it.
The Accountability Objection #
The first objection is accountability. Without a human approval, who is responsible for the code that ships?
I made this argument in the previous piece, and I will not repeat all of it here. The short version is that a human glancing at a diff was never truly responsible for what shipped. Responsibility lives upstream, in who decided the problem was worth solving and who wrote the specification.
The approval signature adds nothing to that picture. It is a name on a line, demanded because it feels like accountability. When a change breaks production, the approver is not the one who gets blamed, disciplined, or even consulted. The signature exists to allocate blame after the fact, not to prevent harm before it.
What remains, once you accept this, is the audit and compliance framing. That is the stronger case for keeping a human signature, and it deserves its own answer.
The Compliance Objection #
“But regulation requires human approval.”
Sometimes it does. More often, regulation requires traceability, a named owner, a documented decision, an auditable path. Those are not the same thing as a tired human clicking approve at four in the afternoon on a Friday.
When a rule says a change must be “reviewed and approved”, it is trying to ensure that someone with authority consciously decided the change was acceptable. That intent can be satisfied several ways. A named owner who signed off on a specification. An automated gate whose rules were themselves approved by a human. A risk classification that a human defined and a machine enforces consistently.
The function is accountability and traceability. The form is “a human clicks a button”. Teams satisfy the form and skip the function all the time. The sound path is the reverse: satisfy the function rigorously, and let the form follow.
If your auditor insists that safety lives in a specific human keystroke, you have an education problem, not an engineering one.
The Binary Mistake #
The deeper error is treating approval as binary. Either every pull request needs a human, or no pull request does.
This is wrong, and it is not how anyone actually behaves. A README typo and a production schema migration are both pull requests. They do not need the same gate. Treating them the same is not caution; it is a failure to think about risk.
The right unit of gating is not “is this a pull request”. It is “what is the blast radius of this change, and is it reversible”.
A one-line documentation fix is low blast radius and trivially reversible. Let it merge on green. No human needs to see it.
A change that drops a database column is high blast radius and may be irreversible. That deserves a human looking at it, carefully, with time.
A change that alters an authentication boundary is medium blast radius but high trust impact. That deserves a human, and probably more than one.
The properties that should trigger a human gate are properties of the change: irreversibility, blast radius, trust-boundary crossing, external commitment. They are not properties of the artifact. When you gate on the change instead of the artifact, the fraction of changes that need a human collapses to a small minority.
The Small Set Where a Human Gate Genuinely Adds Value #
Frankly, there is a set of changes where a human in the merge loop is not theater. It is small, but it is real.
Irreversible changes. Data destruction, schema drops, deletions of public content, sending real money, publishing to external systems. Once these execute, you cannot call them back. A human who understands the irreversibility should look at them, because the automated gates can only verify forward correctness, not undo impossibility.
Trust-boundary changes. Authentication, authorization, permission models, security-sensitive code paths. These are exactly where a subtle mistake is both likely and catastrophic. A human reviewer adds value here, not because they will catch every bug, but because the cost of a miss is high enough to justify the latency.
Changes to the gating system itself. You do not want the merge gate to auto-approve changes to the merge gate. That is the one place circularity will bite you. A human reviews the rules that the machine enforces.
External commitments. Public API changes, contractually obligated behaviors, compliance-relevant logs. These have consequences outside the codebase, and a human should confirm the external surface is intentional.
Note what is not on this list. Styling. Refactors within a single module. New tests. Documentation. Internal-only features. Dependency bumps that pass audit. These are the overwhelming majority of pull requests. They do not need a human gate. They need the automated gates, and then they need to merge.
The Transition #
You do not get to “no human gate for most changes” by decree. You get there by making the default path safe.
Start by making the low-blast-radius path auto-merge on green. Documentation, tests, internal-only changes within a single module. CI passes, the merge happens, nobody clicks anything.
Then compute blast radius automatically. Which files changed. Did the change touch the public API. Did it touch the database schema. Did it add a dependency. Did it change infrastructure or deployment configuration. Did it cross a security boundary.
Each of these is a machine-checkable property. Route the change to the human gate only when it crosses a threshold.
When a change does reach the human gate, change what the human is actually doing. They are no longer reviewing code line by line. They are reviewing risk. Is this change as irreversible as the system thinks it is? Is the rollback plan real? Is the blast radius acceptable? Does the external commitment match what was approved upstream?
Reviewing risk is high-leverage work. Reviewing diffs for style is not. The transition moves the human from the low-leverage activity to the high-leverage one, and it frees the rest of the pipeline to move at the speed the machines can sustain.
This is not a proposal.
It is a description of the workflow from the previous piece, where a pull request is checked against concrete gates: does it introduce security-sensitive changes, add dependencies, change public interfaces, is it reversible, do the tests pass, does it satisfy the acceptance criteria.
What this article adds is the principle behind that workflow.
The human gate is the exception, selected by the properties of the change, not the default triggered by the existence of a pull request.
The skills that implement it are publicly available.
The Merge Button Is a Ritual #
The merge button exists because our tools gave us a button. We built a workflow around it, assigned it meaning, and then treated the meaning as structural.
It is not. The safety of a codebase is produced by the systems around the merge, not by the merge approval itself. The click certifies almost nothing those systems did not already certify. And it extracts a real cost: latency, batched risk, fractured focus, concentrated bus factors, and a soft target for anyone who wants to slip something through.
The defensible position is not “no humans in the loop”. It is “humans in the loop where they add value, out of the loop where they do not”.
Most pull requests do not need a human to approve them. A small, identifiable minority do. The mistake of the current default is that it treats every change as if it belonged to that minority.
Free the majority to merge on green. Reserve the human gate for the changes where it actually certifies something the machine cannot. And stop pretending the button is what keeps you safe.
The gate was never the safety. The system was.