Архитектор переосмыслил, что такое ИИ-агент: проверку кода пора проектировать заранее

Что такое ИИ агент в этой логике? ИИ-агент (agent) это программа на основе нейросети, которая сама проходит цепочку шагов: разбирает требования, пишет код, добавляет тесты. Автор исходной колонки, практикующий архитектор, предлагает мысленный опыт. Вечером вы оставили агентам задачу, утром нашли готовую реализацию, все проверки зелёные. Вы это выпустите в релиз?

Его ответ: раньше доверие рождалось из того, что мы сами проходили путь к результату. Мы писали важный кусок, обсуждали решение с коллегой, смотрели diff (список изменённых строк). Когда код пишет агент, этого пути нет, поэтому основания доверия придётся создавать до начала работы.

Автор сам называет часть своих идей гипотезами, которые ещё предстоит проверить. Это честная рамка: перед нами взгляд на направление развития инженерии, а не готовый стандарт.

Часы или вода: в чём суть средового подхода?

Часы идут, только когда детали соединены определённым образом, и отвечаем мы за них через понимание устройства. Волны на воде описывают иначе: никто не следит за каждой молекулой, работают со свойствами жидкости, глубиной и формой границ.

Средовой подход переносит второй взгляд на агентов. Задача архитектора в том, чтобы проектировать не только очередную конструкцию, но и условия, в которых нужные конструкции будут появляться многократно.

Что понадобится для контура проверки?

• ИИ-агент для работы с кодом, облачный или развёрнутый внутри компании.
• Набор автоматических проверок: интеграционные, нагрузочные и сквозные тесты (e2e, проверка сценария целиком, как его прошёл бы пользователь).
• Демостенд, то есть рабочая копия продукта для показа основных сценариев.
• Механизм отката изменений.
• Перечень знаний и документов, к которым у агента есть доступ.
• Время архитектора или ведущего разработчика на первую версию правил.

Пошаговая инструкция: как принимать работу агента без слепого доверия

1. Определите продукт и цену ошибки. Первый вопрос автора звучит так: «Какой продукт?» Правки во внутреннем отчёте и в платёжном модуле требуют разной глубины приёмки.
2. Зафиксируйте, к каким знаниям у агента был доступ. В российских командах с ограниченным доступом к облачным моделям сюда стоит добавить, какая модель работала и где хранились данные.
3. Разведите авторство кода и проверок. Если агент сам написал и код, и тесты, зелёные тесты говорят меньше, чем кажется.
4. Подготовьте откат до запуска. Вопрос «можно ли откатиться?» закрывается на этапе проектирования, а не в момент сбоя.
5. Договоритесь о движении решений: кто предлагает изменения и как остальные участники узнают о принятом решении.
6. Настройте сигналы. Ищите признаки того, что заданные условия систематически приводят агентов к плохим решениям, и правьте сами условия, а не только код.

Шаблон вопросов, которые стоит прогонять перед каждой приёмкой:

1. Какой продукт затронут и чем грозит ошибка?
2. Что именно изменилось?
3. Кто писал тесты и прочие проверки: агент или человек?
4. Можно ли откатиться и как быстро?
5. К каким знаниям и данным был доступ у агента?
6. Повторяется ли эта ошибка у агентов систематически?

Что делать с этим прямо сейчас, по ролям

Автору Дзена: если вы пишете о нейросетях, объясняйте читателю разницу между «код готов» и «результат принят». Если вы сами отдаёте агенту черновики, задавайте те же вопросы: к каким источникам был доступ и кто проверял факты.

Маркетологу: генерация дешевеет, а приёмка остаётся человеческой работой. Закладывайте в сроки проектов время на проверку, а не только на производство.

Предпринимателю РФ и СНГ: с учётом требований к импортозамещению проверки лучше держать независимыми от поставщика модели, чтобы при смене модели контур приёмки остался на месте. Из доступных в РФ аналогов это YandexGPT и GigaChat.