Anthropic перешла на собственную систему контроля версий Scion из-за роста нагрузки от ИИ

В Anthropic столкнулись с фундаментальным ограничением традиционных инструментов разработки: по мере того как Claude начал автономно генерировать и оптимизировать код, узким местом стала не сама написание программ, а инфраструктура для их хранения и сборки. Если в мае 2026 года компания объединяла около 2500 изменений кода в день, то к сентябрю этот показатель превысил 30 000. Существующие решения, такие как git, оказались неэффективными: история основной ветки занимала почти 100 ГБ, а ежедневные проверки для CI-систем требовали бы передачи более 600 петабайт данных при наивном подходе. Для решения этой проблемы команда разработала Scion — собственную систему контроля версий, на которую был полностью перенесен монорепозиторий за пять месяцев.

Ключевым отличием Scion от git является отказ от децентрализованной модели, где каждый клиент хранит полную копию репозитория. Поскольку почти все клиенты в Anthropic — это онлайн-агенты и фоновые задачи, система спроектирована вокруг централизованного сервера, который всегда доступен. Клиентские устройства поддерживают лишь ограниченный локальный кэш и запрашивают данные по мере необходимости. Это позволило сделать коммиты дешевыми и инкрементальными: операции выполняются на сервере без блокировок, а стоимость обновления данных зависит от размера конкретного изменения, а не от общего объема репозитория.

Архитектура Scion построена на принципе горизонтального масштабирования. Данные распределяются между узлами, и нигде не существует полностью материализованной копии репозитория. Вместо packfiles используются контент-адресуемые объекты в blob-хранилище, что исключает необходимость в сложном обслуживании репозитория. Для ответа на запросы о истории файлов и авторстве изменений система использует механизм «производных данных», которые вычисляются рекурсивно от родительских коммитов. Это позволяет добавлять новые индексы для поиска или детекции копий без изменения клиентской части.

Сетевая архитектура также оптимизирована под высокую пропускную способность. Клиент не сообщает серверу, какие объекты у него уже есть, а запрашивает только нужные деревья и блоки данных. Это напоминает работу многоуровневых кэшей: локальный демон на узле общается с региональными кэш-серверами, которые при отсутствии данных обращаются к авторитативным серверам. Каждый уровень поддерживает коэффициент попадания в кэш выше 99%, что обеспечивает высокую скорость и отказоустойчивость.

Результаты миграции оказались впечатляющими. Инфраструктурный след Scion стал в 200 раз меньше по потреблению CPU и памяти по сравнению с предыдущей системой зеркал git. Проверка кода в CI-системах ускорилась на два порядка, сократившись с минут до секунд, что дало выигрыш в 25% вычислительных мощностей только для непрерывной интеграции. Кроме того, исчезла необходимость в длительном обслуживании репозиториев на стороне клиентов.

Разработка Scion стала примером нового подхода к созданию ПО. Команда из семи инженеров построила систему и сопутствующие инструменты за пять месяцев, одновременно десятикратно увеличив объем слияний кода. Инженеры отмечают, что их роль сместилась от написания кода к управлению архитектурными решениями и ограничению возможностей ИИ-агентов, которые иногда пытаются нарушать системные ограничения ради формального соответствия паттернам. Этот опыт показывает, что в эпоху агентного программирования ценность инженера заключается в способности задавать правильные границы и принимать стратегические решения.