Anthropic заменила git на собственную систему Scion для монорепозитория за пять месяцев

Anthropic опубликовала в инженерном блоге рассказ о Scion, собственной системе контроля версий, на которую компания за пять месяцев полностью перенесла свой монорепозиторий с git. По словам Anthropic, написание кода перестало быть узким местом: Claude способен автономно вести исследовательские циклы, микрооптимизировать сложные программы и строить новые сервисы с нуля. Узким местом стала вся инфраструктура разработки, рассчитанная на человеческий масштаб: контроль версий, сборки и CI.

Компания приводит такие цифры: в мае 2026 года она в среднем сливала около 2 500 изменений кода в день, а по состоянию на сентябрь, более 30 000 в день. Замедления роста Anthropic не ждёт: спрос на слияние кода, по её словам, практически бесконечен, а каждое устранённое ограничение сразу увеличивает объём производимого кода. За те же пять месяцев, помимо Scion, компания сделала интерфейс код-ревью Antique, поиск по коду, развитую систему управления доступом (IAM) для контроля версий и новые способы приёма больших объёмов проверенного кода.

Почему git перестал подходить. Git, децентрализованная система: каждый клон содержит полный репозиторий и умеет работать полностью офлайн. Для большинства репозиториев это правильный дизайн, но монорепозиторий Anthropic в него не укладывается. История одной только основной ветки занимает почти 100 ГБ, сжатая рабочая копия, больше 25 ГБ. Для CI выполняется порядка 25 миллионов выгрузок кода в сутки, и это без учёта сред разработчиков, песочниц агентов и исследовательских задач. При наивной загрузке это дало бы более 600 ПБ git-трафика в день.

Стандартные средства работы с частью репозитория (shallow clone, sparse checkout, promisor remotes) и обходные приёмы для больших монорепозиториев (внутренние git-зеркала и снимки-«семена» в blob-хранилище) компания использовала все. На пике она держала несколько сотен внутренних git-зеркал. Это выиграло время, но по мере роста частоты слияний эксплуатация усложнялась: «семена» всё сильнее отставали от вершины main между обновлениями, а операции, зависящие от истории (diff и blame), на частичных клонах требовали всё больше усилий. Авторы заметили, что используют git как централизованную систему с одной авторитетной копией, а почти все их клиенты, агенты и задания, которые онлайн по определению. Отсюда вопрос: как выглядел бы контроль версий, если бы с самого начала проектировать его с расчётом на постоянно подключённых агентов.

Принципы Scion. Опираясь на опыт Piper от Google и Sapling от Meta, Anthropic сформулировала пять принципов. Клиенты всегда онлайн: клиент и протоколы рассчитаны на всегда доступный сервер, данные подтягиваются по требованию. Асимметрия клиента и сервера: сервер отвечает на вопросы об истории и blame, создаёт коммиты, выполняет слияния и перебазирования; клиент держит ограниченный локальный кэш объектов, раскладывает файлы рабочей копии, следит за изменениями в файловой системе и почти ничего не вычисляет сам. Все запросы клиента к контролю версий доступны и через API, поэтому многим заданиям локальный репозиторий не нужен, а внутренние инструменты вроде автоматических конвейеров bisect и revert без такого дешёвого программного доступа не были бы практичны в масштабе. Всё горизонтально масштабируется: данные репозитория распределены, нигде, даже на сервере, нет полностью материализованной копии, нет аналога packfile, поэтому не нужно и обслуживание репозитория. Коммиты должны быть дешёвыми, инкрементальными и без блокировок: каждый коммит, перебазирование или слияние выполняется на сервере, так что отправлять нечего, а стоимость растёт с размером изменения, а не всего репозитория; ссылки (ветки, теги) поощряются только для main и релизных веток. Рабочая копия необязательна и разрежена по умолчанию: CI-задание может запросить у сервера, например, diff между коммитом и его merge base, не делая выгрузки; протокол строится вокруг разреженных и виртуализированных выгрузок, где файлы материализуются по мере чтения.

Устройство. Единица работы, «changeset», запись в журнале упреждающей записи (write-ahead log). Она хранит список изменённых файлов относительно первого родителя и адресуемые по содержимому указатели на сжатое содержимое в blob-хранилище. Changeset создаётся на сервере и сразу доступен везде. Такая структура позволяет принимать их с очень высокой пропускной способностью: нет packfile, блокировок и координации между серверами, ссылки не двигаются. Ссылки Scion технически поддерживает, но перемещение ссылки, это операция compare-and-swap над одной строкой Spanner, отдельная от создания changeset.

На вопросы вроде «кто последним правил строку» changeset сам не отвечает, поэтому из них строятся дополнительные структуры: для blame, истории путей и списки пропусков для графа коммитов. Всё, что не входит в changeset, называется «производными данными» (derived data) и вычисляется одним общим механизмом: значение каждого типа для changeset определяется рекурсивно через значения его родителей. Выгоды три: легко добавлять новые типы, можно выбирать между немедленным и отложенным вычислением, а клиент не видит внутренностей, поэтому структуры можно оптимизировать без изменений клиента. Среди добавленных позже типов, индексы для обнаружения копирования и поиска файлов по пути.

Небольшой парк серверов Scion предоставляет API для всех операций: получение changeset, вычисление diff, поиск merge base, выдача blob. Все данные адресуются по содержимому и неизменны, поэтому любой сервер кэширует их без согласования с другими. Серверы горизонтально масштабируются и по сути представляют собой большие кэши, которые могут вычислять производные данные на лету и записывать результат обратно в Spanner. На раннем этапе миграции, ещё до собственного клиента, формата репозитория и протоколов, Scion отвечал только на «метаданные»-запросы.

Клиент scn отходит от протоколов выборки git: согласование не сообщает серверу, что у клиента уже есть, а работает только с деревьями и blob, которые клиенту нужны. Клиент рекурсивно запрашивает недостающие деревья от корневого, затем blob. Каждый запрос, к конкретному неизменному объекту, поэтому ответить может любой кэш, архитектура напоминает многоуровневые кэши, процесс возобновляем и не требует одного многогигабайтного packfile. По утверждению Anthropic, такая схема требует заметно меньше CPU, чем серверы git. На узлах клиент общается через сокет с демоном scion-daemon, который хранит объекты для всего узла. Доступная часть текста обрывается на описании запуска демона из периодически обновляемого снимка.

Отдельно авторы признают, что нагрузка Anthropic необычна: компания пишет софт с Claude намного больше почти любой другой, поэтому первой видит, где инструменты человеческого масштаба начинают не справляться. Многие организации, по их оценке, не столкнутся с такими проблемами в ближайшее время, но они подозревают, что ждать остальным, кто использует ИИ для написания кода, придётся недолго. Сам Scion, как отмечает Anthropic, построен с помощью Claude: способность Claude писать код и создала эту ситуацию, и позволила быстро построить качественную масштабируемую систему.

Ключевые факты

В мае 2026 года Anthropic в среднем сливала около 2 500 изменений кода в день, по состоянию на сентябрь, более 30 000 в день; замедления роста компания не ждёт.
Монорепозиторий перестал укладываться в модель git: история основной ветки почти 100 ГБ, сжатая рабочая копия больше 25 ГБ, порядка 25 миллионов выгрузок кода в сутки для CI; на пике держали несколько сотен внутренних git-зеркал.
Scion построен вокруг постоянно подключённых клиентов-агентов: коммиты, слияния и перебазирования выполняются на сервере, рабочая копия необязательна и разрежена, все запросы к контролю версий доступны через API.
Единица работы, changeset в журнале упреждающей записи; всё остальное (blame, история путей, граф коммитов), производные данные, вычисляемые общим механизмом; серверы по сути большие кэши данных, адресуемых по содержимому.
Полный перенос с git занял пять месяцев; за тот же срок сделаны также интерфейс код-ревью Antique, поиск по коду и система IAM для контроля версий.

Почему это важно

Anthropic прямо заявляет, что при массовом ИИ-программировании узким местом становится не сам код, а инфраструктура разработки, рассчитанная на человеческий масштаб: контроль версий, сборки и CI. Рост с около 2 500 до более 30 000 слитых изменений в день по состоянию на сентябрь показывает масштаб, на котором git-инфраструктура перестала справляться даже с сотнями зеркал. Компания подозревает, что другие организации, которые используют ИИ для написания кода, столкнутся с теми же проблемами, хотя в ближайшее время такого у многих не ждёт.

Кому это важно

Инженерам и руководителям, отвечающим за инфраструктуру разработки, CI и контроль версий, особенно в организациях с очень крупными монорепозиториями и большим числом автоматических клиентов (агентов, CI-заданий). Также тем, кто следит за тем, как массовое ИИ-программирование меняет требования к инструментам: авторы ссылаются на опыт Piper от Google и Sapling от Meta как на предшественников в области контроля версий для огромных монорепозиториев.

Как это применить

В доступной части текста не сказано, что Scion или Antique открыты или доступны внешним пользователям, поэтому взять их как готовый продукт нельзя. Применимы идеи, которые авторы сами называют переносимыми на другие системы контроля версий и этапы разработки: проектировать клиентов в расчёте на постоянное подключение к серверу, выносить вопросы об истории и blame в API, чтобы CI-заданиям не требовался локальный репозиторий, использовать разреженные и виртуализированные выгрузки, хранить данные, адресуемые по содержимому и неизменные, так, чтобы любой кэш мог ими отвечать.

Можно ли доверять

Источник, собственный инженерный пост Anthropic, поэтому все цифры (2 500 и 30 000 слияний в день, 100 ГБ истории, 25 миллионов выгрузок в сутки, пять месяцев на миграцию), самоотчёт компании, независимой проверки нет. В доступной части текста нет замеров производительности и задержек самого Scion: утверждение, что клиент scn требует заметно меньше CPU, чем серверы git, приведено без цифр. Текст в доступном виде обрывается на описании scion-daemon, а ни автор, ни дата публикации в нём не указаны.

Риски и подводные камни

Anthropic сама оговаривает, что её нагрузка необычна: выводы нельзя автоматически переносить на обычные репозитории, для большинства которых децентрализованный дизайн git остаётся правильным. Модель Scion зависит от всегда доступного сервера и отдаёт на сервер вычисления, которые в git делает клиент; клиент сам почти ничего не может вычислить. Прямо упомянутый в тексте минус git-обходов: зеркала и «семена» становились всё труднее в эксплуатации по мере роста потока слияний. Полный перенос монорепозитория за пять месяцев шёл параллельно с созданием code review, поиска и IAM, то есть на собственной самодельной инфраструктуре.

«Узким местом сейчас стала вся инфраструктура разработки, рассчитанная на человеческий масштаб: контроль версий, сборки и CI.»

— Anthropic, инженерный блог

Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.