Auto-Merge on Green CI: How Much Do You Trust Your Own Pipeline?

The workflow for dev-hub has no "click approve to merge" step. A pull request that passes CI merges and deploys on its own. That sounds reckless until the actual question underneath it gets asked: what does "green" require in this pipeline, and is that requirement strong enough to stand in for a human looking at the diff?

What has to be true for this to be safe

Auto-merge is a bet that the test suite plus the type checker plus the lint pass catch the failure modes a manual review would have caught. That bet only pays off if coverage is real — not just present, but actually exercising the branches that matter — and if the suite runs against something close to production shape (a real database in integration tests, not a mock that agrees with itself). dev-hub's posts feature shipped with 131 tests covering the boundary cases specifically because "the pipeline is trusted" is a claim that has to be earned test by test, not asserted once.

Why manual approval isn't the fallback

Removing the human approval step isn't removing review — review moved earlier, into writing the tests that define "correct" before the code exists, and into whatever caught the bug in the first place if CI ever goes red. A confirmation click on a green pipeline doesn't add information; it adds a pause. For a one-person project, that pause has no one on the other end to catch something the pipeline missed anyway.

Where the trust actually breaks

The failure mode isn't "CI passes and something's still broken" — that will always happen occasionally, on any pipeline, reviewed or not. It's a gap between what CI checks and what actually matters going unnoticed for a long time because nothing forces a re-audit of coverage. The honest maintenance cost of auto-merge isn't watching each merge — it's periodically asking whether "green" still means what it meant when the policy was adopted.