Anthropic's merges passed 30,000 a day and source control became the wait. Find where your agent's work stalls

When one person runs several coding agents, the code stops being the slow part. The slow part becomes everything after the agent says “done”: the review, the checkout, the CI run, the merge. On October 13, Anthropic published what that looks like at the far end of the scale, and GitLab published its answer the same day.

What Anthropic reported

In “Redesigning source control at Anthropic,” the company says it moved its monorepo off git to an in-house system called Scion in five months. All figures below are company-reported.

• Merged code changes went from about 2,500 a day in May 2026 to more than 30,000 a day in September.
• CI checks out code on the order of 25 million times a day, and CI and research checkouts now take seconds rather than minutes.
• A team of seven built Scion and Antique, a code review tool.

The post states the shift plainly: “The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.”

Three practices in the post matter more to a small team than the version control system itself:

1. Review the intent, not every line. Anthropic says the engineers on this system still review every change, but they now examine the intent rather than reading every line, and that Antique can separate comment-only changes from sensitive logical changes so reviewers focus on the consequential ones.
2. Test after merge, too. Anthropic says it has not been able to replicate a global repository lock on the merge queue, so it invested in post-merge and pre-deploy automated testing instead.
3. Let the agent fix conflicts. Concurrent changes can conflict, and the post says Claude can typically fix those conflicts faster than people can spot them.

Anthropic also says Scion is not a suitable replacement for git for general use, and that it would be difficult to offer it in a broadly useful form. You will not be adopting it.

What GitLab answered

GitLab’s reply, “Scaling Git for the agentic software factory,” keeps the Git protocol and changes what sits under it, so agents can request the files and history they need without cloning the whole repository each time. The product is in private beta.

In early internal tests, GitLab reports workloads finishing up to 50 times faster, with up to 2 times fewer tokens and up to 1,000 times less network traffic. GitLab itself calls these peak results under specific test conditions. It also reports that over the past year on GitLab.com, customers created 40% more CI/CD pipelines and code pushes increased 50%. All of these are company-reported.

GitLab names the next wait too: an agent that writes code in seconds is not worth much if its changes then wait hours for validation, security review or deployment.

What this means for a team of one to five

You are nowhere near 30,000 merges a day, and you do not need a new version control system. Anthropic does not expect many organizations to have these infrastructure problems in the very near term, though it suspects others who use AI coding tools will hit the same pressure points before long. Add a second or third agent and output goes up. Review time, CI minutes and merge conflicts go up with it. If you do not know where your changes wait, the extra agent just makes the queue longer.

A test to run this week: time ten changes

Pick the last ten changes an agent produced. For each one, write down five timestamps from your git host and CI logs:

1. Agent finished and the branch was pushed.
2. You (or a reviewer) first opened it.
3. Review approved.
4. CI went green.
5. Merged, and deployed if you deploy.

Subtract each step from the next. Add up each gap across all ten changes. The largest total is your bottleneck. Then use this rule:

• If the review gap is largest, sort changes into tiers before you read them. Anthropic’s review tool separates comment-only changes from sensitive logic; a small team can use tiers such as docs and comments, tests only, logic, and anything touching auth, payments, data deletion or infrastructure. Read the intent and the tests for the first three. Read every line only for the last.
• If the CI gap is largest, split the suite. Keep a fast set that must pass before merge and move the slow set to run after merge and before deploy. That only works if a failure after merge stops the deploy and someone gets told.
• If the time from approval to merge is largest, you are probably rebasing by hand. Give the agent the conflict and its own tests, and review its fix like any other change.
• If checkout or clone time shows up in the agent’s own logs, note it and watch GitLab’s beta. It is not something to switch to this week.

Run the same ten-change count again after one change. If the biggest gap did not shrink, undo the change.

What to do this week

• Pull timestamps for your last ten agent changes and find the largest gap.
• Write down your review tiers in one paragraph and put it where your agents and reviewers can read it.
• Decide which tests must pass before merge and which can run after, and make a post-merge failure block the deploy.
• Hold off on adding another agent until you know where the current ones wait.

If you want a second pair of eyes in your repository, a Consult block is pairing time on a merge checklist for agent pull requests and on which debt to pay down first.