Anthropic rebuilt source control for agents. CI is next.
Anthropic's source-control redesign shows what agent scale does to developer infrastructure. Most teams will keep Git. The CI and merge loop is where they need to change. 2026-10-13. A proper merge queue, for example, doesn't make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running?
On 2026-10-13, Anthropic published Redesigning source control at Anthropic. It is worth reading in full. This is our response: what it says, what it means for CI, and what we're building. Anthropic has not reviewed or endorsed ModernCI; the figures below are theirs, quoted from the article.
What the article says
The headline number: "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day."
Git, built for people working offline, became their bottleneck. They "perform on the order of 25 million code checkouts per day for CI." So they built Scion, their own version control system, and "fully migrated our monorepo from git in five months." CI checkouts became "two orders of magnitude faster (in seconds rather than minutes)", and "CI alone realized a 25% CPU capacity win."
They are clear that Scion is not for everyone: the ideas "really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code." Scion is internal; it isn't something you can adopt.
Source control and CI are different bottlenecks
The part we keep re-reading is about CI, not Git:
Anthropic's answer, at their scale, was to drop the global lock and invest "in post-merge and pre-deploy automated testing." They accept that "concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them."
Most teams are nowhere near 30,000 merges a day. But the shape of the problem arrives much earlier. Our own repo, built by a fleet of coding agents, had 338 pull requests opened in one day (F1). tokio, a busy open-source Rust project, opened 144 in 30 days (F2). CI was built for the second number.
Why pull-request CI gets awkward with many agents
- One queue. GitHub-hosted runners cap concurrent jobs per account: 60 on Team (F6).
- Serial merge. GitHub's merge queue tests each pull request on top of every one ahead of it; when one fails, it is removed and the builds behind it start again (F7).
- Re-run everything. Checks that passed on the pull request run again in the queue (F7).
- Red by flake. The tool offered is a re-run (F8). An agent handed a flaky red will try to fix code that isn't broken.
None of this is wrong for a team of people opening a few pull requests a day. It is the wrong shape for agents.
What an agent-first CI loop has to do
- Check every push, fast, and stop work a newer push made moot.
- Never run the same checks on the same inputs twice.
- Send a failure back to the agent that made it, with the evidence to fix it: the failing check, the log, the command to reproduce it, the diff.
- Tell a flake from a real failure before blaming anyone.
- Merge many changes at once, and merge exactly what was checked.
- Say when it is stuck, and why.
- Put the cost of every merge on the record.
Why keep Git
Anthropic rebuilt source control because their monorepo outgrew it. Most teams' repos haven't, and their forge holds their reviews, permissions and history. So ModernCI keeps Git and works with GitHub and Gitea. It changes when, where and whether checks run, and how changes merge. It does not ask you to move your code.
We also make a different trade-off on merging. Anthropic tests after merge. ModernCI merges exactly what it checked: changes ride the merge queue, are checked together, and the target moves to the checked commit. That is safer, and it costs throughput. Our own busiest day shows the cost: push to result had a p95 of 22.6 hours while one batch in the merge queue stalled for 171 minutes (F10, F12). Batching is one lever we have measured: replayed on 612 real heads, checking two at a time cut cost per merged change from $14.32 to $5.81, in simulation (F13).
The hard parts
- Concurrency: many changes, one target, and a result that goes stale when the target moves.
- Protected tests: an agent can make a red go green by deleting the test. Protected paths, where that needs a person's order, are planned, not built.
- Flaky failures: ModernCI re-runs a suspect test alone before it blames anyone, and quarantines repeat offenders.
- Security: agents push code that runs on your machines. Checks run as a separate OS user; sandboxing on a shared machine is not built (Security).
- Cost: counting machines and agents together, per merged change (Cost).
What ModernCI does today
ModernCI is not released. It runs on our own repos, on one install we operate. Live today: checks on every push, reuse by inputs, stopping superseded runs, the batch-and-bisect merge queue, flake quarantine, and failures sent back to agents. The full list, with what is still building or planned: Release status. Every number: Facts.
If your team runs many coding agents on a busy repo, with CI that is slow or costly, we are inviting a few teams to try it: request early access.