Когда разработка перестает быть узким местом
В индустрии высоких технологий долгое время считалось, что написание кода является главным ограничителем скорости создания сложных систем и проведения исследований. Однако стремительное развитие генеративных моделей радикально изменило эту парадигму. Инженеры компании Anthropic столкнулись с новой реальностью, где нейросетевые агенты способны автономно итерировать исследовательские циклы, проводить микрооптимизацию сложных программ и выстраивать новые сервисы с нуля со скоростью, недоступной человеческим командам. Главным препятствием на пути этого прогресса оказалась не сама разработка, а инфраструктура, исторически спроектированная под человеческие масштабы работы. Системы контроля версий, процессы сборки и непрерывной интеграции начали давать сбои под колоссальной нагрузкой.
Масштаб происходящего лучше всего иллюстрируют цифры. Если в мае 2026 года среднее количество сливаемых изменений кода составляло около двух с половиной тысяч в день, то к сентябрю этот показатель превысил тридцать тысяч ежедневных слияний. Скрытый спрос на интеграцию кода оказался практически бесконечным: каждое устраненное узкое место немедленно провоцировало новый всплеск объема производимого программного обеспечения. Чтобы поддержать такой экспоненциальный рост, команде из семи инженеров потребовалось полностью отказаться от привычных инструментов и за пять месяцев создать собственную систему контроля версий под названием Scion, осуществив полную миграцию своего монорепозитория.
Архитектурный кризис децентрализованного подхода
Популярная система контроля версий Git была создана как децентрализованный инструмент, где каждый клон представляет собой полноценный, самодостаточный репозиторий. Он способен вычислять разницу между версиями, читать историю изменений и переключаться между ревизиями полностью в автономном режиме. Для подавляющего большинства проектов это идеальное архитектурное решение, которое и сделало данный стандарт доминирующим в отрасли. Но по мере роста монорепозитория Anthropic его характеристики перестали вписываться в заложенную модель. Только история главной ветки стала занимать почти сто гигабайт, а сжатая рабочая копия превысила двадцать пять гигабайт.
Ежедневно для нужд непрерывной интеграции выполняется порядка двадцати пяти миллионов операций проверки кода, не считая сред разработчиков, изолированных песочниц для агентов и исследовательских задач. При наивном подходе к скачиванию данных это привело бы к генерации более шестисот петабайт сетевого трафика в сутки. Стандартные механизмы оптимизации, такие как поверхностное клонирование, разреженные копии и внутренние зеркала, давали лишь временную передышку. На пике нагрузки компания поддерживала несколько сотен внутренних зеркал, но управление ими становилось все сложнее. Сеансы обновления рассинхронизировались с актуальным состоянием главной ветки, а операции, зависящие от полной истории, требовали все больше ручного вмешательства. Стало очевидно, что использование децентрализованной системы в качестве централизованной базы данных для постоянно находящихся в сети агентов фундаментально противоречит здравому смыслу.
Принципы построения Scion для эпохи ИИ-агентов
При проектировании Scion инженеры заложили принципы, кардинально отличающиеся от классической парадигмы. Главный постулат заключается в том, что клиенты всегда находятся в сети. Поскольку почти всеми потребителями системы являются автоматизированные агенты и вычислительные задачи, клиентская часть и сетевые протоколы были спроектированы вокруг постоянно доступного сервера, откуда данные запрашиваются по мере необходимости. Это породило выраженную клиент-серверную асимметрию. Сервер берет на себя всю тяжелую работу: отвечает на запросы об истории файлов, формирует коммиты, выполняет слияния и перебазирования. Клиент же поддерживает лишь ограниченный локальный кэш объектов, управляет файлами на диске и предоставляет эргономичный интерфейс, не выполняя сложных вычислений самостоятельно.
Такой подход превратил систему контроля версий в комплексный сервис, питающий множество новых приложений. Любая задача непрерывной интеграции может получить информацию о коммите через программный интерфейс, вообще не скачивая локальную копию репозитория. Все компоненты Scion изначально проектировались с прицелом на горизонтальное масштабирование. Данные репозитория распределены, а единой материализованной копии не существует даже на сервере. Создание коммитов стало дешевым, инкрементальным процессом без блокировок, поскольку каждая операция происходит на стороне сервера, а ее стоимость зависит исключительно от размера конкретного изменения, а не от общего объема хранилища. Рабочая копия стала опциональной и разреженной по умолчанию, что позволяет агентам получать только те директории, которые действительно требуются для выполнения задачи.
Структуры данных и многоуровневое кэширование
Базовой единицей работы в Scion является набор изменений, представляющий собой запись в журнале упреждающей записи. В отличие от традиционных коммитов, хранящих указатель на дерево объектов, набор изменений содержит список модифицированных файлов относительно первого родителя вместе с контентно-адресуемыми указателями на сжатое содержимое в облачном хранилище. Эти структуры создаются на сервере и мгновенно становятся доступны во всей системе. Отсутствие пакетных файлов, блокировок и межсерверной координации обеспечивает экстремально высокую пропускную способность приема данных. Для поддержки таких функций, как поиск авторов строк или истории путей, поверх базовых наборов изменений вычисляются производные данные. Этот механизм работает рекурсивно, позволяя легко добавлять новые типы индексов и выбирать стратегию их вычисления - жадную или отложенную.
Флот серверов Scion предоставляет программные интерфейсы для любых операций, при этом все данные контентно-адресуемы, что означает их неизменность после записи. Любой сервер может кэшировать информацию без согласования с остальными узлами. Клиентский компонент общается через сокет с локальным демоном, который обслуживает весь вычислительный узел. Задачи на одном узле используют общие объекты, поэтому демон обращается к региональным серверам кэширования, транслирующим данные прямо из оперативной памяти в нужном формате. Если объект отсутствует в кэше, запрос уходит к авторитетным серверам, читающим информацию из распределенной базы данных Spanner или облачного хранилища. Каждый уровень этой архитектуры поддерживает коэффициент попадания в кэш выше девяноста девяти процентов. В результате инфраструктурный след Scion оказался в двести раз меньше по требованиям к вычислительным ресурсам, чем предыдущая сеть зеркал, а задачи непрерывной интеграции стали выполняться на два порядка быстрее.
Роль нейросетей и трансформация инженерного труда
Создание Scion совпало с внутренним развертыванием новейших версий языковых моделей Anthropic, что одновременно усилило потребность в новой системе и ускорило ее разработку. Показательным стал случай, когда ранний прототип конвейера импорта данных, написанный вручную, был полностью переписан нейросетью без дополнительных инструкций. Результат потреблял в двадцать раз меньше оперативной памяти и работал в четыре раза быстрее, сохранив при этом все неявные инварианты структур данных. Команда из семи человек смогла не только создать новую систему контроля версий и платформу код-ревью под названием Antique, но и полностью мигрировать на них за пять месяцев, параллельно справляясь с десятикратным ростом объема сливаемого кода.
Этот опыт продемонстрировал, что ценность инженеров не уменьшилась, но характер их работы радикально изменился. Разработчики признают, что нейросеть пишет код лучше них, однако именно люди обеспечивают критически важное понимание межсистемных взаимодействий и архитектурных компромиссов. Часто главная задача инженера заключалась в том, чтобы запретить алгоритму применять сомнительные паттерны. Агенты склонны нарушать системные ограничения ради достижения локальных целей, например, пытаясь brute-force методами читать лог коммитов вместо использования специализированных интерфейсов. Кроме того, инженеры использовали практику состязательного ревью, направляя модель и защищая систему от избыточного усложнения. Теперь специалисты проверяют не каждую строку кода, а общую интенцию предлагаемых изменений. Подобный подход к разработке инфраструктуры для агентных вычислений неизбежно станет стандартом для технологического сектора в ближайшие месяцы, заставляя всю отрасль переосмысливать инструменты, созданные для людей.