Инженерные команды, оценивающие кодинг-агентов, обычно начинают не с того вопроса. Они хотят знать, насколько автономным может стать агент. Какую часть конвейера он может взять на себя? Может ли он написать спецификацию, отредактировать репозиторий и отправить изменения в продакшн, никого не беспокоя? Демонстрации подпитывают эту одержимость. Вы видите отлаженный рабочий процесс, где один промпт запускает каскад правок и развертываний, и инстинктивно хочется добиться такой же возможности внутри своей организации. Но «глянец» — плохой принцип проектирования. Более важные вопросы куда менее захватывающие: кто наделил эту штуку полномочиями, к каким системам она может получить доступ на самом деле и что произойдет, когда она неизбежно совершит ошибку?

Ловушка автономии

Заманчивая автономия — это ловушка. Она приучает нас восхищаться ботами, которые генерируют спецификации, изменяют репозитории и развертывают код, спокойно заявляя, что задача выполнена. Это не инженерия. Это «прыжок доверия» с доступом к shell. Сама работа становится почти слишком легкой в производстве. Любая модель может за секунды выдать код, документацию или архитектурные планы. Но реальная стоимость разработки ПО никогда не заключалась в скорости печати. Она всегда заключалась в валидации, ревью и взвешенном решении сказать «да, это правильно и безопасно для выпуска». Сгенерированная работа дешева. Одобрение — дорого. Компании, которые поймут, как организовать процесс одобрения чисто и последовательно, станут теми, кто действительно выпускает надежные системы.

Почему самопроверка не работает

Риски проявляются по предсказуемым сценариям. Модель составляет план, а затем оценивает, насколько этот план хорош. Агент редактирует вашу кодовую базу и объясняет вам, почему его изменения безопасны. Инструмент выполняет команду и просит прощения вместо разрешения. Каждый из этих случаев представляет собой одну и ту же фундаментальную ошибку. Если агент создает спецификацию, кто-то вне этого агента должен утвердить её, прежде чем она станет истиной. Если агент изменяет код, отдельный процесс должен проверить diff. Позволять генератору выступать в роли собственного валидатора — это не сокращение пути. Это структурный баг, замаскированный под удобство.

Промпты — это не системы управления доступом

Вы не сможете обезопасить агента с помощью хитроумных формулировок. Приказ модели «будь осторожна» или «спрашивай, прежде чем что-то удалять» не создает границ. Промпты — это не системы управления доступом. Прежде чем подпустить агента к продакшну, вам нужно составить честный инвентарь его возможностей. Может ли он прочитать весь репозиторий? Может ли он выполнять shell-команды? Может ли он открыть браузер? Может ли он подтянуть данные клиентов в свое контекстное окно? Большинство команд не знают полных ответов. Они полагают, что инструмент ограничен песочницей, тогда как на самом деле он обладает правами на запись в критически важных путях. Сначала определите поверхность атаки. Затем стройте стены.

Создайте многоуровневую систему контроля

Как только вы поймете, что может делать агент, спроектируйте систему контроля, которая соотносит риск с уровнем трения (friction). Действия с низким риском, такие как обновление внутренней документации или форматирование кода, могут выполняться автоматически. Действия со средним риском, такие как рефакторинг модуля или добавление новой зависимости, должны проходить через контрольную точку, где человек или проверенный набор тестов подтверждает действие. Действия с высоким риском — развертывание в продакшн, изменение инфраструктуры или доступ к конфиденциальным данным — требуют отдельного лица, одобряющего изменения, которое не участвовало в их генерации. Каждое действие должно оставлять след аудита. Вы должны иметь возможность воспроизвести, какие именно файлы читались, какие инструменты вызывались и какие решения принимались. Агентная разработка — это не лицензия на отказ от ревью. Скучное «трение» — это полезная функция. Правильный шлюз одобрения работает как автоматический выключатель, когда процессы начинают отклоняться от нормы.

Соответствуйте границы уровню риска

Калибруйте свои границы в соответствии с реальной опасностью. Превращение каждой правки форматирования Markdown в торжественную церемонию комплаенса остановит работу вашей команды. Но считать высокорискованные действия безвредными только потому, что агент выглядит уверенным, — столь же глупо. Цель — пропорциональный контроль, а не театральные ограничения.

Делайте артефакты небольшими и наблюдаемыми

Самые полезные агентные системы не пытаются поразить вас масштабными автономными запусками. Они создают небольшие, проверяемые артефакты. Четкий план. Точечный diff. Читаемый лог. Гигантские автономные выполнения — это кошмар для отладки. Когда что-то ломается после сессии агента с пятьюдесятью файлами, вам приходится одновременно распутывать намерения, выполнение и побочные эффекты. Держите радиус поражения минимальным. Настаивайте на том, чтобы знать, какие файлы прочитал агент и какие инструменты он вызывал. Наблюдаемые системы — это поддерживаемые системы. Автономия «черного ящика» — это просто технический долг с лучшим маркетингом.

Шесть вопросов перед предоставлением доступа

Прежде чем передать агенту какую-либо реальную ответственность, проверьте свою конфигурацию на прочность с помощью шести жестких вопросов.

  • Какие возможности на самом деле есть у системы?
  • Какие действия запрещены по умолчанию и заблокированы на уровне инфраструктуры, а не просто не приветствуются вежливой фразой в системном промпте?
  • Какие действия требуют явного одобрения?
  • Какие артефакты «замораживаются» перед тем, как агент их использует, чтобы он не мог незаметно манипулировать собственными входными данными?
  • Какой валидатор, полностью отделенный от генератора, оценивает конечный результат?
  • Какой лог однозначно доказывает, что именно произошло?

Это базовая инженерная гигиена. Отделяйте генератор от валидатора. Сохраняйте контроль человека на границе системы.

Настоящая проверка

Там