Anthropic: 30,000 merges a day. Me: 250. Same bottleneck

On 14 October 2026, 250 changes were merged in my GitLab. In September, Anthropic was at over 30,000 a day. My peak day beside their daily throughput is a different order of magnitude. Still, the question behind it feels familiar: what is finished code waiting for?

TL;DR

• Anthropic built Scion for its enormous monorepo. It explicitly says Scion is unsuitable as a general replacement for Git.
• My changes wait for integration: review, pipelines, release windows and my decisions. Git does not show up as a bottleneck in my measurements.
• What I already do today: releases only go out in the evening, and merges run one after another per repository. Whatever needs my decision lands in one place. Separating merge from deployment is my next plan.

The big number hides a familiar problem

In its engineering article of 13 October 2026, Anthropic describes a shift in the bottleneck. Claude produces code faster than the existing infrastructure can handle it. Source control, builds and CI need to keep up. CI means the automated checks that build and test changes.

Anthropic reports the following figures for its own systems:

Scion addresses a specific problem of scale. The history of the main branch alone is almost 100 GB. CI performs on the order of 25 million code checkouts daily. Several hundred internal Git mirrors became increasingly difficult to operate as throughput grew.

Scion therefore moves work to the server. It answers questions about history, computes differences and merges changes. Clients fetch only what they need; some jobs can skip a local working copy altogether.

The original states plainly what Scion is not meant to be:

Scion is by no means a suitable replacement for git for general use.

Same bottleneck means: writing code is no longer what slows things down, everything after it is. At Anthropic, that pushed Git to its limits. For me, work piles up on the way from finished code to live, even though my repositories are small.

My curve: from 13 to 250 merges a day

On 15 September, 13 merge requests were merged in my GitLab. On 14 October, it was 250 in a single day. A merge request, or MR, proposes a change for inclusion in the shared codebase. The 250 are a peak; the median across the 31 days is 121.

Across 51 active projects, 3,108 MRs were merged from 15 September to 15 October. The agent account opened 2,643 of them, that is 85 percent. Opening a request does not mean it has been reviewed or shipped.

The figures are real, but they date from 15 October. And they count merges, not quality.

When this much code is ready at once, three questions follow. Who reviews it, when can it be merged, and when does it reach users? I explore that shift in Verification, not typing.

Git barely features in my waiting list

The largest repository examined is 942 MB. The CI configurations examined use shallow clones with a depth of 20, keeping the history limited. In the pipeline sample, the median wait for a runner is 4 seconds. A runner is the machine that executes the checks.

Jobs do wait longer during load spikes; I measured that too. I found no Git bottleneck. Honestly, a new version control system would start in the wrong place for me.

By integration, I mean the whole path after writing: review, merging, automated checks and deployment. A change can be finished on its branch and still be a long way from running in the product. For users, that final step is what counts.

How this runs for me today

During the day, the release MR waits

For several of my products, a merge to main triggers a production deployment straight away. Whatever lands on the main branch goes directly to users. That is why my releases only go out in the evening: from 06:50 to 22:05 Vienna time, a daytime release pause applies.

Release MRs are prepared during the day and parked. From 22:05 they run one after another in merge trains. A train bundles several finished changes in one repository, so a single pipeline runs instead of many. Internal changes still get merged during the day; only releases wait.

Before anything goes to main, the coding session announces it to Navigator, my tool above the coding sessions. The announcement names the MR and its code revision and says whether the pipeline is green. It also states what the merge to main triggers and what the review says. Navigator then performs the merge itself, in a fixed order.

This makes clear who goes when. But a merge alone does not prove that the change is running in production.

The running pipeline determines who goes next

That order comes from a window procedure: while a repository's main pipeline is running, the window for the next merge there stays closed. Changes are integrated in sequence. On a small scale, this is the same kind of lock Anthropic does without at its pace. They run automated checks after the merge and before deployment instead.

On 13 October, I measured a chain of 10 pipelines in one product repository, around 3.7 hours back to back. That is a consequence of this serial process. It does not tell me how many agent hours were lost in total.

Assigning more agents to implementation can also leave more finished work waiting at this gate. For me, that is a reason to examine the dependency between the steps first. More code alone will not remove it.

My decisions arrive in one place

Approvals, questions and acceptance decisions land in a separate queue just for me, the owner queue. Open decisions arrive there with options and a recommendation. Deciding is up to me.

From 12 to 14 October, it received 119 to 125 new items per day. Those are incoming items, not completed decisions, and they cover more than merges.

This is where I become the bottleneck myself. The agents can keep working in parallel; my attention does not multiply the same way. I describe how these items reach me in From iPhone to coding session.

What I want to change next

Three ideas from Anthropic's article fit my numbers. None of them is in place yet; these are plans.

Separate merge from deployment. That is Anthropic's approach, and I would try it on a single product first. In that setup, main builds a checked but unpublished version, and deployment only happens in the evening release window. Code could then be merged during the day.

That changes my release process and needs a deliberate decision. Simply removing the pipeline lock without defining the checks before publication would not be enough for me.

Watch the gap between main and live. Anthropic assigns Claude as “superfans” that each watch a single component. I already run a few watchers, but one is missing: one for the gap between main and what is actually live. Several times, a merged change was not live for hours, once even for days.

I describe the underlying pattern in Shipped, but never switched on. A green merge does not tell you the system is running.

Match reviews to the effect of a change. According to the article, the Scion team still reviews every change. But they check its intent rather than reading line by line. Their review tooling tells a comment-only change apart from a change to the logic.

I want to try a more targeted review process for documentation-only and test-only changes. Logic changes would still get the full review. Whether my queue actually shrinks is something I would need to measure first.

All three plans come down to the same question: which step has to wait for which? That connects them to Graph Engineering.

Before you start more agents

Look at a finished change and ask what it is waiting for:

• Is a review missing?
• Is the pipeline running?
• Is the release window closed?
• Is a decision pending?

Each of these needs a different answer. “More agents” does not tell you which one will get faster.

I would make those transitions visible first. For example, I cannot yet put a number on how much of the long MR turnaround comes from the daytime release pause. Without that attribution, I could easily work on the wrong part of the process.

My lesson from Scion is to treat integration as work in its own right and examine its waiting times. I am keeping Git. Neither a custom version control system nor a token budget on Anthropic's scale carries over to how I work.

The fleet behind this is described in Building an agent fleet. For me, the next improvement needs to show up in reviewed changes reaching users reliably.

Sources and measurement date

Anthropic: Redesigning source control at Anthropic, 13 October 2026. Anthropic's figures and the direct quotation come from this primary source.

My figures come from my internal analysis of 15 October 2026 on my private GitLab. The measurement window runs from 15 September to 15 October 2026, 07:51 UTC. It touches 31 calendar days, with only part of the final day included. The merge process described here reflects the state at the end of October 2026.