ena pragma
·16 min read·agent-architecture · ai-operations · ai-verification

Anthropic left git for its own code. What carries over to a team with ordinary repositories

Anthropic built its own source control after merges grew more than tenfold. What carries over to teams with agents writing code, what does not, and what the post leaves out.

Contents

The useful part of Anthropic's October 13 engineering post is the diagnosis, not the system. Anthropic says that once agents wrote its code, writing stopped being the slow step, and everything after it (source control, builds, checks) became the slow step. It built a replacement for git in five months and says that replacement is not for most companies. What carries over is a set of questions about your own path from finished to accepted, and those questions work at any size. Several figures in the post are self-reported, one is hard to reconcile with its own chart because the post does not say which statistic it uses, and the companies that share its diagnosis have products to sell.

This is research from public sources, not a test of ours. We did not run Scion, the system Anthropic built, or any other system named here. We read Anthropic's post, its charts and the outside pages cited below on October 14, 2026, Central time. Values we take from a chart are our reading by eye and by pixel, and we say so where we use one.

#What Anthropic changed, and why

The post, dated October 13, 2026, opens with the reason: "As our merges per day grew more than tenfold, source control became our biggest development bottleneck." It gives two figures: "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day." Both are for one very large shared repository, a monorepo. The history of its main branch is "almost 100 GB," and the post says Anthropic does "on the order of 25 million code checkouts per day for CI," where CI means the automated checks that run on a change. Fetched naively, that would be "over 600 PB of git traffic per day." That is a hypothetical, not measured traffic. The post also says a compressed working copy is "over 25 GB." Our arithmetic is that 25 million checkouts of a 25 GB copy comes to about 625 PB, so the figure assumes every checkout downloads everything.

Anthropic used the usual git workarounds. The post says that "at our peak, we operated several hundred internal git mirrors," which are extra copies of the repository placed close to the machines that need it. Then it names the root problem: "we were using git as a centralized system with one authoritative copy, but nearly all of our clients were agents and jobs that are online by definition."

The replacement, Scion, rests on a few plain choices:

  • Always online. Git "assumes that clients work offline and need a complete copy of the repository." Scion is built around "a server that is always reachable," with clients that "fetch data when they need it."
  • The server does the work. "In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on."
  • Source control as an API. Because those queries are available as calls, "in many cases jobs don't need a local repository at all."
  • Nothing to push. The post says "every commit, rebase, or merge happens on the server, so there's nothing to push." The post adds that Scion discourages branches and tags other than the main line and release branches, though it supports them.
  • No global merge queue. The post says "A proper merge queue, for example, doesn't make much sense at agent scale." It also says: "We haven't been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we've invested in post-merge and pre-deploy automated testing. This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them."

The post says "A team of seven people built both Scion and Antique," the code review tool, and fully migrated the monorepo in five months. It is plain about the limits: "Scion is by no means a suitable replacement for git for general use," and "Practically speaking, it's difficult to offer Scion in a form that would be broadly useful to other organizations."

#Reading the numbers

Three points where the post's text and charts need care. This is our reading of the charts, not a finding against the text.

Merges per day. The post says "more than tenfold" and "increased by 10x." The post's chart of changes merged per day labels 30,401 merged on September 9, and that is the last day the chart shows, although the post is dated October 13. The black 7-day average line at the chart's right edge sits near 18,000 (our pixel reading, give or take about 1,000). Against the post's May figure of 2,500, the peak day is 12 times (our arithmetic, 30,000 divided by 2,500) and the 7-day average is about 7 times. Against the roughly 2,250 the chart shows for May, the average is about 8 times. The post's own "10x" sits between those readings, and even the lower one is a very large rise. One more caution: the chart's counted unit changes partway through, from pull requests to Antique change requests, between about late May and mid-July, so a multiple over the whole series compares different units.

Two orders of magnitude. The post says "CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes)." The post's chart of median times, git against Scion, shows 31 seconds against 3.5 seconds for a checkout in a CI job (8.8 times) and 175 seconds against 22 seconds for a checkout at the start of a compute job (8.0 times). By the chart, only a developer's status command (3.9 seconds against 19 milliseconds, 207 times) clears two orders, and a new working copy in an agent environment is 84 times. The post does not say which statistic or population the sentence uses, so we cannot tell whether it describes the same measurement as the chart. We are not calling it an error. The chart's CI row is internally consistent: 25 million checkouts a day times the 27.5 seconds saved is about 191,000 hours, close to the chart's own label for that row, about 195,000 machine hours a day.

What is thin. The post says the infrastructure footprint is "200x smaller" than the old git mirroring setup, and that a rewrite of a largely hand-written first version "consumed 20x less memory and was 4x faster." Those name a comparison but give no absolute figures, period or sample size. The "25% CPU capacity win" for CI names no baseline at all. The page's text has no figure for defects, outages or reverts. It mentions revert pipelines once, as a tool built on the new API.

#What carries over to a team with ordinary repositories

Anthropic says the concepts "really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code." It also says "our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend." So the lesson is not to build a Scion. The five questions below are our reading of what holds at smaller scale, and each one is cheap to ask.

1. Where does the clock run after the code is written? The post's claim: "At Anthropic, coding is no longer the bottleneck to building systems or doing research," and "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI." Outside the company, GitHub's engineering blog (October 6, updated October 7, 2026) says "In September alone, developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier," and lists "Merges contend on one reference" among the pressures. Take one ordinary agent change and time it from the moment the agent reports it is finished to the moment it is running for customers. Write down each wait and who or what owns it.

2. What does each agent download before it can start? In the post's chart of agent environments, the median time to create a new working copy is 7.1 minutes with git and 5.1 seconds with Scion, and pulling the latest changes is 3.0 minutes against 9.0 seconds. Those are Anthropic's medians on its own monorepo, with no sample size. The shape of the fix shows up elsewhere, in vendor-written descriptions. The vendors' own speed claims are internal and unchecked: GitHub reports "up to 35 times higher write throughput" in internal benchmarks, and GitLab reports workloads that "completed up to 50x faster" in early internal tests, which it calls "peak improvements under specific test conditions." GitHub writes that "Authoritative repository data lives in Azure Blob Storage" and that "read capacity comes from lightweight workers that cache data to serve requests." GitLab, in an October 13, 2026 post, says its next-generation design "preserves the Git protocol while modernizing the architecture underneath" and describes "Stateless compute" over "shared object storage." Cursor's August 18, 2026 post describes a write-ahead log "which we store in S3-compatible object storage." A normal team does not need any of that. It needs the number: how long does a fresh agent job wait for a usable copy of your code, and does your Git host have a plan for that traffic?

3. What does "tested" mean when other changes land during the test? The post asks "What does CI even mean when hundreds or even thousands of changes can merge while tests are running?" and answers with testing after the merge, with Claude repairing conflicts. The repair rate is not given. A Hacker News comment from the account nickg-anthropic, posted October 13, 2026 at 11:04 PM Central, says: "We never allow textual conflicts, but semantic conflicts" are "an unavoidable fact of very large repos unless you completely serialize merging with running extensive validation at the proposed batch tip, which isn't practical at a certain commit rate." We take that account to be the post's lead author, Nick G., but we could not confirm it. A textual conflict is two edits to the same lines. A semantic conflict is two edits that merge cleanly and still break each other, such as one change that alters a function and another that adds a new call to it.

Outside data covers the first kind only. A July 7, 2026 arXiv study (Xu, Subramanian and Karthik) started from a dataset of 33,596 agent pull requests in 2,807 public GitHub repositories, drawn from December 2024 to July 2025. It replayed merges for one sampled pair of simultaneous pull requests per repository. It found textual conflicts in 19.8% of pairs from the same agent product (119 of 601, 95% confidence interval 16.8% to 23.2%) and 41.7% of pairs from different products (48 of 115, interval 33.1% to 50.9%), "with non-overlapping 95% confidence intervals." Mixed-product pairs are rare: 2,896 of 580,913 concurrent pairs (0.50%), in 122 of the 2,807 repositories. The authors say their method "captures only the surface layer; no tracking is done for deeper build or semantic conflicts," and call their results "a conservative lower bound." They also note the patterns "may differ in proprietary enterprise code bases with stricter branching rules." So this is public repositories from 2024 and 2025, textual conflicts, small samples and one team's replay method, set beside a monorepo where the nickg-anthropic account says textual conflicts are never allowed. They are different measurements. What both point to is the same plain question: how many agent changes may be in flight against one branch, and who repairs a bad merge?

4. Who reads what? The post says the Scion team "still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code." It says Anthropic's review tooling "can express complex semantic constraints on approvals, which lets us differentiate simple things like comment-only changes from sensitive logical changes, so that human reviewers can focus on the most consequential changes." And it warns that adversarial review, while "incredibly effective in many ways," "can also be myopic." That is one seven person team describing its own system. An analyst quoted by DevOps.com on October 8, 2026, Mitch Ashley of The Futurum Group (the page header reads "a Futurum company" beside the Techstrong logo, so the outlet appears to share a parent with the analyst's firm), says "Agent commits build verification debt faster than teams can hire reviewers to clear it" and that leaders "should require agent changes to carry evidence of what ran and why before they reach a protected branch." That is an opinion about GitHub's change, not a measurement. The part to copy is the sorting: decide which changes a person must read in full, which need only an intent check, and which need no human at all, and write it down before volume forces the choice.

5. Where do the rules live? The post says "Very often, we found that the role of the engineers was to tell Claude 'no.'" and "Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place." Its example: "there were multiple systems that tried to brute force looking up when a change merged to main by linearly reading the commit log instead of asking our code review tool." Our reading is that a rule in a prompt is a request, and a rule in the system is a limit. Anthropic's own answer included "the ability to apply permissions to individual directories." GitLab's August 26, 2026 post, which is marketing for its own private-beta product, lists a failure it sees when agents share one login: "Agents share accounts and one branch space, so they overwhelm the repository, leave no clean way to discard abandoned work, and keep no record of which agent did what." Whatever your tooling, give each agent its own identity and keep a record of what it changed.

#Who agrees, and how much that tells you

GitHub says "Agentic software development is driving the next architectural shift." GitLab says Anthropic's experience "reinforces the architectural direction we've been pursuing." Cursor describes a different shape of the problem, "vast numbers of small repositories, many of them throwaway." That is a lot of agreement since August, but treat it as correlated and not as independent confirmation. Anthropic, GitHub and Cursor sell agent products. GitLab says it has been "collaborating on the technical challenges of agent-scale development" with Anthropic and that Nick G. "joined on stage" at its June event. Their agreement shows the diagnosis is widely held by parties with a stake in it.

The designs also differ. GitLab says its design "preserves the Git protocol" and feeds "existing merge requests." GitHub says its new infrastructure is "designed to support those same workflows at much higher volumes of activity." Both are rebuilding the servers behind git and keeping the workflow people know. Anthropic left git. On novelty, Simon Willison wrote on October 13, 2026 that Scion "sounds to me like a reinvention of centralized source control along the lines of Subversion." The post itself credits Google's Piper and Meta's Sapling as prior art. A post dated October 14, 2026 on sunshowers.io, whose author says he helped build Mononoke at Meta, says Scion's "derived data" idea matches Mononoke's, and writes: "I do not have a problem with Anthropic copying Mononoke's design." The same post says the lack of credit for Mononoke "borders on plagiarism." Our judgment, not a finding: what looks new is the design target (clients that are always online and mostly agents), source control offered as an API, and merging without a queue. Much of the rest is established technique.

#What we do not know yet

  • What happened after September 9. The merge chart stops on its peak day. The sustained rate, and what happened to quality, are not shown.
  • Defect, outage and revert rates. The post has none, so "faster" is the only measured direction.
  • How often Claude's conflict repair works. The post's words are "can typically fix," with no rate, and it does not say what breaks when a repair fails.
  • What replaces CI. The post asks what CI means when thousands of changes land during a test run. Its stated answer, testing after the merge, comes with no results.
  • Whether reading intent catches what reading lines would. The post says Anthropic could "easily write a whole other blog post" about Antique, the review tool, and describes it only briefly.
  • Limits Anthropic accepts. On offline work, the Hacker News commenter says (October 13, 2026, 5:00 PM Central): "Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn't important to do." On changes across repositories, in the 11:04 PM comment: "As for cross-repo changes, not exactly, but there are ways we could allow such a thing if we wanted." How many companies could live with both is open.
  • When the five months started. The post's chart of changes to the Scion and Antique directories shows activity from about late January or early February. The post does not say when its five months begin.
  • Anthropic's internal numbers. None can be checked from outside.

Related field notes: Agents did not clear the backlog, they moved the bottleneck covers the cost of oversight when the work gets cheap, and Why your AI review is slow even when the AI is right covers the size of the unit a person is asked to check.

Our read, which is a judgment and not a finding: when producing work gets cheap, accepting work becomes the system you run. Anthropic's version is extreme, a seven person team and a custom repository. The ordinary version is a question any owner can ask this week. For the last ten changes an agent made, can you say who or what accepted each one, on what evidence, and how long it waited? Where the honest answer is that nobody did and no one knows, the agents are not the problem. The path after them is.

#Sources

Keep reading