Scion: когда агенты упираются в инфраструктуру разработки (Рубрика #AI4SDLC)

В свежей статье Anthropic про Scion есть занятный самоподдерживающийся цикл: агенты производят столько изменений, что инфраструктура разработки перестаёт справляться. А затем помогают построить новую инфраструктуру, чтобы производить ещё больше изменений :)

По данным команды, с мая по сентябрь 2026 года число вливаемых изменений выросло примерно с 2500 до более 30 000 в день. Семь инженеров за пять месяцев построили Scion, инструмент ревью Antique и несколько связанных систем, полностью мигрировав монорепозиторий с Git. В аннотациях я отдельно отметил скорость миграции: написать систему и перевести на неё работающую компанию — весьма разные задачи.

🔸 Кто теперь клиент системы контроля версий?
Преимущественно постоянно подключённые агенты и задания CI. Поэтому в Scion историю, blame, merge и rebase обрабатывает сервер. Клиент держит ограниченный кеш, получает нужные файлы, а многие операции вообще выполняются через API без рабочей копии.

Дальше мои пометки всё чаще сводились к «напоминает базы данных». Changeset — запись в WAL со списком изменённых файлов и ссылками на содержимое. Деревья, история путей и blame строятся как производные данные. Похоже на CQRS: запись изменений и структуры для чтения оптимизируются отдельно. Можно добавлять новые индексы, считать их заранее или по запросу и менять внутренности без обновления клиентов.

Неизменяемые объекты раздаются через кеши на нодах и в регионах. Стоимость коммита должна зависеть от размера изменения. Знакомые принципы масштабирования под новую нагрузку. И хорошо, что авторы признают предшественников: Google Piper и Meta Sapling.

🔸 Инженер, который умеет сказать агенту «нет»
Команда по-прежнему ревьюит каждое изменение, но смотрит прежде всего на его намерение. Люди удерживают архитектурные ограничения и останавливают лишнюю сложность: например, агентный ревьюер может придумать гипотетическую угрозу, а другой агент — старательно обложить сервис ненужными проверками. Вот где проявляется инженерное суждение. Хотя правильное намерение ещё нужно подтвердить проверками реализации.

Ещё одна моя пометка — «электронный SRE». У каждого компонента есть агент-«суперфанат»: смотрит телеметрию и логи, ищет странности. По утверждению команды, такие агенты замечают проблемы, которые пропускают обычные алерты. Сами алерты при этом остаются.

🔸 Переосмысление доходит до CI
Пока идут тесты, в main могут попасть сотни других изменений. Anthropic делает ставку на post-merge и pre-deploy проверки, допуская конфликты между параллельными изменениями и рассчитывая на быстрое исправление агентами. В аннотациях я отметил именно redesign процесса. Здесь хочется больше деталей: что разрешено выпускать, как долго main бывает сломан и как это мешает остальным агентам? Статья такого контракта не раскрывает.

И красивые цифры стоит читать внимательно. В тексте заявлены два порядка ускорения checkout, а на итоговом графике у compute jobs — 8×, у CI — 8,8×, у создания нового worktree агентом — 84×. Возможно, условия разные, но расхождение не объяснено. Число merge тоже само по себе не измеряет полезность кода. Перед нами инженерный отчёт компании о собственном решении.

Авторы честно оговаривают необычный масштаб и доступный им бюджет токенов. Копировать Scion целиком большинству команд вряд ли нужно. А вот проверить, какие операции в нашем SDLC существуют по привычке и действительно ли они нужны агентам, — уже вполне прикладная идея.

P.S.
Сегодня ближе к вечеру проведу прямой эфир Research Insights Made Simple, где расскажу про эту систему подробнее

#AI4SDLC #Architecture #DistributedSystems #DevTools #Engineering