Merge on green is a policy. Choose it deliberately.
Most teams already merge on green. They just have not admitted it, so nobody has decided what green needs to mean. Undeclared merge-on-green is the worst of both worlds.
Merge on green has a reputation as the reckless option, the thing you do when you have given up on review. I think that reputation is backwards, and it is causing real harm.
My position: merge on green is a legitimate and often correct policy. The problem in most organisations is not that they have chosen it. It is that they are doing it without having chosen it, which means nobody has done the work of deciding what green has to mean for it to be safe.
The dangerous state is not merge-on-green. It is merge-on-green with a human approval ritual on top that nobody performs and everybody believes in.
You are probably already doing it
Take a team with a nominal two-approval policy, an agentic pull request volume that has roughly tripled, and reviewers who are also expected to ship. LinearB’s 2026 benchmarks describe what happens: pickup time on agentic pull requests around 5.3 times longer, median review duration up over 400 percent, and merges with zero review up about 31.3 percent.
Behind those numbers, the approvals that do happen have changed character. The reviewer opens the change, sees the checks are green, forms a quick judgement that nothing looks structurally alarming, and approves. The green state did most of the work. The human contributed a plausibility scan.
That is merge on green. It has a signature attached, which makes it look like something else, and the signature is why nobody has asked the important question: what would the automated checks have to establish for this to be defensible on its own?
Because if the answer is “quite a lot more than they currently establish”, you have a problem regardless of the approval policy.
Undeclared merge on green
- Policy says two approvals
- Practice is a plausibility scan on a green build
- Nobody specified what the checks must prove
- The signature obscures the actual gate
Declared merge on green
- Named paths merge without a human, on purpose
- Green has a written definition per path
- Gaps in the check suite are visible and owned
- Human review is concentrated where it was not spread
What green has to mean
If a change is going to production without a human in the path, the automated evidence has to answer three questions, and most check suites answer one and a half.
Does it do what was asked? This needs acceptance criteria that are specific enough to evaluate, and a check that evaluates against them rather than against the change’s own internal logic. A test suite written by the same process that wrote the code answers “is this self-consistent”, which is a different and much weaker question.
Does it break something else? Regression coverage on the paths this change can reach. Not overall coverage percentage, which is a number I have watched teams optimise while their critical paths stayed untested. Coverage of the specific call graph downstream of the change.
Can it be undone? A change that merges without human judgement needs to be reversible without human archaeology. Feature-flagged, or trivially revertible, or behind a canary with an automatic rollback on error rate. If undoing it requires a migration to be run backwards at 2am, it does not qualify for this path.
A check suite that answers all three is genuinely stronger than a tired human at the end of a queue. A check suite that answers “the tests that exist still pass” is not, and the gap between those two is where every merge-on-green horror story lives.
Per path, not per repository
The mistake I see next is treating this as a global setting. Merge on green: on or off. That framing guarantees a bad answer, because a repository contains paths with wildly different consequences.
The unit of decision should be what the change can reach. A copy string, a log level, a generated client, an internal admin tool: these merge on green, and a human reading them is spending the scarcest input in the organisation on something a machine settled. Authentication, payment handling, data deletion, anything with a schema migration, anything that alters a public contract: these do not merge on green regardless of how green they are, because the tail risk is not proportional to the diff.
The interesting middle is where most changes live, and the honest answer there is that it depends on the quality of the check suite for that specific area. Which is a useful thing to have to say out loud, because it turns “should we merge on green” into “is our coverage of the billing module good enough to merge on green”, and that second question has an owner and a fix.
Low reach, strong checks
Merge on green. A human here is pure waste. Say so in policy.
Low reach, weak checks
Merge on green and accept it. Or fix the checks. Do not add a ritual approval.
High reach, strong checks
Human on fit and consequence only. Correctness is already settled.
High reach, weak checks
The only quadrant that justifies slow, careful, senior review. Protect it.
Declaring it is the whole benefit
Writing the policy down does three things that the practice on its own does not.
It makes the check suite’s inadequacy visible. “We merge billing changes on green” forces somebody to look at what green covers in billing, and that look is where the value is.
It makes the unreviewed rate a chosen number rather than a discovered one. If you have declared that 40 percent of changes may merge without a human and you are at 40 percent, the system is behaving. If you have declared nothing, 40 percent is a finding you will react to badly.
And it gives you an artifact. Under the EU AI Act, in force since 2 August 2026, Article 12 requires automatic logging of events relevant to risk and traceability, tamper-evident and retained for six months. A declared merge policy plus a log of which path each merge took is the difference between being able to describe your control environment and having to reconstruct it under pressure.
Where this breaks down
Declaring a policy nobody follows is worse than not declaring it. A written merge-on-green policy that engineering ignores creates an evidentiary problem: you have documented an intent you demonstrably did not implement. This is a genuine risk and I do not have a cheap answer beyond making the policy machine-enforced rather than aspirational.
Path classification is guesswork and will be wrong. Something classified low reach will cause an incident, and the organisational reflex will be to reclassify everything as high reach, which is uniform review with more machinery. Surviving the first bad miss requires senior air cover agreed before the miss, not after.
Strong checks are not free, and merge-on-green makes them load-bearing. Once you remove the human, a flaky test suite is no longer an annoyance, it is your last line. Some teams will declare the policy without funding the check suite it depends on, and that is strictly worse than what they had.
Reversibility is often theatrical. Feature flags get left on, canaries get watched for four minutes, rollbacks get blocked by a data change nobody modelled. If your “can it be undone” answer is aspirational rather than tested, the third condition is not met and the policy rests on a fiction.
And there are contexts where none of this applies. If every change carries a regulatory evidentiary obligation, the answer is human review on everything, and the cost is the cost. Do not import a tolerance framing into a domain that has no tolerance to allocate.
The takeaway
Merge on green is not the reckless choice. It is a policy about where assurance comes from, and it is defensible when the automated evidence establishes intent, regression safety and reversibility for that particular path.
The reckless choice is the one most teams are currently making by default: a nominal review policy over a real merge-on-green practice, with nobody accountable for what green proves, because officially green is not the gate.
If you take one thing into next week: for the single most consequential module you own, write down what the automated checks would have to establish for a change there to merge with no human. Then compare that list to what your checks actually do.