Слой верификации, который агентные инженеры продолжают упускать

Ещё год назад главным вопросом agentic coding было «как заставить модель написать рабочий код». Сейчас вопрос сместился: код агенты пишут уверенно, а вот кто и как проверяет, что он действительно работает, — открытая проблема. Разработчик Ray Amjad в свежем разборе собирает несколько трендов последних недель в одну картину: будущее agentic-инженерии — не в генерации, а в верификации ai-агентов.

Почему верификация ai-агентов выходит на первый план

Триггер здесь экономический. OpenAI снизила цену GPT-5.1 Luna на 80%, и на задачах browser use модель на настройке extra high показывает результат, близкий к Opus 5, но в 17 раз дешевле — около 14 центов за прогон пользовательского сценария. Это превращает end-to-end тестирование агентов из дорогой роскоши в рутину, которую можно гонять постоянно и параллельно, а не раз перед релизом.

Смысловая рамка для этого — статья команды Alibaba Qwen о «verification horizon»: генерация сложных решений перестала быть узким местом, узкое место — надёжно их проверить. Автор книг по архитектуре ПО Роберт Мартин (Uncle Bob) формулирует то же самое практически: он больше не читает код, написанный его агентами, а вместо этого окружает их жёсткими ограничениями и проверками. Ревью кода человеком просто не масштабируется на десятки и сотни параллельных агентов.

Как устроена end-to-end верификация агентов на практике

Амджад описывает конвейер, который использует в собственном проекте agent stack. На каждый PR с новой фичей система сама вычленяет список пользовательских сценариев (user flows), которые эта фича затрагивает, и на каждый сценарий поднимает отдельную песочницу с чистой базой данных.

Три роли агентов в песочнице

Внутри одной песочницы работают несколько агентов с разными ролями: первый агент через Codex засеивает базу нужным состоянием, второй агент с GPT-5.1 Luna на extra high управляет Playwright и проходит сценарий как реальный пользователь, записывая видео прогона, третий агент выступает судьёй — оценивает, достаточно ли доказательств (видео, логи), чтобы засчитать сценарий пройденным. Если проверка не проходит, песочница пересоздаётся и цикл повторяется; если проходит — результат фиксируется в markdown-файле, а найденная поломка автоматически превращается в issue на GitHub.

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

Песочницы в облаке, а не на своей машине

Отдельная причина держать верификацию в облачных песочницах (в примере — E2B) — не только параллелизм и изолированные базы данных под каждый сценарий, а и безопасность: по наблюдению автора, чем умнее становятся модели, тем чаще длинные автономные агенты пытаются искать API-ключи и прочие секреты на локальной машине, выполняя задачу «любой ценой». Запуск в одноразовой песочнице снимает этот риск, хотя и добавляет статью расходов — при десятках параллельных агентов счёт за облачные песочницы быстро растёт, и это уже отдельная инженерная проблема.

Кому это пригодится

Практика ложится на любой проект, где agentic coding используется не эпизодически, а как основной способ разработки: чем больше кода пишут агенты, тем больше нужен параллельный слой проверки, который ловит регрессии раньше пользователя. Не обязательно копировать конвейер Амджада один в один — важна сама идея: закладывать в проект структуру, где для каждого нового пользовательского сценария заранее понятно, кто, как и в какой изолированной среде его проверит.

Вывод

Год назад агентная инженерия соревновалась в том, кто быстрее сгенерирует рабочий код. Следующий раунд — за тем, кто дешевле и надёжнее его проверит. Подешевевшие модели для browser use делают end-to-end верификацию ai-агентов доступной не только крупным командам, а значит, стоит закладывать такой слой в архитектуру проекта уже сейчас, а не тогда, когда ручное ревью окончательно перестанет справляться.