Anthropic «убила» Git: 30 000 коммитов в день — это не хрен собачий.
Я в IT-разработке и управлении инфраструктурой с начала двухтысячных. Помню болезненный переход с Subversion и CVS на Git, помню войны за монорепозитории в крупных конторах и сотни часов, сожжённых на оптимизацию CI/CD. Так что когда компания публично объявляет, что за пять месяцев полностью выбросила Git и написала собственную систему контроля версий, у меня включается не восторг, а привычка читать между строк.
На днях Anthropic опубликовала откровенную статью о том, как они это сделали. Систему назвали Scion. Причина — их нейросети пишут код с такой скоростью, что классический Git захлебнулся, физически перекачивая туда-сюда петабайты данных. От 2 500 до 30 000 мерджей в день, команда из 7 человек, написавшая новую VCS, инструмент для ревью и поиск за 5 месяцев с помощью Claude.
Народ сейчас потащит это в свои проекты размера «я и мои хомяки». На ближайшие месяцы Scion станет флагманом индустрии, его будут цитировать на каждом втором митапе, и под лозунг «так делает Anthropic» в сотни репозиториев поедет неконтролируемый техдолг под видом революции. Поэтому давайте посмотрим на этот кейс глазами человека, который видел десятки «революционных» систем, сгоревших под весом собственного техдолга. Возникает пара очень неудобных вопросов.
Честно говоря, вы переизобрели Perforce и Google Piper
Anthropic гордо заявляет: «Мы поняли, что агенты всегда онлайн, поэтому сделаем сервер главным, откажемся от полной истории на клиенте и будем запрашивать файлы по запросу».
Ребята буквально пересказали концепцию Perforce из 1990-х или Google Piper из 2000-х.
Главное достижение Git — децентрализация и автономия разработчика. Anthropic заявляет, что автономия больше не нужна, потому что «агенты всегда онлайн». Превращение VCS в централизованный клиент-серверный сервис с тяжёлым бэкендом на Spanner и облачными кэшами — это не шаг в будущее. Это откат на 20 лет назад, засыпанный бесконечным бюджетом на AWS и Google Cloud.
30 000 коммитов в день — это успех или нейрослоп?
График роста с 2,5k до 30k мерджей в день подаётся как главный предмет гордости. Но давайте зададим главный менеджерский вопрос: а нужно ли монорепозиторию тридцать тысяч мерджей в день?
Когда кодит человек, каждый коммит — осознанная единица смысла. Когда Claude автономно итерируется и микрооптимизирует сервисы, она генерирует гигабайты кодового шума. Там, где опытный инженер сделает один изящный коммит, ИИ нагенерит 500 мелких итераций, проверяя гипотезы прямо в основной ветке.
Мы точно уверены, что создаём ценность, а не греем серверы Anthropic генерацией и рефакторингом нейрослопа? Не факт.
Я эту разницу хорошо чувствую, потому что сам таскаю git-историю как датасет — детерминированные метрики вроде churn и co-change, а поверх них уже интерпретацию. Первое правило там: каждое утверждение опирается на SHA или число, а не на красивый график роста. Голый счётчик коммитов не говорит ни о ценности, ни о здоровье кодовой базы. Он говорит ровно об одном — сколько раз что-то упало в main. График, которым гордятся, одинаково хорошо описывает и инженерный прорыв, и аккуратно автоматизированный нейрослоп.
VCS за 5 месяцев силами 7 человек: мина замедленного действия
Написать ядро VCS, систему ревью и кэширующий слой за 5 месяцев силами 7 человек — звучит как мечта любого CTO. Давайте почитаем между строк.
Код писала сама нейросеть. В статье прямым текстом сказано: разработчикам приходилось работать в режиме «сказать модели "нет"», потому что Claude постоянно пытался срезать углы, нарушал базовые архитектурные ограничения или оверинженирил защиту от гипотетических угроз. Внезапно! Всё как говорили луддиты.
В сухом остатке:
- Систему написала нейросеть, и есть сомнения, что ребята правильно удержали её в канве в сложных пограничных случаях.
- Инженеры, по их собственному признанию, больше не читают строчки кода, а проверяют только намерения — intent of the change.
Что произойдёт, когда пара ключевых архитекторов уволится, а Scion столкнётся со сложным распределённым дедлоком в Spanner? Справится ли сам Claude с исправлением, если никто в команде больше не держит в голове, как эта штука устроена на уровне строк?
Это та самая развилка, о которой я говорю везде: агент — множитель инженерной организации. Но без владельца, который проектирует систему и держит её целостность в голове, агенты из множителя превращаются в статью расходов. Семь человек, которые проверяют намерения вместо кода, — это ещё владельцы системы или уже операторы чёрного ящика, который для них написал подрядчик по имени Mythos?
Отказ от Merge Queue: «ИИ сам поправит конфликты на проде»
Самый неожиданный фрагмент статьи — подход к конфликтам при мердже. В Anthropic честно признали: классическая очередь мерджей с глобальными блокировками при 30 000 коммитов просто умирает.
Какое решение они нашли? Отказались от блокировок.
Изменения вливаются параллельно. Если возникает логический конфликт, они надеются на авто-тестирование после мерджа и на то, что Claude обычно чинит такие конфликты быстрее, чем их заметит человек. Мы сознательно допускаем попадание некорректного или конфликтующего кода в main, рассчитывая, что другой бот вовремя наложит жгут. В сложных распределённых системах с неявными связями это прямой путь к плавающим, невоспроизводимым багам и осознанный риск, что какое-то время продукт находится в неопределённом состоянии.
Я двадцать лет живу в парадигме явных переходов состояний: статус лежит во внешнем манифесте, в очереди, в гейте — там, где его видно и можно проверить, а не в надежде, что следующий прогон как-нибудь разрулит. «Залили сломанное, бот потом починит» — противоположная философия. Это ставка на то, что система в среднем сойдётся, а то, что в отдельные моменты main невалиден, — приемлемая цена. Для компании с бесконечными токенами — может быть. Для всех остальных это называется «у нас прод в неопределённом состоянии, и мы молимся».
Slack-боты вместо нормальной инженерии
Не могу обойти стороной милый пассаж про то, как они настроили в Slack ИИ-ботов-«суперфанатов», заставив их «с энтузиазмом преданного фаната» постоянно обновлять графики telemetry и искать аномалии в работе Scion.
Когда вместо детерминированных алертов, нормальных SLO/SLA и грамотного мониторинга вы садите нейросеть вглядываться в графики в поиске странностей — это подмена системной инженерии. Хотя мы все понимаем, что наше будущее будет выглядеть именно так.
Не путайте спасение от собственного ИИ-хаоса с эволюцией индустрии
Scion — инженерный эксперимент. Anthropic оказалась на переднем крае проблемы, с которой 99% компаний не столкнутся ещё лет десять. Они решали свою узкую задачу: как подпереть костылями инфраструктуру, когда у тебя есть бесконечные бесплатные токены и гигантский монорепозиторий.
Все пять неудобных вопросов сходятся в одну точку: это не прыжок вперёд, а централизованный откат на двадцать лет, обвешанный моделями и оплаченный бюджетом, который есть у одной компании в мире.
Скорость поставки действительно можно поднять в разы — я это делал руками, не на слайдах. В одном SaaS релизы ехали раз в несколько месяцев, стало раз в несколько недель; поток в 5–10 новых багов в день загнали под контроль, выручка выросла на 50%. Двигала это не количество коммитов. Двигала дисциплина: QA, CI/CD, нормальный bug-tracking, инженерная культура и люди, которые отвечают за результат. Ни одна из этих вещей не измеряется графиком «2,5k → 30k мерджей в день».
Готовы выкинуть Git в следующем квартале — потому что «так делает Anthropic»? Сколько из 30 000 коммитов в день, которые вы так гордитесь, создают ценность, а сколько просто греют облачные сервера?