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 的写码能力既是把我们逼进这个处境的原因，也是我们能快速造出高质量可扩展系统来应对的原因。
Growing our monorepo · monorepo 的膨胀
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 是去中心化系统：每个 clone 都是完整自足的仓库，可以完全离线地算 diff、读历史与 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.
但随着 monorepo 膨胀，它越来越不适合这个设计空间。仅主分支的历史就接近 100 GB，一份压缩工作副本超过 25 GB。我们每天为 CI 执行约 2,500 万次代码检出——还没算开发环境、agent 沙箱和研究任务。如果按 naive 方式抓取，那将是每天超过 600 PB 的 git 流量。
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 提供了一些只处理仓库切片的工具，比如浅克隆（shallow clone）、稀疏检出（sparse checkout）与 promisor remote。除此之外还有大型 monorepo 的标准变通：内部 git 镜像、放在 blob 存储里的仓库快照（种子）。我们全都用过——峰值时运营着几百个内部 git 镜像来扛负载。这争取到了时间，但随着合并率上升，它们越来越难伺候：种子在两次刷新之间离 main 的尖端越来越远，让 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 当作只有一份权威副本的中心化系统在用，但我们的客户端几乎全都是天生在线的 agent 与任务。让 git 在分布式离线工作中出色的那些特性，正在主动破坏仓库变大后的扩展能力。于是我们问自己：如果从一开始就带着「agent 永远在线」这个事实来设计源码控制，它会是什么样子？
Principles for agent-scale source control · Agent 规模源码控制的原则
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:
随着 agentic coding 兴起，关于软件如何开发的许多默认假设都在演化。造 Scion 时我们拥抱了这些变化，得以在几条核心原则上采取与 git 根本不同的路线。巨型 monorepo 的源码控制有先例——最著名的是谷歌的 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 假设客户端离线工作、需要仓库的完整副本。既然我们的客户端几乎全是 agent 与任务，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 的问题、创建提交、执行合并与 rebase 等等；客户端维护一个有界本地对象缓存、把工作副本文件摆到磁盘上、监听文件系统变化、给用户一个人体工学的方式与服务器协作。它自己几乎不算什么——作为交换，它需要的数据也少得多。
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 暴露，很多情况下任务根本不需要本地仓库。许多内部工具——比如自动化 bisect 与 revert 管道——若没有这种便宜的、可编程的源码控制访问，根本不可能规模化。
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 limits. In Scion, the repository's data is distributed, and every component is independently scalable; there is no fully materialized copy of the repo anywhere, even on the server. There is no equivalent of packfiles (git's compressed bundles of objects), so no repository maintenance is needed.
**一切必须水平可扩展。** 峰值时我们跑几百个 git 镜像，容量吃紧，而且一旦仓库超出镜像的磁盘或内存上限就再无扩展可言。Scion 里仓库数据是分布式的，每个组件独立可扩展；任何地方都不存在全量物化的仓库副本——服务器上也没有。没有 packfile（git 的对象压缩包）对应物，也就不需要仓库维护。
Commits must be cheap, incremental, and lock-free. In git, you commit locally and then push to share your work. In Scion, every commit, rebase, or merge happens on the server, so there's nothing to push, but each of those operations needs to be fast. The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo, or the server can't keep up. The development lifecycle in Scion discourages refs (pointers to commits, such as branches and tags), except for the main ref or release branches, because global state that every server has to agree on is a looming scaling problem.
**提交必须便宜、增量、无锁。** Git 里你本地提交然后 push 分享。Scion 里每次提交、rebase、合并都发生在服务器上——没有东西可 push，但每个操作都必须快。创建提交与更新其下游数据结构的成本必须随变更大小伸缩，而不是随仓库总大小，否则服务器跟不上。Scion 的开发周期不鼓励 ref（指向提交的指针，如分支与标签）——main 和发布分支除外——因为「每台服务器都必须达成一致的全局状态」是一个迫在眉睫的扩展问题。
The working copy is optional, and sparse by design. Because our monorepo is so large, and because we check out code tens of millions of times a day for CI, we wanted to avoid checkouts whenever we could. With Scion, a CI job that needs the diff between a commit and its merge base, for example, can ask the server for it. The same goes for writes: many write workloads can also skip the checkout and function entirely via API. Scion's protocol is centered around sparse checkouts, which only contain the directories the client asks for, and virtualized checkouts, which materialize files on demand, so when a job does need files on disk, the client only pays for what it actually reads.
**工作副本是可选的，且天生稀疏。** 因为 monorepo 太大、每天为 CI 检出代码上千万次，我们能避免检出就避免。Scion 里，一个需要「提交与其合并基之间的 diff」的 CI 任务可以直接问服务器要。写也一样：很多写负载同样可以跳过检出、纯走 API。Scion 的协议围绕稀疏检出（只含客户端要的目录）与虚拟化检出（按需物化文件）展开——任务真需要磁盘上的文件时，客户端只为它实际读取的内容付费。
How Scion works · Scion 怎么工作
It's helpful to understand how these principles came together in practice when building Scion. These insights can apply to other source control systems or, more broadly, to other stages of the software development lifecycle.
看看这些原则在造 Scion 时如何落地，会很有帮助。这些洞见也适用于其他源码控制系统，或更广泛地，适用于软件开发生命周期的其他阶段。
### Data structures · 数据结构 In Scion, the unit of work is a "changeset," an entry in a write-ahead log. A changeset stores most of what you'd expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere, instantly.
Scion 的工作单元是「changeset」——write-ahead log 里的一条记录。它存了你对 git commit 期望的大部分内容，区别在于：git commit 存一个指向树对象的指针，changeset 存的是相对其首父变更的文件列表，外加指向 blob 存储中压缩文件内容的按内容寻址的指针。Changeset 在服务端创建，即时全局可用。
This structure lets us accept changesets with very high throughput because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move around. Scion does technically support refs, but since neither creating nor fetching commits involves them, moving one is a compare-and-swap on a single Spanner row that happens separately from creating changesets.
这种结构让我们能以极高的吞吐接收 changeset：没有 packfile 要接收、没有锁或跨服务器协调、没有 ref 要搬动。Scion 技术上支持 ref，但由于创建与获取提交都不涉及它，移动一个 ref 只是对单个 Spanner 行做一次 compare-and-swap，与创建 changeset 完全分离。
A changeset records only what's changed, so on its own, it can't quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn't directly part of the changeset "derived data," and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset's parents.
Changeset 只记录变更了什么，所以单凭它答不了「这行最后谁改的」「哪些提交动过这个文件」这类问题。为了回答它们，Scion 从 changeset 构建额外的数据结构：文件 blame 与路径历史的专用结构、提交图的跳表（skip list）。凡是不是 changeset 直接组成部分的东西我们都叫「派生数据」（derived data），全部通过一套通用机制计算：每类派生数据递归定义——它在某条 changeset 上的值，由它在该 changeset 各父上的值算出。
This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don't need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We've added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search.
这套机制有三个好处。一，当新数据结构能让某个操作更快时，加一类新派生数据很容易。二，每类数据可以选择急算还是缓算，避免物化不需要的数据。三，客户端永远看不到这些结构的内部，我们可以随意优化而不用改客户端。系统成长过程中我们加过很多次新派生数据，比如做复制检测或按路径文件搜索的新索引。
### Scaling Scion · Scion 的扩展 A small fleet of Scion servers provides source control APIs for any operation a client needs, such as getting changesets, computing diffs, finding merge bases, and fetching blobs. All source control data is content-addressed, so a piece of data never changes once it's stored, and any server can cache it without checking with the others. As a result, the servers are horizontally scalable and require little coordination. They are essentially large caches that can also compute derived data on the fly and write the results back to Spanner.
一小队 Scion 服务器为客户端需要的任何操作提供源码控制 API：取 changeset、算 diff、找合并基、取 blob。所有源码控制数据都按内容寻址——数据一旦写入永不变，任何服务器都能放心缓存而无需与其他服务器核对。因此服务器水平可扩展、几乎无需协调。它们本质上是大型缓存，外加能顺手计算派生数据并把结果写回 Spanner。
Scion's many consumers no longer need to maintain local repositories of their own. Fetching and maintaining the repository used to be a significant maintenance burden for CI jobs or tools that needed to ask source control questions, particularly about commit ancestry and blame. Early in the migration, before we had our own client, repo format, or protocols, Scion only answered these "metadata" queries. Fetching file contents and materializing working copies are far more data-intensive operations, and they needed a design of their own.
Scion 的众多消费方不再需要各自维护本地仓库。以前，抓取与维护仓库对 CI 任务或需要问源码控制问题的工具（尤其是提交祖先与 blame 类问题）是显著的维护负担。迁移早期，在我们有自己的客户端、仓库格式与协议之前，Scion 只回答这些「元数据」查询。抓取文件内容与物化工作副本是数据密集得多的操作，需要单独的设计。
Scion's scn client deviates from git's fetch protocols in several important ways and, as a result, lends itself to a highly scalable architecture that requires significantly less CPU than git servers. Scion's negotiation doesn't tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs. Every request is for a specific object that never changes, so any cache can answer it, and the architecture closely resembles traditional tiered caches. The process is also efficient and resumable, because there is no single multi-gigabyte packfile response. Sparse and even virtualized checkouts don't need special support, because the client simply doesn't ask for trees it doesn't want.
Scion 的 scn 客户端在几个关键点上偏离了 git 的 fetch 协议，因此天然适合一种比 git 服务器省 CPU 得多的高度可扩展架构。Scion 的协商不告诉服务器「客户端已有什么」，而是完全围绕「客户端想要哪些树和 blob」运作：从根树出发，客户端检查本地缺哪些树、递归请求，然后对 blob 重复这一过程。每个请求都针对一个永不变的具体对象，任何缓存都能应答——整个架构非常像传统的分层缓存。过程也高效且可续传，因为不存在动辄数 GB 的单个 packfile 响应。稀疏甚至虚拟化检出不需要特殊支持——客户端干脆就不请求它不想要的树。
In the fleet, the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node. Most of our nodes need access to the monorepo, and jobs on the same node reuse most of the same objects. Each daemon starts from a periodically refreshed snapshot, then talks only to the tree and blob cache servers in its region, called scion-cache. These cache servers stream objects directly from memory, in the disk format that the daemon will consume, so they don't need to spend time computing the client's missing objects or performing delta compression. When a cache is missing an object, it asks the authoritative scion-servers, which read from Spanner or cloud storage as needed.
在机群中，客户端通过 socket 与一个守护进程 scion-daemon 通信，它为整个节点存对象。我们多数节点都需要访问 monorepo，同一节点上的任务复用大部分相同的对象。每个 daemon 从定期刷新的快照起步，之后只与本区域的树与 blob 缓存服务器（叫 scion-cache）通信。这些缓存服务器直接从内存流出对象、用的就是 daemon 将要消费的磁盘格式——因此不必花时间计算客户端缺的对象，也不必做差分压缩。缓存缺对象时，它去问权威的 scion-server，后者按需读 Spanner 或云存储。
The scion-daemon, scion-cache, and scion-server all respond to identical RPCs for this protocol, so the client doesn't need to know the cache topology. Any tier could theoretically talk to any other, but we strictly enforce the tiering to isolate failure domains. We want to avoid a situation where a failure in a regional scion-cache overwhelms the upstream scion-servers and brings down the entire system.
scion-daemon、scion-cache、scion-server 对这套协议应答完全相同的 RPC，客户端不需要知道缓存拓扑。任何一层理论上都可以与任何其他层通信，但我们严格执行分层以隔离故障域——要避免「一个区域 scion-cache 的故障冲垮上游 scion-server、带崩整个系统」的局面。
Each tier of this system maintains a cache hit rate of over 99% and does not require long-lived state, so it's easy to scale up if needed. Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win. Neither clients nor caches need to perform repository maintenance, which simplifies the lifecycle management of our jobs.
这套系统的每一层都保持 99% 以上的缓存命中率，且不需要长期状态，需要时扩容很容易。以 CPU 与内存需求计，我们的 Scion 基建足迹比之前的 git 镜像基建小 200 倍。CI 与研究任务的代码检出快了两个数量级（秒级而非分钟级），为整个机群腾出了可观的容量——仅 CI 一项就收获 25% 的 CPU 容量。客户端与缓存都不需要做仓库维护，任务的生命周期管理随之简化。
What we learned building Scion · 造 Scion 学到的
We started building Scion around the same time as Claude Mythos Preview and Claude Tag became available internally. Both of these releases simultaneously amplified the need for Scion and meaningfully accelerated how quickly we could build it.
我们开始造 Scion 的时间，差不多是 Claude Mythos Preview 与 Claude Tag 对内可用的时候。这两个发布一边放大了对 Scion 的需求，一边实打实加快了我们建造它的速度。
Here's a particularly striking example. Earlier in the year, we had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. We thought it was good—until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures.
一个特别惊人的例子：今年早些时候，我们基本手写了 git 到 Scion 摄取管道的第一版原型。我们觉得挺好——直到拿到 Claude Mythos Preview 的早期内部快照。我们让它重写整个东西，没给任何补充指令，它产出的版本省了 20 倍内存、快了 4 倍，同时完整保留了摄取顺序与数据结构周围所有隐式不变量。
What we learned building and operating Scion offers some interesting lessons for what building agent-scale software could look like.
建造与运营 Scion 的经验，对「agent 规模的软件该怎么造」给出了一些有意思的启示。
Rapid development with a small team will become more common. A team of seven people built both Scion and Antique (our code review tool, which we could easily write a whole other blog post about), not to mention half a dozen related systems, and fully migrated to them in five months. We did all this while the volume of code merged per day increased by 10x. In the past, developing and deploying a source control system like this would have taken a company years of iterative migration, with many more engineers. We think this sort of fast, nimble migration will become more common in the future.
**小团队的快速开发会更常见。** 七个人的团队造了 Scion 和 Antique（我们的代码审查工具——它轻松值得再写一篇博客），外加半打相关系统，并在五个月里完成整体迁移——同期日均合并量还涨了 10 倍。放在过去，这样的源码控制系统从开发到上线要一家公司花数年、动用多得多的工程师迭代迁移。我们相信这种快而轻的迁移今后会越来越常见。
Engineers are no less valuable, but their work is changing. All of the engineers who worked on this system would now rate Claude as better at writing code than them. But our engineers still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs, making informed choices around the problems we wanted to solve and the scale we knew we needed to achieve. Very often, we found that the role of the engineers was to tell Claude "no." Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. This was particularly common in our migration. For 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. Anthropic also makes extensive use of adversarial review, and, while this is incredibly effective in many ways, it can also be myopic, so skilled engineers needed to steer Claude away from over-engineering parts of the system in response to hypothetical concerns. For example, one such review was overly defensive about trusting another internal service, which resulted in Claude adding excessive validation and complexity. Our team members 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.
**工程师依然重要，但工作在变。** 参与这套系统的所有工程师如今都会承认 Claude 写代码比自己强。但我们的工程师仍然提供了无可替代的东西：对高层系统间组件的理解、设计层取舍的把握——围绕「我们要解什么问题、需要撑什么规模」做出有根据的选择。很多时候，工程师的角色是对 Claude 说「不」：agent 有时会为了满足某种本就不该被允许的模式而违反核心系统约束。这在迁移期尤其常见——比如多个系统试图用线性读提交日志的蛮力方式查「某变更何时合入 main」，而不是去问代码审查工具。Anthropic 还大量使用对抗式审查，它虽然在很多方面极其有效，但也可能短视：熟练工程师需要把 Claude 从「为假想的担忧给系统某部分过度工程化」里拉出来——比如某次对抗审查对「信任另一个内部服务」过度防御，导致 Claude 加了一堆多余的校验与复杂度。团队成员仍然审查系统的每一次变更请求，但现在审的是变更的意图，而不是逐行读代码。
We were able to substantially improve optimization and quality. By virtue of Claude's ability to write immense amounts of code much faster than we could ourselves, Scion is among the most well-tested and well-defended codebases we have ever worked on. Even on our tight timeline, we were able to build hermetic simulations of every non-trivial infrastructure and source control interaction we've ever encountered, as well as fuzzing and sophisticated rate limiting. Claude also casually found significant optimizations—for example, an algorithmic optimization to ancestry queries that missed one of our indexes—that would have taken an expert days or weeks of analysis and tuning… and then did it all again the next day.
**优化与质量被大幅拉高。** 凭借 Claude 远快于我们的海量写码能力，Scion 是我们经手过测试与防护最完善的代码库之一。即便时间线这么紧，我们也为我们遇到过的每一个非平凡的基建与源码控制交互建了封闭仿真，外加模糊测试与精细的限流。Claude 还顺手找到了显著的优化——比如对祖先查询的一个算法级优化（绕开了我们的一个索引）——这种事放人工要专家分析调优数天数周……然后它第二天又来了一次。
We laid the groundwork for new forms of monorepo security. Managing safety, security, and compliance in a massive monorepo is as important as managing the size and scale. We built Scion with these in mind from the start. It supports rich access control on repositories, as well as the ability to apply permissions to individual directories in order to protect the most sensitive code without losing the benefits of a monorepo. Furthermore, the code review tooling we built 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.
**我们为 monorepo 安全的新形态打了地基。** 在巨型 monorepo 里管理安全性、保密性与合规，与管理局面和规模同等重要。Scion 从第一天就为此设计：支持仓库级的丰富访问控制，还能对单个目录施加权限——保护最敏感的代码而不放弃 monorepo 的好处。此外，我们建的代码审查工具能对审批表达复杂的语义约束，让我们能区分「只改注释」与「敏感逻辑变更」这类差别，让人类审查者聚焦最有分量的变更。
A new level of operational excellence is possible. Our team uses Claude Tag heavily, which has helped us monitor each component of the system. For example, we created Slack channels where we tasked Claude with being obsessively focused on the health of a single component. We call these Claudes "superfans." We have a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, and so on. They have access to our telemetry and logs, and act like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange. We also have traditional alerts for all of our systems, but our superfans can detect subtle and novel issues that make these alerts seem one-dimensional by comparison.
**运维卓越的新层次成为可能。** 团队重度使用 Claude Tag 来监控系统的每个组件。比如我们建了一些 Slack 频道，指派 Claude 着魔般地盯单个组件的健康。我们管这些 Claude 叫「superfan」：有 scion-daemon superfan、scion-cache superfan、Antique merge queue superfan，等等。它们能读我们的遥测与日志，表现得像一位经验丰富、除了刷图表找异常以外无事可做的工程师。传统告警我们也都还有，但 superfan 能发现微妙而新颖的问题——相比之下那些告警显得很单维。
We're completely rethinking our priors. This project prompted us to take a very hard look at other workflows designed for human scale. 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? 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.
**我们在彻底重查先验。** 这个项目逼我们重新审视其他为人类规模设计的工作流。比如，正经的 merge queue 在 agent 规模下没什么意义：当几百甚至上千个变更可以在测试运行期间完成合并，CI 还算什么？我们没法有效复刻「merge queue 上的全局仓库锁」这个行业标准，于是转而投资合并后与部署前的自动化测试。这确实意味着并发变更可能冲突——但 Claude 修这些冲突的速度，通常比人类识别出冲突的速度还快。
Contributing to the wider ecosystem · 回馈生态
We see Scion as just one part of the answer to the scaling concerns that increasingly capable AI agents have raised. We're sharing these details as an example of how teams can tackle similar challenges, though we don't expect our solution, or our considerations, to suit every case.
我们把 Scion 看作日益强大的 AI agent 引发的扩展性问题的一部分答案。分享这些细节是给「团队如何应对类似挑战」打个样——但我们不指望我们的方案或考量适合每一种情况。
Scion is by no means a suitable replacement for git for general use. The concepts we've outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code. Plus, Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. We do this both to address our own software development needs, and to test Claude's capabilities.
Scion 绝非 git 的一般用途替代品。这些概念只在真正巨大的 monorepo 上才成立——要么几万名工程师、要么成群的 agent 高产写码。另外 Anthropic 的独特之处在于：我们能为内部使用支付的 token 远超任何其他企业现实愿意花的量级。我们这样做既为解决自己的软件开发需求，也为测试 Claude 的能力上限。
Practically speaking, it's difficult to offer Scion in a form that would be broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI. Our internal versions of these components are highly bespoke, so they would be difficult for other organizations to adopt, and we worry that attempting to build a public version that tries to please everyone wouldn't actually be very useful.
实际地说，很难以「对其他机构普遍有用」的形态提供 Scion。它与 git 分歧巨大——公司得迁移开发生命周期的每一环，还得配自己的代码审查、代码搜索与 CI。这些组件的内部版本高度定制，其他机构难以采用；而试图取悦所有人的公开版本，我们担心其实不会太有用。
However, we anticipate that this class of problems will become more commonplace over the next six to 12 months, and it would be an inefficient use of engineering resources for every company using git to face similar challenges alone. Given that, we think the most impactful thing we can do is to share our thinking, so that other developers can apply some of the most successful parts of Scion to git without departing from the overall model. A git server doesn't have to work the same way as a git client does; novel server architectures exist that provide significant scaling improvements. Git platforms can provide comprehensive server-side RPCs like Scion, perhaps even in a standardized way across forges that the git client can learn to talk to. The negotiation protocol doesn't have to look exactly like it does today, either, and the various sparse and shallow features in git can be made to compose well.
不过我们预期，这类问题在未来 6 到 12 个月会变得常见；每个用 git 的公司都单独面对同样的挑战，是对工程资源的浪费。因此我们认为最有影响力的做法是分享思考：让其他开发者把 Scion 最成功的部分应用到 git 上，而不必离开整体模型。git 服务器不必与 git 客户端以同样的方式工作——能带来显著扩展改善的新型服务器架构是存在的。Git 平台可以提供 Scion 式的全面服务端 RPC，甚至可以跨 forge 标准化、让 git 客户端学会与之对话。协商协议也不必是今天这副样子，git 里各种稀疏与浅克隆特性也完全可以组合得更好。
Lastly, we want to acknowledge that the git community has spent nearly two decades scaling the platform for millions of developers. Our contribution is far narrower: sharing our early view into how agentic software development interacts with these systems, so that we can partner with GitHub, GitLab, and the OSS community to support the changing needs of developers. We're all in it together as the software development lifecycle intersects with the AI exponential.
最后要说明：git 社区花了近二十年为数百万开发者扩展这个平台。我们的贡献窄得多——分享「agentic 软件开发如何与这些系统互动」的早期视角，以便与 GitHub、GitLab 和开源社区合作，支持开发者变化中的需求。当软件开发生命周期撞上 AI 指数曲线，我们同在一条船上。
Acknowledgements · 致谢
Written by Nick G. and the source control team: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. We're grateful to Vilas J. and Sergiu D. for supporting the source control team on this ambitious journey and Amir O. for early contributions to Antique.
作者：Nick G. 与源码控制团队（S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.）。感谢 Vilas J. 与 Sergiu D. 在这段雄心之旅中对源码控制团队的支持，感谢 Amir O. 对 Antique 的早期贡献。