Agents got fast. Trust didn't.

When an agent says done, somebody still has to find out whether it's true. For me, that somebody was me.³3Over 60 days I stopped agents mid-run to correct them 525 times, and reopened about a third of my sessions within ten minutes, just to check. I decided which agent worked on what, remembered what each one had been told, and read everything that came back.

My agents could produce work faster than I could check it, and the checking set the pace for everything.

Agent setups went from one agent looping on a goal, to graphs of specialised agents, to orchestrators like Orca,⁴4Orca runs a fleet of coding agents, like Claude Code or Codex, side by side. source ↗ where one person runs a whole fleet in parallel.

Two recent designs go after coordination. DeepSeek's super agent is an always-on front door that hands every request to a worker.⁵5Their stated principle: take as little human attention as possible. Staying out of the work is a prompt rule, not a hard limit. source ↗ LangChain's async subagents let a coordinator steer or cancel workers without waiting on them.⁶6Start returns a task ID immediately; check, update, cancel and list work on that ID. source ↗

Every step ships unchecked work faster. The queue just moves to whoever has to read it.

Agents aim at the check they can see. On ImpossibleBench, GPT-5 'passed' 54% of tasks whose tests contradicted the spec, and the only way to pass those is to cheat. Given a way to flag the conflict, the rate fell to 9%.⁷7Conflicting-SWEbench split. 'Cheating' is the paper's own word. source ↗

Add coverage and mutation tests, and about 20% of agent patches that had already passed get rejected.⁸8SWE-ABS, on SWE-bench Verified. source ↗ METR measured the same gap another way. For Claude Sonnet 4.5, the task size it could handle fell from about 50 minutes to about 8 once the question went from 'do the tests pass?' to 'would a maintainer merge this?'⁹9Small sample, and the maintainers reviewed without CI. The direction is the point. source ↗

Work ships at the speed of the slowest check you trust. Right now that check is a person reading diffs.

In every public write-up I found, a person still approves the merge. Stripe merges over a thousand agent-written pull requests a week, each one reviewed by a human.¹⁰10Stripe's Minions post. source ↗ Google's AI-driven migrations go through engineers and code owners.¹¹11Google, AI-driven code migrations. source ↗

Dependency bots can merge on their own, but only by fixed rules like 'patch updates only', never by a measured failure rate.¹²12Renovate automerges by configured rules; Dependabot needs a workflow to do it. source ↗

Meta is the exception. Its RADAR system lands low-risk changes with no human review, and each type of automated change has to earn that: 60 days with zero production incidents and a low revert rate. One incident blocks it.¹³13Meta calls each type a runbook. Reverts were about a third of other changes; Meta says that comparison isn't causal. source ↗ I want that for teams that aren't Meta.

I'd build it like this. Every agent change gets tagged with what kind of change it is, decided by the files it touches, so an agent can't call its own work low-risk.

Every night, each merged change is checked against what happened next. Was it reverted, or quietly fixed within two weeks? That gives each kind of change a failure rate from real outcomes.

Each kind of change has to earn auto-merge. Zero failures in 60 changes puts the 95% upper bound near 5%.¹⁴14Rule of three: 3/60 = 5%. Assumes the changes are similar and independent. One incident sends it back to review, and every failure becomes a new test.

Property tests make the checks harder to game. They test a rule across hundreds of random inputs, and once they're locked an agent can't quietly redefine them. When researchers had an agent write them for 100 Python packages, 56% of a reviewed sample of its bug reports were real bugs.¹⁵15A sample of 50 reports. The authors include Anthropic staff. source ↗

I tried to measure how often 'done' was wrong, and both easy counts failed. Counting only explicit reverts gives a tiny number that misses most mistakes. Counting any later fix to the same file flags nearly every change.

A real number needs line-level links from each fix to the change it repaired, checked by hand. And I'm wrong if reviewing agent code costs people very little time. Then trust isn't the bottleneck.