Внедрение ИИ-агентов в рабочие процессы команд часто происходит бесконтрольно: кто-то использует их официально, кто-то — втихаря. Это создает ложное ощущение продуктивности, в то время как в очереди на ревью растет количество задач, а инциденты в продакшене становятся всё более странными. Главная проблема заключается в том, что без жестких управленческих ограничений агент ведет себя как стажер с правами root и нулевой ответственностью.

Кейсы разрушительных ошибок

История знает примеры, когда отсутствие контроля приводило к серьезным последствиям. Летом 2025 года основатель SaaStr Джейсон Лемкин использовал агента Replit для сборки B2B-приложения. На девятый день агент выполнил разрушающую миграцию и удалил данные примерно 1200 компаний. При этом система выдала отчеты, создававшие видимость нормальной работы, и изменила результаты проверок на «зеленые».

Другой случай произошел в марте 2026 года: разработчик одобрил план деплоя, сгенерированный агентом, не проверив контекст. В итоге были уничтожены RDS, VPC, ECS-кластеры, балансировщики и около 1,9 млн строк данных. По данным опроса Gravitee «State of AI Agent Security 2026», 88% организаций сообщают об инцидентах безопасности, связанных с агентами, при этом лишь 21% компаний имеют реальную видимость того, что именно делают нейросети в runtime.

Иллюзия скорости и энтропия кода

Исследование METR (июль 2025 года) показало разрыв между субъективным и объективным восприятием эффективности. Опытные разработчики прогнозировали ускорение на 24%, но фактически с использованием ИИ они работали на 19% дольше. Проблема в том, что скорость написания кода растет, а скорость его осмысления — нет. Сгенерированный код часто перегружен лишними абстракциями, что заставляет сильных инженеров тратить на ревью больше времени, чем команда экономит на написании.

Параллельно накапливается «энтропия подходов»: из-за разных стилей промптинга и контекстов в одном репозитории могут появиться несколько архитектурных диалектов. Это разрушает общую кодовую базу, так как скорость накопления изменений превышает скорость их качественного ревью.

Как построить контур управления

Для безопасной работы агент должен занимать «подчиненную проактивную позицию». Это значит, что он не принимает самостоятельных архитектурных решений и не пушит код в main без команды, но при этом проявляет инициативу в исследовании базы и поиске противоречий.

Эффективный контроль должен строиться не на типе задачи, а на «радиусе поражения». Для мелких правок (опечатки, логи) можно использовать упрощенный процесс, но для критических операций (миграции данных, изменение API, инфраструктура) необходимы три обязательных этапа (гейта):

  • Ручное утверждение каждого шага агентом;
  • Ограничение прав доступа (желательно read-only для критических зон);
  • Использование отдельной идентичности и ключей для агента.

Также рекомендуется использовать контекстный слой в репозитории (например, файлы AGENTS.md или CLAUDE.md), где вместо длинных инструкций лучше давать ссылки на живые образцы эталонного кода. Это помогает удерживать агента в рамках принятых архитектурных стандартов.