В мае 2026 года в Anthropic вливали в основную ветку около 2 500 изменений в день. В сентябре — больше 30 000. Код в Anthropic пишут с Claude больше, чем почти в любой другой компании, и самым узким местом разработки оказался git. Сегодня команда source control опубликовала разбор того, как они заменили git своей системой Scion. По сути это альтернатива git, спроектированная под ИИ-агентов, а не под людей.
Ниже коротко: почему git перестал справляться, как устроена новая система, от чего пришлось отказаться и что из этого применимо в обычном проекте, где агентов два-три, а не тысячи. Я пишу с позиции человека, у которого несколько репозиториев и в каждом работают кодинг-агенты. Scion мне не нужен. Часть идей нужна уже сейчас.
Почему понадобилась альтернатива git#
Масштаб из статьи. История основной ветки — почти 100 ГБ, сжатая рабочая копия — больше 25 ГБ. Только CI делает порядка 25 миллионов чекаутов в день. Если бы каждый тянул данные наивно, получилось бы больше 600 ПБ git-трафика в сутки.
Стандартные приёмы они перепробовали: shallow- и sparse-клоны, partial clone, заранее подготовленные копии в blob-хранилище. На пике у них работали несколько сотен внутренних git-зеркал. С ростом числа слияний зеркала было всё труднее держать, а заготовленные копии всё сильнее отставали от свежего main.
Главное наблюдение у них такое: git создан для распределённой работы офлайн, у каждого полная копия истории. А их клиенты — агенты и CI-задачи, которые всегда онлайн. Git фактически использовали как централизованную систему, и его распределённость только мешала.
Как устроена система контроля версий Scion#
Scion исходит из того, что клиент всегда в сети. Отсюда остальные решения.
- Тяжёлая работа на сервере. История, blame, коммиты, слияния и ребейзы считаются на сервере. Клиент держит ограниченный кэш объектов, раскладывает файлы и следит за файловой системой.
- Changeset вместо коммита. Единица работы — запись в журнале упреждающей записи (write-ahead log). Changeset не ссылается на дерево целиком, а перечисляет изменённые файлы относительно первого родителя. Создаётся сразу на сервере, пушить нечего.
- Ветки — одна атомарная операция. Сдвиг ref — compare-and-swap одной строки в Spanner, отдельно от создания changeset. Веток кроме
mainи релизных они избегают: глобальное состояние плохо масштабируется. - Клиент просит только недостающее. В git клиент рассказывает серверу, что у него уже есть. В Scion клиент идёт от корневого дерева и просит только недостающие деревья и блобы. Объекты неизменяемые, поэтому их отдаёт любой кэш.
- Три уровня раздачи.
scion-daemonна каждой машине, региональныйscion-cacheв памяти иscion-serverповерх Spanner и облачного хранилища. Протокол у всех одинаковый, но уровни изолированы: падение регионального кэша не обрушит лавину запросов на серверы. - Рабочая копия по желанию. Многим CI-задачам чекаут вообще не нужен, им хватает API. Если копия нужна, она частичная или виртуальная: файл появляется на диске, только когда его читают.
Идеи не новые, и авторы этого не скрывают. Для гигантских монорепозиториев уже были Piper у Google и Sapling у Meta. Новое здесь в нагрузке: клиенты — агенты, и их на порядки больше, чем людей.
Что получилось в цифрах#
| Метрика | Значение |
|---|---|
| Слияний в день | ~2 500 в мае → 30 000+ в сентябре |
| Инфраструктура против git-зеркал | в 200 раз меньше |
| Чекаут в CI | секунды вместо минут |
| CPU в CI | освободилось 25% |
| Попадания в кэш на каждом уровне | больше 99% |
| Команда и срок | 7 человек, 5 месяцев |
Семь человек за пять месяцев построили Scion, инструмент код-ревью Antique, поиск по коду, систему прав и ещё несколько связанных сервисов. Миграция прошла, пока объём слияний вырос в десять раз. Писали с Claude: прототип конвейера импорта из git команда сделала руками, а ранняя версия Claude Mythos Preview переписала его, и он стал тратить в 20 раз меньше памяти и работать в 4 раза быстрее.
От чего пришлось отказаться#
Эта часть статьи показалась мне самой полезной.
Это не замена git#
Авторы прямо пишут, что Scion не подходит как git для общего использования. Чтобы перейти на него, пришлось заменить код-ревью, поиск и CI. Отдавать Scion наружу они не собираются: внутренние инструменты слишком под себя.
История только по основной линии#
Changeset хранит изменения относительно первого родителя. Blame и история путей оптимизированы под main. Это работает только при trunk-based разработке.
Нет глобальной блокировки очереди слияний#
Повторить привычную для индустрии глобальную блокировку при таком темпе они не смогли. Вместо неё — тесты после слияния и перед деплоем. Параллельные изменения иногда конфликтуют, и Claude обычно чинит конфликт быстрее, чем человек успел бы его заметить. Для меня это главный сигнал: merge queue придумали под темп людей, и при агентах её проще заменить другой схемой, чем масштабировать.
Роль инженера: говорить Claude «нет»#
По словам авторов, архитектуру и компромиссы по-прежнему задают люди. Чаще всего их работа сводилась к тому, чтобы сказать агенту «нет». Примеры из статьи: агент перебирает историю коммитов вместо того, чтобы спросить инструмент ревью; агент после ревью «на прочность» обкладывает код лишними проверками.
Ревьюеры смотрят на намерение изменения, а не на каждую строку. За продом следят отдельные экземпляры Claude, по одному на компонент, их называют «суперфанатами». Они читают телеметрию и логи и замечают то, что статические алерты пропускают.
Что взять себе: монорепозиторий git и агенты без Scion#
У меня масштаб другой: несколько сайтов и приложений, в каждом по одному-два агента. Но три идеи из Scion работают и на обычном git.
1. Не клонируйте лишнего. Partial clone и sparse checkout есть в git давно, и агенту редко нужна вся история:
git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/ios packages/sharedДля больших репозиториев есть scalar clone, он входит в git с версии 2.38 и сразу включает эти настройки и фоновое обслуживание.
2. Каждому агенту — своё рабочее дерево. Сегодня агент выкатывал правку на сайт meteohealth.pro, где моя рабочая ветка была с незапушенным коммитом. Он не трогал её, а сделал отдельный worktree от origin/main:
git worktree add -b fix-key ../site-main origin/main
git -C ../site-main push origin fix-key:main
git worktree remove ../site-mainЭто локальный аналог того, что в Scion рабочая копия дешёвая и необязательная.
3. Проверки — машинные и до слияния. Глобальной блокировки у меня нет, её роль играет pre-push хук. На meteohealth.pro он гоняет типы, проверку переводов и раскладку шапки на 108 комбинациях языков и ширин. Агент не может обойти его вежливой просьбой. Человеку остаётся смотреть на намерение изменения, как и у Anthropic.
Что я бы не переносил: отказ от веток и историю только по первому родителю. Это осмысленная цена при 30 000 слияний в день. При тридцати слияниях в неделю она ничего не даёт.
Чего в статье нет#
- Исходников и даже описания API клиента
scn. Повторить систему по статье нельзя, и авторы на это не рассчитывают. - Сравнения с другими подходами на одной нагрузке: цифры «в 200 раз» и «секунды вместо минут» измерены относительно их собственной схемы с git-зеркалами. С Piper или Sapling никто не сравнивал.
- Ответа, когда такое понадобится остальным. Авторы предполагают, что проблемы этого класса станут массовыми в ближайшие 6–12 месяцев, и хотят предложить идеи GitHub, GitLab и open source сообществу. Какие именно серверные RPC и режимы sparse/shallow они предложат, пока не известно.
Если у вас монорепозиторий git, а агентов становится больше, чем людей, проверьте три вещи из списка выше до того, как упрётесь в зеркала. Как дать агентам общую память о проекте, я разбирал в статье про вики для кодинг-агентов по MCP. Как несколько агентов делят работу без конфликтов — в статье про заявки агентов в общей вики.
