GitHub за четыре месяца нарастил месячный поток коммитов с 1,4 млрд до 2,9 млрд. Для всех, кто следит за темой AI-агентов в разработке, это не просто красивая метрика роста: проверка AI-кода явно не поспевает за скоростью его генерации, а значит узкое место в инженерных процессах смещается из написания в верификацию.
Об этом как пишет The New Stack рассуждает Арджун Айер в колонке от 29 августа 2026 года. Отправная точка у него вполне конкретная: GitHub впервые показал публичную инфраструктурную цифру, которая похожа не на маркетинговый бенчмарк вендора, а на след массового прихода агентной разработки в реальный продакшен. Платформа, по словам автора, уже обрабатывает 2,9 млрд коммитов в месяц, около 130 млн слитых pull request и 24 млн новых репозиториев. Издание Engadget, на которое ссылается The New Stack, пишет, что в GitHub связывают этот скачок именно с AI-сгенерированным кодом.
История быстро перестала быть теорией и превратилась в инфраструктурную проблему. 17 августа GitHub пережил сбой длиной 7 часов 47 минут: в центральном дата-центре США не выдержал нагрузки один из базовых компонентов платформы. В разборе инцидента CTO GitHub Владимир Федоров прямо признал, что в тот день сервис подвел команды, пытавшиеся доставлять софт. Ответ на аварию был предсказуемо «гиперскейлерский»: более 3 млн новых CPU-ядер, 120 ПБ быстрого хранилища и ускоренная миграция в Azure, на которую уже приходится 58% нагрузки платформы. Для GitHub проблема выглядит как дефицит мощностей. Для команд, которые сидят поверх GitHub, проблема неприятнее: железо можно докупить, доверие к изменениям в коде масштабируется куда хуже.
Главный тезис колонки в том, что генерация кода стала машинной по темпу, а проверка осталась человеческой. И это не спор о вкусе, а конфликт двух скоростей. Если раньше объем коммитов более-менее рос вместе с числом разработчиков, то теперь кривая отвязалась от headcount. Один инженер, который гоняет несколько агентных сессий параллельно, может выдать поток изменений, на который старые процессы review, тестирования и выката просто не были рассчитаны. Отсюда и неприятный вывод: количество сгенерированного кода перестало быть дефицитным ресурсом. Дефицитом становится уверенность, что этот код вообще делает то, что обещает.
Для русскоязычной IT-аудитории здесь нет ничего экзотического. Почти у любой команды уже есть знакомый набор симптомов: pull request становится больше, веток одновременно открыто больше, ревью висит дольше, staging превращается в очередь, а end-to-end проверка откладывается на потом, потому что «сначала бы просто смерджить». AI-инструменты частично помогают на входе: они умеют разбирать диффы, находить очевидные дефекты, оптимизировать CI, подсказывать, какие тесты прогнать. Но это, по сути, ускорение фильтра перед настоящей проверкой. Ни AI-ревью, ни статический анализ не доказывают, что изменение не развалится при контакте с живыми сервисами, данными, очередями и зависимостями.
Именно здесь, по версии автора, упирается проверка AI-кода. В традиционной cloud-native разработке поведенческая верификация все еще завязана либо на общий staging, либо на дорогие и медленные копии полноценного стека. Оба подхода плохо переживают взрывной рост изменений. Один общий стенд неизбежно становится бутылочным горлышком. Полные дубли окружения слишком дороги, чтобы поднимать их на каждый коммит. Пока код писали люди в привычном темпе, отрасль с этим как-то жила: были конфликты, очереди и периодические задержки, но система не рушилась. С агентами старая математика ломается. То, что раньше нагружало платформенную команду на 500 инженеров, теперь может прилететь в команду из 50 человек, если она просто включила параллельную генерацию.
Дальше у компаний, по сути, три пути, и все неидеальны. Первый: ускорять review и надеяться, что автоматические проверки поймают больше дефектов до мержа. Второй: искусственно душить агентов, ограничивая объем создаваемых изменений, чтобы не убить pipeline. Третий: мержить быстрее, а разбираться потом, уже на сломанном staging, в регрессии или в проде. Последний путь особенно соблазнителен, потому что сначала выглядит как рост производительности, а потом внезапно оказывается ростом стоимости инцидентов. И если 17-августовский сбой GitHub был аварией железа и масштаба, то для обычной продуктовой команды аналогичный провал чаще выглядит как накапливающийся долг в тестировании и интеграции.
У колонки есть и прикладной вывод. Если генерация стала почти бесплатной, выигрывать будут не те, кто производит больше коммитов, а те, у кого проверка AI-кода растет вместе с этой генерацией. Иначе все бонусы от агентов быстро превращаются в более длинную очередь на ревью, более токсичный staging и более дорогие разборы полетов. Вопрос на ближайшие годы звучит уже не как «нужны ли команде AI-агенты», а как «что в вашем процессе сломается первым, если объем изменений удвоится за четыре месяца». Судя по данным GitHub, это уже не гипотеза для конференционного доклада, а вполне рабочий стресс-тест для любой инженерной организации.