The New Stack 25 июля 2026 года вынес в заголовок мысль, которая многим не понравится, но слишком похожа на правду: если ИИ-агент не справился с задачей, бесконечно править его код вручную уже мало полезно. Гораздо важнее собрать среду, где агент видит ограничения проекта, запускает проверки и получает понятный сигнал, что именно сломалось.
Для русскоязычных команд это не спор в духе «заменит ли ИИ программиста». Вопрос практичнее: если код все чаще пишет агент, работа инженера смещается к тестам, спецификациям, правам доступа и наблюдаемости.
Источник тезиса — материал The New Stack и выступление Patrick Debois
Поводом стал материал Stop correcting AI code. Build the system agents need, который The New Stack опубликовал 25 июля 2026 года. В нем Patrick Debois, автор термина DevOps и сотрудник Tessl, формулирует сдвиг предельно прямо: если агент сделал не то, «улучшайте систему, а не подсказку».
Эта мысль продолжает его июньское выступление на PlatformCon London — Context is the new code: The context development lifecycle. Идея в том, что вокруг агента нужен не один цикл CI/CD, а несколько контуров: генерация, оценка результата, распространение контекста и наблюдение за поведением системы.
Проблема не в коде, а в контуре проверки
Классическая схема «модель сгенерировала, разработчик потом подчистил» плохо масштабируется. Агент может быстро собрать патч, но без доступа к тестам, журналам, правилам проекта и безопасному окружению он остается разговорчивым стажером, который уверенно ошибается.
Именно поэтому в разговоре об ИИ-разработке все чаще обсуждают не качество автодополнения, а качество верификации. Для продукта с несколькими сервисами, внутренними SDK и наследованными зависимостями одной проверки в CI/CD уже мало: баги часто живут на стыке сервисов, прав доступа и реального рантайма.
Роль инженера сдвигается к спецификациям и наблюдаемости
Из этого следует неприятный, но полезный вывод. Инженер все меньше работает «ручным корректором» вывода модели и все больше проектирует правила игры: какие тесты обязательны, что агенту можно менять, где смотреть телеметрию и по каким критериям считать задачу выполненной.
Для компаний в России и СНГ это особенно актуально в крупных продуктах, где много интеграций, самописных сервисов и регуляторных ограничений. Там слабое место давно не скорость написания кода, а предсказуемость изменений. Если внедрить агента без тестовой инфраструктуры и изолированных сред, команда получит не ускорение, а более дорогую версию хаоса.
Для рынка это означает рост роли инженерной инфраструктуры
Практический вывод простой: выигрывать будут не команды с самым громким названием модели, а те, кто лучше описал систему и научил агента проверять себя на реальных сценариях. На таком фоне вложения в тестовые стенды, спецификации и наблюдаемость выглядят уже не как технический долг на потом, а как базовое условие для работы с ИИ-инструментами.
Следующий логичный шаг для рынка очевиден: конкуренция сместится с «кто быстрее генерирует код» к «кто быстрее и безопаснее проверяет результат».