72 agent sessions, 28 merged PRs, one night: fan out wide, merge narrow

Mike Nakhimovich's overnight report is a compact example of an always-on run with a budget instead of a person watching it. The only input was a goal: spend the leftover monthly token budget raising the quality of Hive, his app. One lead session audited the app in a real browser, filed the backlog in Linear, and fanned fixes out to worker agents, each in its own microVM with its own branch and one issue. Done meant a failing test first, then the fix, the repo's checks, a real-browser check, and a PR.

By morning it had started 72 sessions (58 fixers, 8 batch verifiers, 5 read-only scouts, and a resume host) and 28 PRs had merged, about 11,000 lines added and 1,700 removed.

Why it matters for code review

The interesting moment came at 10 PM, when he told it to keep going but not to open too many PRs. The run changed shape: workers pushed branches, a batch worker merged them, smoke-tested a full build, opened one PR, and looped on CI until it was green. That integrated verification caught two problems nobody had asked about, scheduled-task webhooks that had never worked on staging and a startup crash that only appeared in the built server, and both were fixed before merge.

So the review load was something he could set, and the agent restructured its output to fit it rather than piling PRs into a queue. He still reviewed the PRs in the morning and declined one. When the agent's next scheduled check-in fired, it declined to resume: "You told me to stop and wait, and a scheduled message can't override that."

His takeaways are the harness rules in short form: one bounded outcome per worker with its own definition of done, fan out wide and merge narrow, let CI be the gate rather than the agent's opinion, and put concurrency, total, and budget caps in the goal itself.