T3 Code's agent merge campaign: hundreds of PRs a day on green CI and AI audits, then a revert of everything the fleet couldn't run

The T3 Code repository just ran a public test of what sustained agent merging does to a busy open-source project. On Oct 18, maintainer Julius Marminge posted that "for the past 30 hours my agent has merged almost 400 PRs focused on web perf", claiming 86% fewer renders when another thread streams, up to 35% less JS CPU and a heap about 10% smaller. A GitHub search of the repo's merged PRs for the 30 hours before his post, run on the morning of Oct 20, returns 388 merged PRs opened from his account. Theo, who runs T3 Code, wrote that the next nightly "almost feels fake, like the data is hard coded or something." One of them, #20823, is a render-audit fix that a Macroscope bot approved and that merged with green CI under five hours after it was opened.

Then the agents moved on to the backlog. In what the repo calls the takeover campaign, comments under Julius's account announced "Taking over this one as maintainer" on open contributor PRs, and a search for that phrase among merged PRs returned 245 on the morning of Oct 20. The review lessons came out of that second wave:

Green CI and clean audits weren't enough for the desktop app. #20907 was meant to keep saved connections working after the app's Beta rename. It changed the identity used to decrypt them, and after it merged it broke every existing install. The sidebar showed "No projects yet" and the status bar read "0 of 8 updated." It was reverted. Minutes later, #22222 pulled 14 more desktop fixes from the same campaign: "All of them landed on green CI and clean code audits, and none of them was run on a real desktop build... nothing in the fleet can verify Electron changes."
The bots had flagged the risk. Macroscope's approvability check marked #20907 "Needs Human Approval" and a cookie-decryption fix (#19377) "Not approved." The takeover comments on both said "No merge is planned." Both merged anyway.
A permission change skipped its human gate. #22152 reverted a PR that let MCP agents respond to another thread's pending approvals. The revert says it "landed via the campaign's audit-gated path without maintainer sign-off, which the rules reserve for auth/permission changes."
Taste got reverted by hand. On Oct 20, Theo also reverted a run of recent merges one at a time, several on UX grounds. One had left a pin icon floating "in the middle of the top row." Another had added a warning to worktree threads that was "noise on almost every active thread."

Julius's own account is upbeat with caveats. On Oct 18 he wrote "only 1 UI bug after autonomously merging like 600 PRs." On Oct 19 he said he was burning Codex and Claude usage resets and was "bottlenecked by 5k req/hr" on GitHub's rate limit. On Oct 20 he wrote that he was "tuning the loop and it's let a few bad PRs slip by." He also noted that "if you look at the open PRs and Issues the number hasn't really gone down a whole bunch... cause the intake is just so big."

Why it matters for code review

This is the strongest recent case for steady, harnessed throughput. Hundreds of performance fixes that passed CI landed in a day and a half, and a second maintainer felt the difference in the product. It also shows where that throughput stops compounding. It held up where the harness could verify the work (web rendering, which tests and render audits can check) and broke down where it couldn't (Electron builds carrying real user state, permission boundaries, UX taste). The fix was a scoping rule, not slower agents: desktop changes don't ship until someone has run them on a real build. The approvability verdicts were already on the PRs, but nothing in the merge path enforced them. Read with the two always-on maintainers that invented their own work, Yegge's land rush at 175 commits a day, and Anthropic at 30,000 merges a day.