Letting an agent merge code you haven't read

A stack of mechanical checks decides which kinds of change can merge without anyone reading them.

This is the jump from Level 3 to Level 4 on the autonomy ladder, where teams tend to stall. One rule makes it work. AI suggests, and a fixed policy decides. An agent's confidence doesn't count as a gate, and neither does an AI reviewer's approval. A gate passes or fails mechanically, like a test, a scanner or a policy rule. Only a stack of those earns an auto-merge.

Pick your stack, the gates every auto-merge must pass and the change classes allowed to auto-merge. The builder below writes guardrail.yml, labeler.yml and auto-merge.yml for you.

What broke when I ran it

I ran this config on a live sandbox where an agent fleet opened PRs. Three things failed that reading the YAML would never have shown. The generated files include the fixes.

• Mixed PRs got the docs label. any-glob-to-any-file labels a PR auto:docs if it touches any doc, even if it also rewrites source. Use any-glob-to-all-files, so the label applies only when every changed file matches.
• The merge workflow never ran. I had one workflow add the label and a second on: [labeled] workflow merge. Events raised by GITHUB_TOKEN don't trigger other workflows, so nothing happened and nothing looked broken. Fix: label and enable auto-merge in one run, off the labeler's all-labels output.
• GitHub refused green PRs. If the label lands after checks finish, gh pr merge --auto fails with the misleading "auto merge is not allowed for this repository." Fix: gh pr merge --auto || gh pr merge. Branch protection still gates the direct merge.

Two smaller changes: semgrep ci needs a Semgrep platform token, so the gate runs semgrep scan --config p/default --error, which doesn't. And the coverage floor runs inside the test job (c8 --check-coverage) so the suite runs once. On github.com, branch protection needs a paid plan or a public repo, and everything here depends on it. Self-hosted Forgejo has no such limit.

Why an AI reviewer can't hold the gate

An LLM reviewer catches things, so keep it as an advisory comment. But it fails in the same ways as the LLM that wrote the code, and it can be talked into "looks good." Nobody can argue a test into passing, so tests and scanners hold the merge.

The gates

Code

Lint, type-check, build, tests, and a coverage floor so an agent can't ship untested code by deleting the test in its way.

Security

Secret scanning has to block the merge, because agents do paste live keys into configs. Add SAST (semgrep) for injection and unsafe patterns, and a dependency audit so an agent can't pull in a vulnerable or hallucinated package.

Auto-merge is earned per class of change

A green dependency bump and an auth refactor carry different risks. Treat them the same and you either never turn auto-merge on or regret it. Start with docs and dependencies, where the damage is small and a glob can spot the class. Add "refactor with tests" once you trust the gates. Keep auth, money, migrations, public API and .github/** with a person.

Make it reversible

Keep a break-glass path: a labeled, logged way for a person to force or block a merge when the gates are wrong. Make rollback one command, and let a post-merge signal trigger it. Keep auto-merges small so reverting is trivial. Log every merge and override, so you widen the policy on evidence.

What still reaches you

Escalations and break-glass cases are now your review queue and your bottleneck (see why review is the bottleneck). Keep it moving with small diffs and the right reviewer: a senior engineer for risky logic, a quick human check that the rendered result looks right. twocents does the second kind. Your agent shares the output, you pin what's off from your phone, and the note goes back to the agent as markdown it can act on.