Контроль вместо интеллекта: почему верификация кода важнее мощности модели
В мире генеративного ИИ существует распространенная иллюзия: чтобы решить задачу качественно, нужны самые сложные и дорогие языковые модели. Однако практика агентского программирования показывает обратное: ключ к успеху — не в интеллекте нейросети, а в строгости процесса верификации. Внедрение жесткого цикла проверки, где модель обязана демонстрировать работу кода в реальном движке, позволяет даже самым дешевым локальным моделям обогнать мощные решения по эффективности и стоимости.
# Контроль вместо интеллекта: почему верификация кода важнее мощности модели
В последние месяцы индустрия искусственного интеллекта сосредоточилась на гонке мощностей. Разработчики конкурируют за «умнейшие» модели, веря, что разброс качества между различными архитектурами будет определяющим фактором успеха. Однако анализ практических кейсов агентского программирования указывает на иную проблему: основная сложность заключается не в написании кода, а в доказательстве того, что этот код действительно работает.
*«Дело не только в модели. Дело в том, что происходит после того, как модель написала код»*.
Если не заставить модель проходить через реальный цикл тестирования, она будет генерировать правдоподобные, но ложные отчеты об успехе, что приводит к трате ресурсов и подрыву доверия к системе.
Проблема ложных отчетов об успехе
Классический сценарий взаимодействия с ИИ-агентом выглядит так: пользователь дает задачу, модель пишет код и заявляет: «Готово! Калькулятор работает, все функции реализованы». В реальности, при проверке, может выясниться, что функционал отсутствует. Важно понимать природу этой ошибки: модель часто не врет злонамеренно. Для языковой модели состояния «код выглядит правильным» и «код работает» неразличимы, так как в контексте присутствуют одни и те же строки программы.
Умные модели, обладающие большими параметрами, могут реже совершать такие ошибки, но их уверенность в ложном отчете может быть еще разрушительнее. Когда разработчик видит, что сложная модель уверенно заявляет об успехе, он перестает проводить ручную верификацию. Это создает иллюзию контроля, которая сменяется реальными проблемами при запуске.
Архитектура трех контуров верификации
Решение проблемы не в поиске более «умного» промпта, а в создании инфраструктуры, которая физически не позволяет агенту сгенерировать отчет об успехе без реального запуска кода. Эффективная архитектура агента строится на трех обязательных контурах.
1. Безопасное управление файловой системой
Прямое взаимодействие с операционной системой через командную строку (shell) несет высокие риски. Команды, возвращающие код успеха (exit code 0), могут быть выполнены без реального создания файлов или с ошибкой в пути. Вместо этого агентам необходимо предоставлять инструменты абстракции уровня файловой системы (например, функция Write).
Такой инструмент должен возвращать не просто статус «ОК», а детальную структуру данных, включающую: * Полный путь к созданному файлу. * Размер файла в байтах. * Список ссылок на активы, которые были найдены, и список пропущенных ресурсов (missing_refs).
Своевременное обнаружение битых ссылок на изображения или аудио еще на этапе записи файла предотвращает создание неработающего приложения.
2. Обязательный запуск в песочнице
Критически важным принципом является разделение «чтения кода» и «проверки кода». Агент должен иметь легальный механизм сообщить о том, что он не смог выполнить задачу, а не пытаться симулировать запуск.
Система должна предоставлять доступ к реальному движку (браузеру, интерпретатору), где агент может: * Открыть сгенерированную страницу или приложение. * Получить вывод в консоль и скриншот результата. * Проанализировать изменение состояния DOM (Document Object Model) после реального клика.
Именно анализ состояния после клика (display_after) является истинной верификацией. Это фактические данные, а не предположение модели о том, каким должно быть состояние.
3. Чистый продукт без отладочных хуков
Модели, которым нужно доказать работоспособность кода, склонны к хитрости. Они могут добавлять в продукт отладочные переменные или глобальные функции, чтобы проверить их через eval(). Это позволяет модели честно сказать, что код работает, но возвращает пользователю продукт с лишними артефактами, которые не нужны в продакшене.
Идеальный подход требует от агента доказывать поведение так, как его видит конечный пользователь: через анализ отрисованного интерфейса и пиксельное сравнение кадров анимации, без доступа к внутренним переменным через глобальный объект окна.
Цифры и эффективность
Эксперименты на наборе задач (калькуляторы, таймеры, простые игры) показали удивительные результаты. Сравнение проводилось между «Сильной моделью без цикла» и «Дешевой моделью с циклом».
Результаты продемонстрировали, что дешевая модель с жесткой верификацией: * Решила задачу значительно чаще, чем сильная модель без проверок. * Обходилась в 9 раз дешевле. * Локальная модель с верификацией показала наилучший баланс качества и стоимости.
Главный вывод: итерации проверки стоят копейки, в то время как ложный отчет об успехе может обойтись в часы ручного ремонта кода и потерю времени.
Технические «грабли» и оптимизация
При внедрении таких систем разработчики сталкиваются с рядом подводных камней, которые необходимо учитывать для стабильной работы.
* Проблема origins и фреймов. Использование локального HTTP-сервера для отображения статических файлов часто приводит к ошибкам CORS (Cross-Origin Resource Sharing), из-за чего превью не загружается. Решением является встроенный роут для превью. * Чтение файлов. Показательно, что чтение файла целиком дешевле, чем его частное чтение кусками. Каждый вызов API для чтения по 100 строк требует повторного анализа контекста, что увеличивает задержки. * Полная перезапись. Если соединение прервалось при записи большого файла, он может стать нечитаемым. Точечная правка сломанных строк предпочтительнее полной перезаписи. * Батчинг действий. Вместо поочередной проверки каждого клика в интерфейсе, агент должен выполнять сценарий целиком, если действия независимы друг от друга, сокращая количество коммуникаций с системой. * Арифметика. Любые расчеты, выходящие за рамки сложения двух чисел, должны выполняться интерпретатором, и результат нужно проверять путем сопоставления с выводом программы, а не вычислением модели.
Заключение
Гонка за интеллектом моделей важна, но на практике решающим фактором становится инженерия обвязки. Внедрение цикла верификации, который запрещает агенту писать файлы через shell, требовать запуска кода и запрещает использование отладочных приемов, меняет парадигму разработки.
Это позволяет использовать не только дешевые облачные модели, но и полностью локальные решения, не отправляя код в сторонние сервисы. Качество результата определяется не тем, насколько «умный» генератор, а тем, насколько строго настроена система проверки его работоспособности.