Claude, Gemini и GPT-5 стали символами новой гонки за автоматизацию разработки, но у этой гонки появился неприятный для продавцов copilot-счастья вывод: AI-агенты в разработке уже способны закрывать почти весь жизненный цикл ПО, и именно поэтому им нельзя отдавать его целиком. Для русскоязычных команд это важный сигнал: узкое место теперь не в том, кто быстрее пишет код, а в том, кто держит в руках архитектуру, контекст и ответственность за последствия.
В колонке с намеренно колючим заголовком, как пишет The New Stack, разговор предлагается резко сдвинуть в сторону от привычной темы безопасности. Последние два года индустрия в основном спорила о секретах в prompt, лицензиях, уязвимостях в сгенерированном коде и о том, не заведет ли агент в прод какой-нибудь особенно бодрый абсурд. Но сам по себе вопрос безопасности уже не объясняет, где AI реально полезен, а где начинает дорого вредить. Модель действительно может написать код, тест, документацию, SQL-запрос, release notes и даже помочь с разбором инцидента. Это больше не магия и уже не новость. Новость в другом: возможность выполнить задачу еще не означает право ею владеть.
На практике весь спор упирается в путаницу между кодингом и инженерией. Рынок с удовольствием продает картинку, где агент берет тикет, проходит путь до pull request, сам гоняет проверки и чуть ли не машет рукой релиз-менеджеру на прощание. Звучит красиво, особенно для менеджмента, которому после пары демо хочется купить ускорение оптом. Но кодогенерация — лишь один фрагмент доставки софта. Вокруг нее есть требования, неявные договоренности между командами, старые компромиссы в архитектуре, ограничения по данным, интеграции, регуляторика и та самая память проекта, которая редко лежит в README. Когда AI ускоряет только набор кода, бутылочное горлышко не исчезает. Оно просто переезжает в review, тестирование, согласование границ изменений и разбор странных побочных эффектов.
Отсюда и главный практический критерий. Хорошие задачи для AI-агентов в разработке — те, что сводятся к узнаваемому шаблону и дают проверяемый результат. Boilerplate, шаблонные endpoint, генерация unit-тестов, повторяющиеся рефакторы, конфигурационные правки, обвязка вокруг уже понятного интерфейса — все это машина отрабатывает быстро и, что не менее важно, без лишней драмы. Пограничная зона начинается там, где разработчик должен сначала определить рамку задачи: что именно менять, чего не трогать, какие ограничения считать жесткими, чем пожертвовать, если все сразу не помещается. А вот плохие кандидаты на автономию — архитектурные развилки, изменения межсервисных контрактов, решения с длинным хвостом последствий и работа, где правильный ответ зависит не от паттерна в коде, а от договоренностей между людьми.
Это неприятная мысль для тех, кто всерьез ждал универсального цифрового мидла, но логика у нее железная. LLM видит репозиторий, логи и тикеты. Он не видит спор на созвоне двухнедельной давности, где команда отказалась от красивого решения из-за сроков клиента. Он не помнит, что сервис ведет себя странно не по ошибке, а потому что так когда-то обошли зависимость от древнего внешнего API. Он не чувствует, что формально безопасный рефактор сейчас не стоит трогать, потому что соседняя команда в эту же неделю меняет схему событий. Иными словами, модель хорошо читает артефакты, но плохо считывает реальность вокруг них. А в зрелой разработке именно эта реальность обычно и решает, будет change request успехом или дорогостоящим откатом.
Для CTO, техлидов, продактов и даже HR из этого следует довольно приземленный вывод. AI-агенты в разработке не отменяют потребность в сильных инженерах, а скорее меняют цену их времени. Чем лучше в компании описаны контракты, ownership, acceptance criteria, ADR, правила эскалации и границы сервисов, тем больше механической работы можно безболезненно отдать машине. Чем хуже все это формализовано, тем быстрее агент превращается в очень бодрого джуна, который печатает с космической скоростью, редко сомневается и почти никогда не задает тот самый неудобный вопрос вовремя. Для бизнеса это означает простую вещь: покупать еще одну модель проще, чем построить среду, где ей безопасно доверить кусок процесса. Но без этой среды ROI от модной автоматизации очень быстро уходит в доработки, повторные проверки и новый слой управленческого контроля.
Следующий раунд конкуренции, похоже, пройдет не только между Claude, Gemini и GPT-5, а между компаниями, которые сумеют превратить неявное инженерное знание в явные правила работы. Кто научится четко делить задачи на машинные и человеческие, тот получит ускорение без лишнего героизма. Кто продолжит верить в волшебный режим от тикета до прода, скорее всего, обнаружит старую проблему в новой упаковке: pull request стало больше, а инженерного суждения по-прежнему не хватает.