Nobody has to approve the agent's merge

Somewhere in the last year, a rule got written down at your company. Every change authored by an agent requires review and approval by a human engineer before it merges. It went into the engineering handbook, it probably went onto a slide for the board, and nobody argued with it, because it's the kind of sentence that sounds like responsibility.

Go and watch what it looks like on a Tuesday. The engineer holding the approval button has thirty-one agent-authored diffs in her queue and about four hours that aren't already spoken for. She isn't reading them. She's opening the ones that touch files she recognises, skimming the rest, and she'd tell you exactly that if you asked in a way that didn't sound like an accusation.

The rule is still in the handbook. It hasn't gated anything in months.

The claim

An agent can merge to main with no human approval. Not eventually, not only for typo fixes, not once the models get another turn of the crank. Now, for most of what an agent produces, in an org that's done the work.

The gate was never the signature. It's the machinery underneath it: a test suite that tells the truth, every change behind a flag, a staged rollout, a rollback measured in seconds, and a blast radius small enough that being wrong is cheap. When those five things are real, the approval adds nothing you didn't already have. When they aren't real, the approval doesn't save you, and it never did.

What approval was actually for

Nobody sat down and decided that a second person's attention was the correct control for software risk. It accumulated, the way most process accumulates, and it accumulated for a decent reason. When one engineer produced one plausible change a day, a second engineer reading it was the cheapest instrument available for the question "is this safe to ship." Cheap, quick, roughly correlated with the answer.

That correlation is the thing that's gone. Approval was a proxy, and proxies hold right up until the volume changes, then stop measuring what they used to measure without announcing it. At forty diffs a day your reviewer isn't exercising judgment. She's demonstrating availability. The signature keeps arriving at the bottom of the pull request, it keeps meaning slightly less each week, and the org keeps counting it as a control because it's still on the list of controls.

You can watch this happen in aggregate. Faros AI's 2026 telemetry, across roughly 22,000 developers, has median code review time up 441.5% against a 33.7% rise in throughput, and pull requests merged with no review at all up 31.3%. Nobody repealed the policy. It got outrun.

The question that settles it

Take any class of change you're routing through a human approver and ask what the approval catches that the machinery underneath doesn't. Not in general. For that class of change, specifically.

You want a concrete answer, and you should be ready for how often there isn't one. "Someone might spot something" isn't an answer, it's a hope with a process attached. If the answer is "our tests wouldn't catch a subtle error in pricing logic," good. That's real, and it tells you what to do: pricing needs the kind of test that would catch it, and until it has one, changes there sit in a different class with a different gate. If the honest answer is "we'd be uncomfortable," that's worth knowing too, and worth naming as discomfort rather than dressing it up as a control.

Two moves work from there. Fix the machinery, or shrink the blast radius. Adding another human is the one that can't keep up, because reviewer capacity is fixed and generation isn't, and any answer built on the fixed quantity loses on arithmetic before you've finished designing it.

Where a person still belongs

The line isn't who wrote the change. It's whether you can undo it.

One-way doors still get a person, and they should have been getting one all along: a migration that drops a column, anything that moves money, anything touching customer data in a way you can't reverse, deleting the old path in a cutover. Those are expensive to be wrong about at a scale no rollback fixes, and the autonomy level follows the blast radius, not the task type and not the author.

Notice the classification never mentions who wrote it. A human-authored irreversible migration earns the same gate. Most orgs wrote the rule the other way round, keyed on authorship, which is how you end up demanding two approvals on an agent's dependency bump while a person's unflagged schema change goes out on a Friday afternoon behind a thumbs-up emoji.

Three objections, and what each is worth

Compliance is the first, and sometimes it's genuine. Most change-management controls, the SOX ones included, ask for evidence that a change was authorised, tested, and traceable to a person accountable for it. Every one of those can be satisfied by a pipeline that records what it did. Almost none of them say a human has to click a button. Go and read the actual control text, or get your auditor to say it in their own words, because almost nobody in that room has. They've read a summary of a summary from four years ago. Sometimes the answer really does come back as a human signature, and then you comply and move on with a clear head.

Second: review is how people learn the codebase. True, and it's the strongest thing anyone says in defence of the rule. It's also a different job wearing the same clothes. If code review is your knowledge-transfer mechanism, design it as one on purpose, with pairing and rotation and somebody accountable for whether it's working. Don't leave a mandatory bottleneck standing and hope the learning happens inside it, because at current volumes the learning is the first thing to fall out.

The third objection is the honest one, and it's why the rule is so hard to remove. The signature gives you a name when it goes wrong. Not prevention. Attribution. Worth saying out loud, because a better answer is available and you already use it everywhere else: name an owner for the workstream and put them on the rota. Ownership survives contact with volume. A signature collected forty times a day doesn't.

The uncomfortable part

If you don't trust the machinery enough to let an agent merge through it, you don't trust it enough to let a person merge through it either.

Your engineers have been shipping through that same pipeline the whole time. Same tests, same flags, same rollback. The difference was never safety. The difference was that you had someone to blame, and the rule you wrote this year is a way of keeping that feeling while the volume goes up.

So write the other rule. Classify change by how expensive it is to be wrong, put a named gate on each class, and say nothing at all about who or what authored it. Then go and find out whether your test suite still tells the truth, because that's the sentence everything else here depends on, and it's the one nobody wants to be the answer.