GitHub переписал план мощностей в 30 раз — AI-агенты пишут код быстрее CI
CTO GitHub Влад Фёдоров: октябрьский план мощностей в 10 раз к 2026 году устарел уже к февралю, нужен в 30 раз из-за роста AI-агентного кода. Bottleneck сместился — не в инфраструктуру CI, а в валидацию: review-очереди, staging, integration-тесты. Разбираем, что меняется в SDLC.
Новости Tproger
CTO GitHub Влад Фёдоров опубликовал апдейт о двух апрельских инцидентах с пометкой, которую стоит прочитать каждому, кто строит CI/CD: октябрьский план нарастить мощности GitHub в 10 раз к 2026 году пришлось переделывать в 30-кратный — и не потому, что прошлый был плох, а потому, что AI-агенты пишут код быстрее, чем валидация успевает его проверять.
Это не рутинное объявление об увеличении кластера. Если самый закалённый разработческой инфраструктуры игрок планеты говорит «в 10 раз — уже мало», значит фундаментальные предположения о том, как производится софт, сместились быстрее, чем GitHub успел заложить в собственные планы. Все, кто строит ниже по течению — на тех же предположениях, — попадают под тот же сдвиг.
Главное
Ключевые выводы
Сигнал. CTO GitHub Влад Фёдоров: октябрьский план мощностей в 10 раз к 2026 году устарел уже к февралю — нужен план в 30 раз из-за роста AI-агентного кода.
Bottleneck не в железе. CI справится с любым потоком; не справляется валидация — очередь ревью, стенды staging, интеграционные тесты.
Стоимость поиска бага растёт по стадиям. Внутри цикла разработки — почти ноль; в CI — полный цикл сборки; в staging — деплой и очередь к стенду; в production — инцидент, откат и отдельный revert-PR.
Структурный ответ. Сдвиг валидации в inner-loop, где агент сам прогоняет изменение против реальной системы до создания PR.
Что делать командам. Отделить «compile-clean» от «correct», встроить эфемерные окружения в inner-loop агента, не наращивать слепо мощности CI.
Почему GitHub переписал план мощностей
В апреле 2026 года у GitHub было два крупных инцидента — внутренний апдейт об их разборе содержал ключевой абзац:
Мы начали в октябре 2025 года план по 10-кратному наращиванию мощностей GitHub с целью существенно улучшить надёжность и failover. К февралю 2026 стало ясно, что нужно проектировать под будущее, требующее 30-кратного объёма от текущего.
Перевести с менеджерского на инженерный это можно так: производство кода ускорилось не на проценты, а в разы, и инфляция объёма не закладывалась в годовое планирование самых опытных платформенных команд. Точка перегиба совпадает с переходом агентов для кодинга из ранних прототипов в дефолтный инструмент инженерных команд.
Объём становится проблемой, когда не конвертируется в throughput
30-кратный рост производства кода в идеальном мире давал бы 30-кратный рост поставленных фич. На практике SDLC никогда не превращал объём кода в релизную функциональность 1:1. Конверсия теряется на одном и том же этапе — валидация.
До прихода агентов это уже было больно: тест-сьюты по часу, постоянно перегруженные стенды staging, интеграционные баги, всплывающие на release candidate, очереди review, в которых сидят единственные люди, способные определить, безопасно ли изменение. Валидация — самая медленная, самая зависящая от человека и самая ошибкоёмкая часть цикла, и она встроена между «код написан» и «код задеплоен».
В cloud-native архитектурах эта проблема обостряется. Современное приложение — это граф сервисов, каждый со своим состоянием, зависимостями, темпом релизов. Изменение одного сервиса прокатывается по половине соседних, а ломается обычно то, что не видно в исходниках: contract drift (несовпадение договорённостей между сервисами), race conditions, edge-кейсы мульти-тенантности, поведение под нагрузкой.
Где ловить баг — там и платить
Стоимость найденного бага компаундится в зависимости от стадии:
- Inner loop (агент или разработчик ещё итерирует) — почти ноль.
- CI — полный цикл сборки.
- Staging — деплой + слот в очереди + время валидаторов.
- Production — инцидент, rollback, revert PR, который сам идёт через тот же pipeline.
При человеческой скорости разработки SDLC поглощал часть этой неэффективности — объём ограничивался числом инженеров. На скорости и масштабе агентов поглощать перестаёт: задержка превращается в постоянно растущий backlog. Поэтому ответ — не «больше мощностей CI, больше стендов staging, больше ревьюеров». Это тактический отклик на структурный сдвиг.
Замкнуть петлю — там, где код пишется
Структурный ответ — сдвинуть валидацию максимально влево, прямо в inner loop, где агент порождает код. Сегодня агенты для кодинга — это половина рабочей системы: они пишут код на беспрецедентной скорости, но не могут самостоятельно проверить, правильно ли он ведёт себя в распределённой системе. Compile-clean ≠ correct. Unit-тесты проверяют ровно то, что они скоупят.
Поэтому агент делает единственное, что может — объявляет изменение готовым и пушит вниз по pipeline, где работа по «а оно вообще пашет?» падает на ревьюера, интеграционные тесты, деплой на staging или инцидент в production. И вся компаундящаяся стоимость валидации включается на полную.
Замкнуть петлю — значит дать агенту способ автономно прогнать кандидатное изменение против реальной системы: реальные сервисы, реальные зависимости, реальные паттерны трафика. Быстро и дёшево настолько, чтобы агент мог итерировать, наблюдать, что сломалось, и пробовать ещё раз — без человека, без конкуренции за общий стенд staging, на скорости и масштабе агентов.
Почему не справляются текущие подходы
- Mocks — подделывают поведение зависимостей и проходят мимо реальных.
- Unit-тесты — покрывают индивидуальные функции, не интеграционную поверхность.
- Зелёный CI — говорит, что протестированное прошло. Это не равно «изменение корректно».
Чтобы петля действительно замкнулась, агенту нужно прогнать кандидата против настоящего состояния системы, а не модельного. И это требует инфраструктуры, которой массово в командах ещё нет: эпемерные окружения, изолированные на уровне one-PR-one-environment, с реальными зависимостями.
Часто задаваемые вопросы
Это не очередной маркетинговый материал?
Тезис о валидации как bottleneck — общеинженерный. Его озвучивают Google и Meta в публичных докладах, тестинг-вендоры (Garden, Signadot и другие), а в апреле 2026 года к нему публично присоединился и GitHub — через внутренний апдейт после двух инцидент в productionов. Конкретный продуктовый ответ у каждого свой, но проблема описана в одних терминах.
Что значит «закрытая петля» в практическом плане?
Это способность агента самостоятельно: (1) собрать своё изменение, (2) поднять окружение с реальными соседними сервисами, (3) прогнать релевантные сценарии, (4) увидеть, что сломалось, (5) переписать код и повторить — всё до того, как PR увидит человек. Технически это требует эфемерных окружений с быстрым стартом (секунды, не минуты), изоляции на уровне один-PR-одно-окружение и доступа агента к runtime-сигналам.
Сколько времени у нас, чтобы это построить?
Кривая роста в 30 раз не остановится — агенты будут писать код всё быстрее, и более способный агент без замкнутой петли просто производит больше непровалидированного кода, ещё быстрее. Команды, которые отложат сдвиг валидации в inner-loop, через 6–12 месяцев упрутся в потолок, который никаким горизонтальным масштабированием CI не пробьётся.
Это касается всех или только крупных платформ?
Любой команды, у которой больше нескольких микросервисов и регулярно рабтают агенты для кодинга. Стартапы из 5 человек могут не заметить — у них валидация и так в голове разработчика. Командам в 50+ инженеров с graph-of-services это уже актуально, в 500+ — критично. GitHub просто первым публично признал, что на их размере прежний план не работает.
Чек-лист для тимлидов
- Замерить текущую валидационную «вилку»: время от commit до зелёного staging для среднего PR. Если оно растёт — bottleneck уже здесь.
- Посчитать долю PR-ов с rollback или revert. Если rollback-rate растёт месяц к месяцу — петля у агентов открытая.
- Запустить пилот с ephemeral environments на одном из сервисов с самым большим интеграционные накладные расходы. Сравнить за 4 недели: процент PR-ов, прошедших валидацию с первого раза.
- Не наращивать мощности CI «в ширину» как первый ответ. Это лечит симптом, не причину.
- Дать агенту сигналы во время выполнения (не только compile + unit). Без них следующий шаг качества кода невозможен.
Выводы
Объём кода, генерируемого AI-агентами, растёт быстрее, чем планировали даже в GitHub. Стратегический вопрос для каждой инженерной организации сейчас простой: ваши агенты работают в замкнутой петле или открытой? Замкнутая — мультипликатор на throughput команды. Открытая — мультипликатор на те самые валидационные bottleneck-и, которые и так были самым узким местом.
Похожий тренд мы недавно разбирали в материале про tokenmaxxing: AI-ассистенты дают двукратную выработку кода ценой десятикратных затрат токенов и роста code churn на 861%. Природа проблемы одна: код производится массой, а инфраструктура к этому не готова.
Источник: The agent code explosion is here. We need to rethink our pipelines, fast — The New Stack.
