Аудит ИИ-агентов: как отделить реальность от галлюцинаций в коде
Перевод ответственности за разработку на автоматизированные системы сместил главную проблему с написание кода на его верификацию. Автор опыта описывает многоуровневую систему проверки, включающую специализированных ревьюеров, скептически настроенных агентов-опровергателей и детерминированный сборочный конвейер, способный остановить развертывание при обнаружении фактических несоответствий, даже при успешном прохождении линтеров и тестов.
# Инженерия доверия: Как построить конвейер качества для ИИ-агентов
Когда на сайт передают управление ИИ-агентами, скорость написания кода перестает быть определяющим фактором эффективности. На смену ему приходит совершенно иная метрика: способность системы отличать рабочее решение от компетентно сформулированной выдумки. Практика показывает, что без глубокой интеграции проверочных механизмов узкое место процесса разработки смещается с генерации на валидацию.
Специализация и конфликт интересов
Эффективная архитектура автоматизированного ревью не полагается на универсальных экспертов. Вместо этого используется стратегия распределения ролей с явным разделением ответственности.
Специализированные линзы (Reviewers-Lenses): Универсальный анализ склонен к поверхностности. Поэтому аудит разбивается на узкие категории: анализ токенов, анимаций, CSS, мобильной верстки, типографики и т.д. Использование множества узких взглядов выявляет проблемы, которые скрыты от общего обзора.
Агенты-скептики (Skeptics): Ключевой элемент безопасности — агенты, чья прямая задача состоит в опровержении найденных дефектов. Они не оценивают качество, а ищут причины, почему дефект может не существовать или предлагать правку. Находка считается валидной только тогда, когда выдерживает давление большинства скептиков.
Статистика подхода наглядно демонстрирует его эффективность: в одном из проектов из 111 находок аудита кодовой базы 25 были отклонены как ложные, а 4 имели критический характер: они описывали реальную механику кода, но делали неверный вывод о необходимости исправления. Предложенная «правка» в таких случаях могла бы сломать работающий функционал, если бы не была отловлена на этапе верификации.
Сторож: Проверка фактов, а не логики
Агенты-скептики ловят ошибки рассуждения, но пропускают классы ошибок, не связанные с логикой, а с фактическими данными. Стандартные инструменты разработки — линтеры и тесты — часто невидят этих угроз, так как тестируют предсказуемые сценарии.
Для компенсации этой слепоты внедряется система детерминированных правил сбора («сторож»), которая падает при обнаружении нарушений фактов: * Соответствие контенту внешних источников (кейсы, контакты). * Соблюдение соглашений о неразглашении (NDA) в названиях файлов и текстах. * Отсутствие самоподменяемых токенов и обрывков фраз из-за ошибочных замен. * Целостность изображений и отсутствие чужих логотипов в продакшене.
Важнейшее правило этой системы: каждое новое правило валидации проверяется подсадкой ошибки. Это позволяет выявить баги в самих проверках до того, как они достигнут реального использования.
Компетентные ошибки и гипотезы
Одной из самых опасных категорий ошибок является компетентная галлюцинация. Модель может верно проанализировать код, сослаться на конкретные строки и предложить технически обоснованное решение, которое приведет к регрессии. Единственный способ отделить это от реальности — проверка против исходного кода, а не текста отчета.
Кроме того, необходимо помнить, что любой комментарий, написанный агентом, является гипотезой, а не фактом. Утверждения, сделанные в документации кода, требуют подтверждения командой или инструментами. В противном случае, как показала практика, даже детальное описание процессов может быть ошибочным предположением, а не фактом.
В конечном итоге, главный навык при работе с ИИ-агентами смещается от умения формулировать задачи к способности быстро и rigorously проверять результат. Автоматизация пишет код, но человек должен уметь быстро отличить работающую систему от той, что выглядит рабочей, но ведет себя иначе.