The software factory · the how

The auto-merge guardrail

The jump from "agents open PRs I review" to "agents merge on their own" isn't a trust fall. It's a policy: a stack of deterministic gates that decide, for a bounded class of changes, whether code ships without a human reading every line.

This is the Level 3 → Level 4 step on the autonomy ladder, and it's where most teams stall — not because agents can't code, but because "merge without reading it" sounds insane until you make it not-insane. The move that makes it sane is one principle, and it's the 2026 consensus among people actually running this in production: AI suggests and accelerates; deterministic policy decides and enforces. An agent's own confidence is not a merge gate. An AI reviewer approving the PR is not a merge gate. A gate is something that mechanically passes or fails — a test, a scanner, a policy rule — and only a stack of those earns an auto-merge.

Below, build the guardrail for your own repo. Pick what qualifies for auto-merge and which gates it must clear; the config generates as you go.

Why deterministic gates, not an AI reviewer

It's tempting to close the loop with AI all the way down — one agent writes, another reviews and approves. Don't make the approval the gate. An LLM reviewer is a useful signal (it catches things), but it fails in exactly the same correlated ways as the LLM that wrote the code, and it can be talked into "looks good." Deterministic gates can't be sweet-talked: a test either passes or it doesn't, a secret scanner either finds the key or the key isn't there. Keep the AI reviewer as an advisory comment; let the mechanical gates hold the merge.

The gate stack, layer by layer

Deterministic code gates

The floor: lint, type-check, build, and the test suite — plus a coverage no-drop rule so an agent can't quietly ship untested code by deleting the test that was in its way. These catch the boring majority of regressions for free.

Security as a hard gate

The moment agents can open PRs, secret scanning must block the merge, not file a report nobody reads — an agent that pastes a live key into a config is not hypothetical. Pair it with SAST (semgrep) for injection and unsafe-pattern classes, and a dependency audit so an agent can't pull in a vulnerable or hallucinated package. These are the gates that turn "move fast" from a liability into a policy.

Agent-output evals

For code that touches AI behaviour — prompts, tool definitions, routing — add regression evals (promptfoo) so a "small tweak" can't silently tank quality. This is the gate the non-agentic world doesn't have and the software factory can't live without.

The change-class policy is the real L3→L4 lever

Here's the part people skip: auto-merge is earned per class of change, not globally. A dependency bump with green checks is a different risk than a refactor of the auth module, and treating them the same is why teams either never turn on auto-merge or turn it on and get burned. Start narrow — deps, docs, formatting — where the blast radius is tiny and the gates are decisive. Widen to "small refactor with tests" only once you trust the gates. And wall off the high-blast-radius classes (auth, money, migrations, public API) so they always reach a human, no matter how green the checks. That policy is exactly what the builder above encodes.

Break-glass, rollback, and the audit trail

Two things make autonomy reversible instead of terrifying. First, a break-glass path: a labelled, logged way for a human to force or block a merge when the gates are wrong, with the override recorded. Second, fast rollback: auto-merge is only safe if a bad merge can be reverted in one command and a post-merge signal (a failing canary, an error-rate spike) can trigger that revert automatically. Every auto-merge should be small precisely so its rollback is trivial. Log every automated merge and every override — the audit trail is what lets you widen the policy with evidence instead of vibes.

What still reaches a human — and how fast

The escalated classes and the break-glass cases are the residual human queue, and its size is now your bottleneck (see why review is the bottleneck). Keep that queue fast: small diffs, and the right reviewer for the judgment — a senior engineer on the risky logic, but a quick human read on whether the rendered result is actually right. That last part is where a lightweight feedback loop earns its place in the factory: your agent shares the running output, a human pins exactly what's off from their phone, and the note comes back structured — the human gate without the human-in-front-of-a-desk. That's what twocents does, and in a mobile-run factory it's how the escalation queue clears from wherever you are.