Thirteen issues overnight: the read-only reviewer found what 40 passing tests missed
Nick Perkins let one coordinating agent work 13 issues for about seven hours, with 12 implementers and 10 adversarial reviewers. Nine pull requests merged, and the reviewers caught a monitor that would fail on every run and an unlimited mail-sending hole.
Source: Running Agents in Parallel Only Works With a Review Gate
Nick Perkins pointed a coding agent at 13 open issues on a household food-inventory app and went to bed. About seven hours later he hit his weekly usage cap with nine pull requests merged and three left as drafts. The coordinating agent launched 12 implementers, each in its own git worktree, and 10 reviewers.
The reviewers were told to assume the author was wrong and prove it. They were read-only: they could run scripts and write to a scratch folder, but not edit, commit, or push. What they found:
- An uptime monitor shipped with 40 passing tests and would have failed on every real run. Its systemd unit ran as a dynamic user that couldn't read the root-only env file. The tests passed because they ran as a user who could.
- A cross-tenant test was mutation-tested by hand: the reviewer broke the code about two dozen ways. A catch-all route registered ahead of the error handler and a route trusting a household ID from the query string both got past it.
- Sign-up abuse controls let one account mail any address without limit, and let anyone block other users' password resets without solving the bot challenge.
Running in parallel also caused failures that had nothing to do with the model. All the branches shared one test database, and a migration on one branch left a column behind that broke a schema test on every other branch. The agents' lock stopped concurrent use but didn't clean up afterward. And the security reviewer had no shell, so its findings still need a pass that actually runs them.
When the cap hit, the agent pushed the unfinished branches as drafts with a handoff note on merge order. Perkins tagged the release from main only; two drafts had never been reviewed, so they stayed out.
Why it matters for code review
This is a small, honest record of an unattended night, and the ratio is the point: nearly one reviewer per implementer, which feels wasteful and was where all the real catches came from. Tests written by the agent that wrote the code check what that agent expected. Overnight throughput only counts if what merges has been tried by something trying to break it, and Perkins's rule that unreviewed work waits, even when it is nearly done, is what keeps a busy night from turning into a messy morning. His advice is to set up the reviewer before starting a second agent.