Компании, которые перевели часть разработки на ИИ-агентов, получили ожидаемый эффект по скорости генерации кода и менее ожидаемый по управлению процессом. Новым узким местом стали проверка изменений, архитектурный контроль и распределение ответственности. Иными словами, писать стало быстрее, а собирать это в устойчивый продукт сложнее.
Сдвиг заметен в корпоративной разработке, где ИИ-системы уже не ограничиваются подсказками в редакторе, а могут самостоятельно генерировать и запускать код. Это снимает часть ручной работы, но не убирает старые проблемы: неясные требования, сложные интеграции, зависимость от легаси-систем и поддержку в продакшне. В результате скорость выпуска кода растёт быстрее, чем способность команд понимать последствия изменений.
На практике нагрузка переехала к людям, которые принимают решения о слиянии изменений, доступах и приоритетах. Чем больше кода выдают агенты, тем больше объём ревью и тем слабее у инженеров локальный контекст по каждому изменению. Это повышает риск дефектов, регрессий и архитектурных расхождений между командами, даже если формально производительность по числу закрытых задач выглядит лучше.
Главная проблема в том, что код перестал быть дефицитом. Ещё до бума генеративного ИИ задержки в разработке чаще возникали не на этапе написания функций, а на согласовании требований, проверке влияния на соседние сервисы и разборе аварий после релизов. Агентные системы усилили этот перекос: они ускоряют выпуск изменений, но не снижают неопределённость в архитектуре.
Отсюда и перегрузка code review. Если раньше старший инженер смотрел несколько осмысленных пул-реквестов в день, то при массовом использовании агентов он получает поток мелких и средних изменений, часто без полноценного объяснения причин и ограничений. Формально код может проходить тесты, фактически команда тратит больше времени на проверку побочных эффектов, прав доступа и совместимости с внутренними стандартами.
Второй слой риска связан с управлением. Когда агентам дают доступ к репозиториям, внутренней документации, CI/CD и иногда к облачной инфраструктуре, вопрос «кто именно внёс изменение» становится менее формальным, чем раньше. Компаниям приходится заново описывать цепочку ответственности, вводить журналирование действий и разделять права чтения, генерации и выполнения. Принцип минимальных привилегий для ИИ здесь выглядит не как рекомендация службы безопасности, а как способ не остановить продакшн одним неудачным циклом.
Есть и прямой финансовый эффект. При масштабировании агентных систем растут расходы на модели, оркестрацию, тестовые прогоны и хранение контекста. В отрасли уже описывали случаи, когда плохо ограниченные циклы работы агентов раздували счёт за ИИ-инфраструктуру в разы. Поэтому вместе с агентами компании вводят лимиты, квоты и правила эскалации для операций, которые затрагивают боевые системы.
Это меняет и подход к оценке эффективности команды. Метрики в духе «строк кода» или «числа закрытых тикетов» становятся ещё менее полезными, чем были до бума ИИ. На первый план выходят частота инцидентов после релиза, доля откатов, устойчивость к регрессиям и скорость восстановления сервиса. Код теперь легко произвести. Дорого обходится его безболезненное внедрение.
Крупные игроки косвенно подтверждают этот сдвиг. В 2025 году Сатья Наделла говорил, что в отдельных проектах Microsoft ИИ пишет до 30% кода. Google ещё раньше сообщала, что более четверти нового кода в компании генерируется ИИ и затем принимается инженерами. Эти цифры показывают масштаб автоматизации, но не отменяют того факта, что финальную ответственность за архитектуру и качество по-прежнему несут люди.
На этом фоне компании начинают перестраивать стек разработки вокруг нескольких моделей сразу. Один класс моделей используют для генерации и рефакторинга, другой для анализа кода и документации, третий для проверки политик безопасности. Такой подход снижает зависимость от одного поставщика и позволяет точнее подбирать стоимость и качество под конкретную задачу. Заодно исчезает иллюзия, что одна универсальная модель закроет весь инженерный цикл.
Меняется и роль самих разработчиков. Ценность смещается от написания синтаксиса к системному проектированию, работе с интерфейсами между сервисами и контролю поведения агентных процессов. По оценке Gartner, к 2028 году ИИ-инструменты будут использовать три четверти корпоративных инженеров. Это означает не сокращение объёма инженерной работы, а её перенос в более дорогие зоны: архитектуру, ревью, безопасность и эксплуатацию.
Следующий этап для корпоративного ИИ будет зависеть не от того, насколько быстро модель пишет код, а от того, насколько компания умеет ограничивать её полномочия и измерять эффект после релиза. Если эти процессы не перестроить, выигрыш в скорости быстро съест рост инцидентов и операционных затрат. Рынок средств для software engineering с ИИ продолжит расти, но деньги там уже уходят не только в генерацию, а в аудит, наблюдаемость и контроль изменений.
