Platform engineering добился того, ради чего его и строили: по данным DORA 2025, около 90% организаций уже используют хотя бы одну внутреннюю платформу. Но теперь у платформенных команд новый клиент, и он куда капризнее живого разработчика: AI-агенты хотят получать среды для проверки кода не «сегодня после обеда», а за секунды. Для российских команд, которые уже экспериментируют с агентной разработкой, это плохая новость в том смысле, что старые процессы внезапно оказываются слишком медленными даже там, где раньше все считалось прилично автоматизированным.
Об этом пишет The New Stack в спонсорской колонке Арджуна Айера, CEO Signadot. Его тезис довольно жесткий: platform engineering выиграл прошлую войну, но может проиграть следующую, если продолжит думать о средах как о заявках на provisioning, а не как о сервисе с запросами, пиками нагрузки и требованиями по задержке. Раньше золотой стандарт выглядел так: золотые пути, self-service, запрос на тестовую среду за часы вместо дней. Теперь этого уже мало, потому что код генерирует не один инженер, который поднял стенд и ушел пить кофе, а агент, который работает короткими итерациями, параллельно и без лишней вежливости к чужому расписанию.
В статье приводятся цифры, которые объясняют, почему проблема перестала быть теорией. GitHub Octoverse насчитал 43,2 млн merge pull request в месяц, что на 23% больше год к году. Отдельно упоминается, что coding agent от Copilot за первые пять месяцев открыл более миллиона pull request. Плюс Stack Overflow в опросе за 2025 год зафиксировал, что половина профессиональных разработчиков уже пользуется AI-инструментами ежедневно. Если такой разработчик ведет не один, а два-три параллельных агентных сеанса, спрос на окружения больше не связан напрямую с числом сотрудников. Он считается по другой формуле: количество инженеров, умноженное на число агентов, умноженное на число итераций. И вот тут даже аккуратно вылизанная платформа начинает подозрительно скрипеть.
Айер разбирает две привычные модели, и обе у него выглядят как ловушки. Первая: делать полную копию стека под каждый запрос. Для системы из десятков сервисов, баз и очередей это означает минуты или десятки минут на разворачивание, несколько долларов в час на каждую копию и почти гарантированный рост счета линейно вместе с активностью агентов. Вторая модель: один общий staging, куда изменения заходят по очереди. Здесь уже ломается не экономика, а теория массового обслуживания: как только поток запросов приближается к пропускной способности среды, очередь перестает расти «понемногу» и начинает взрываться. А если один неудачный change ломает общий стенд, страдают все, кто стоит за ним в этой веселой очереди. В результате команды начинают батчить изменения, чтобы «реже ходить на стенд», и сами же ухудшают ситуацию.
На этом месте автор предлагает сменить саму рамку обсуждения. Не «выдаем среды», а «обслуживаем трафик». Для платформенной команды это очень разный набор привычек. Provisioning-процесс можно считать успешным в момент, когда среда просто создана. Сервисная модель живет по другим метрикам: latency, concurrency, marginal cost на запрос и безопасная многопользовательская работа на общей инфраструктуре. Проще говоря, раньше единицей работы был тикет, теперь это request. Раньше нормой были часы, теперь целевой ориентир смещается к секундам. И это, пожалуй, самый полезный фрагмент всего текста: автор не столько рекламирует конкретный продукт, сколько довольно точно называет новую эксплуатационную задачу.
Практическое решение у Signadot ожидаемо свое: не копировать весь стек, а «подавать дельту». Базовая, постоянно обновляемая копия системы работает как стабильный production-like слой. Когда приходит запрос на валидацию, поднимаются только измененные сервисы как легковесные ephemeral environments, а трафик конкретного запроса маршрутизируется через их версию. Все остальное уходит в общую стабильную среду. Логика понятная: если изменился один сервис, нет большого смысла заново тащить за ним весь зоопарк зависимостей. В такой схеме время старта падает до секунд, предельная параллельность упирается уже в емкость кластера, а стоимость на один запрос остается низкой, потому что дорогая часть инфраструктуры шарится между многими проверками.
Здесь важно не забывать, что перед нами именно взгляд вендора, причем вендора Kubernetes-native платформы. Поэтому текст стоит читать не как нейтральный исследовательский отчет, а как хорошо аргументированный industry pitch. Но это не отменяет главного: сама постановка проблемы вряд ли исчезнет. Тем более что The State of Platform Engineering, на который ссылается автор, показывает: 94% организаций считают AI критически важным для будущего platform engineering. И если кодогенерация действительно становится дешевой, узкое место смещается вниз по конвейеру, туда, где изменения нужно проверять на реальной системе, а не на аккуратных моках, которые агент сам себе и придумал.
Для разработчиков это означает довольно неприятную, но полезную мысль: следующий дефицит в инженерии может быть не в моделях и не в токенах, а в пропускной способности валидации. Для бизнеса тоже вывод без особой романтики: покупка очередного coding assistant сама по себе не ускоряет поставку фич, если платформа не умеет переваривать сотни короткоживущих проверок в день. И главный вопрос здесь уже не в том, будут ли у команд AI-агенты, а в том, успеет ли их внутренняя платформа перестроиться из фабрики стендов в систему обслуживания запросов на агентной скорости.