本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Redesigning source control at Anthropic

Published Oct 13, 2026

2026年10月13日发布

As our merges per day grew more than tenfold, source control became our biggest development bottleneck. Here, we share how we migrated to an in-house version control system in five months.

随着我们每日合并代码的次数增长了十倍以上，源代码控制成为了我们最大的开发瓶颈。在此，我们将分享如何在五个月内迁移到自研版本控制系统的过程。

At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

在 Anthropic，编码已不再是构建系统或进行研究的瓶颈。Claude 能够以我们前所未见的速度和规模，自主迭代研究循环、微优化复杂程序，并从零开始构建新服务。现在的瓶颈在于所有为人类规模而设计的开发者基础设施：源代码控制、构建和持续集成（CI）。

In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

2026年5月，Anthropic 平均每天合并约 2,500 次代码变更；到了9月，我们每天合并超过 30,000 次。我们预计这种增长速度短期内不会放缓；合并代码的潜在需求几乎是无限的，我们消除的每一个瓶颈都会立即导致我们产出的代码量进一步增加。

In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months. We also built and shipped a code review surface (called Antique), code search, a rich source control IAM system, novel ways of managing and landing large amounts of reviewed code, and more, all in that same time period. In this post, we’ll focus on how we built Scion specifically. It makes for an interesting case study: Claude’s ability to write code was both what put us in this situation in the first place and how we were able to quickly build a high-quality, scalable system to deal with it.

为了支持这种增长，我们构建了自研版本控制系统 Scion，并在五个月内将我们的单体仓库（monorepo）从 git 完全迁移出来。在同一时期，我们还构建并发布了代码审查界面（称为 Antique）、代码搜索、功能丰富的源代码控制 IAM 系统，以及管理和提交大量已审查代码的新颖方法等。在本文中，我们将专门探讨如何构建 Scion。这是一个有趣的案例研究：Claude 的编码能力既是让我们陷入当前局面的原因，也是我们能够快速构建高质量、可扩展系统来应对这一局面的手段。

Before we explore what we built, we should acknowledge how unusual our workload is. Unsurprisingly, Anthropic uses Claude to write software far more than almost any other company, so we’re often the first to see where tools built for human scale start to strain. Source control is just one example of this. While we don’t expect many organizations to have these problems in the very near term, we suspect it won’t be too long before others who use AI coding tools experience these same pressure points, which is why we wanted to share what we built and what we learned.

在探讨我们构建的内容之前，我们应该承认我们的工作负载是多么不同寻常。不出所料，Anthropic 使用 Claude 编写软件的频率远超几乎任何其他公司，因此我们往往最先发现为人类规模设计的工具在何处开始吃力。源代码控制只是其中的一个例子。虽然我们预计短期内不会有太多组织遇到这些问题，但我们怀疑，其他使用 AI 编码工具的组织很快也会经历同样的压力点，这就是我们想要分享我们的构建成果和经验教训的原因。

Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design, and it’s a large part of why git became the standard.

Git 是一个去中心化系统：每个克隆都是一个完整、独立的仓库，可以在完全离线的情况下计算差异、读取历史记录和 blame 信息，并检出任何修订版本。对于绝大多数仓库而言，这是正确的设计，这也是 git 成为标准的重要原因。

As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

随着我们的单体仓库不断增长，它越来越不适合这种设计空间。仅我们主分支的历史记录就接近 100 GB，压缩后的工作副本超过 25 GB。我们每天为 CI 执行约 2500 万次代码检出，这还不包括开发者环境、智能体沙箱和研究任务。如果采用原始的获取方式，每天的 git 流量将超过 600 PB。

Git offers tools for working with a slice of a repository, such as shallow clones, sparse checkouts, and promisor remotes. Beyond these, there are standard workarounds for large monorepos, like internal git mirrors and repository snapshots (seeds) kept in blob storage. We’ve used all of them—at our peak, we operated several hundred internal git mirrors to deal with the load. This bought us time, but they became harder to operate as our merge rate increased. Seeds fell further from the tip of main between refreshes, and it took more and more care to keep operations that depend on history, like diff and blame, working on partial clones.

Git 提供了处理仓库片段的工具，例如浅克隆、稀疏检出和 promisor 远程仓库。除此之外，针对大型单体仓库还有一些标准的变通方法，例如内部 git 镜像和存储在 blob 存储中的仓库快照（seeds）。我们都使用过这些方法——在高峰期，我们运行了数百个内部 git 镜像来应对负载。这为我们争取了时间，但随着合并率的增加，它们的维护变得越来越困难。在两次刷新之间，种子（seeds）距离主分支顶端的差距越来越大，并且需要花费越来越多的精力来确保依赖历史记录的操作（如 diff 和 blame）在部分克隆上正常工作。

Taking a step back, we noticed that, like most companies, 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 properties that make git excellent for distributed, offline work were actively undermining our ability to scale as the repo grew. So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like?

退一步看，我们注意到，像大多数公司一样，我们实际上是将 git 作为一种具有单一权威副本的集中式系统来使用，但我们几乎所有的客户端都是本质上始终在线的智能体和任务。使 git 成为分布式、离线工作优秀工具的特性，反而随着仓库的增长削弱了我们扩展的能力。因此我们问自己：如果我们从一开始就考虑到智能体始终在线这一事实来设计源代码控制，它会是什么样子？

With agentic coding, many common assumptions about how software is developed are evolving. We embraced these changes when building Scion, which allowed us to take a fundamentally different approach than git on several core principles. Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind. Our principles are:

随着智能体编码的出现，许多关于软件开发方式的常见假设正在演变。在构建 Scion 时，我们拥抱了这些变化，这使我们在几个核心原则上采取了与 git 根本不同的方法。针对大型单体仓库的源代码控制已有先例，特别是 Google 的 Piper 和 Meta 的 Sapling，因此我们在构建 Scion 时借鉴了他们来之不易的经验。我们的原则是：

Clients are always online. Git assumes that clients work offline and need a complete copy of the repository. Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable, and have clients fetch data when they need it.

客户端始终在线。Git 假设客户端在离线状态下工作，并且需要仓库的完整副本。由于我们几乎所有的客户端都是智能体和任务，我们围绕一个始终可达的服务器设计了 Scion 的客户端和协议，并让客户端在需要时获取数据。

Client-server asymmetry. In git, every client is capable of being a full-fledged server. In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on. The client maintains a bounded local object cache, lays out the working copy files on disk, monitors for filesystem changes, and gives users an ergonomic way to work with the server. It can compute very little on its own but, in exchange, it requires much less data locally.

客户端-服务器不对称。在 git 中，每个客户端都有能力成为一个功能齐全的服务器。在 Scion 中，服务器负责回答关于文件历史和 blame 的问题、创建提交、执行合并和变基等。客户端维护一个有限的本地对象缓存，在磁盘上布局工作副本文件，监控文件系统变更，并为用户提供与服务器交互的便捷方式。它自身能计算的内容很少，但作为交换，它在本地需要的数据量也少得多。

A comprehensive source control service can power many novel applications. With git, a CI job or tool that needs to ask a question about the repository, such as who last changed a line or how two commits are related, has to maintain a local copy of the repo or hope that vendor-specific APIs provide the answer. With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all. Many internal tools, such as our automated bisect and revert pipelines, wouldn’t be practical at scale without this cheap, programmatic access to source control.

全面的源代码控制服务可以支持许多新颖的应用。使用 git 时，需要查询仓库信息的 CI 任务或工具（例如谁最后修改了一行代码，或者两个提交之间有何关联）必须维护一个本地仓库副本，或者寄希望于供应商特定的 API 能提供答案。使用 Scion，客户端使用的所有源代码控制查询也通过 API 公开，因此在许多情况下，任务根本不需要本地仓库。如果没有这种廉价的、程序化的源代码控制访问方式，许多内部工具（如我们的自动二分查找和回滚流水线）在大规模环境下将无法实现。

Everything must be horizontally scalable. At our peak, we ran several hundred git mirrors, which significantly strained capacity and no longer scaled once the repo outgrew the mirrors’ disks or memory.

一切都必须是水平可扩展的。在高峰期，我们运行了数百个 git 镜像，这极大地消耗了容量，一旦仓库大小超过了镜像的磁盘或内存限制，它们就无法再扩展了。