Проверка результатов агента

Аксиома, с которой начинается вся работа с агентами: результат агента — это черновик, а ответственность лежит на человеке. Не «почти готовый результат», не «результат, который надо бегло глянуть», а именно черновик. Агент не подписывает релизы, не отвечает перед клиентом за цифры в отчёте и не будет чинить прод в три часа ночи. Всё это делаете вы, а значит, вы и решаете, что считать готовым.

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

Чем проверять код

• Тесты. Основной инструмент. Существующие тесты должны проходить; на новое поведение должны появиться новые. Просите явно: «прогони тесты и покажи вывод», «напиши тест, который падает на старом коде и проходит на новом».
• Линтеры и статический анализ. Ловят то, что глаз пропускает при чтении диффа: неиспользуемые переменные, подозрительные типы, нарушения стиля.
• Сборка. Код, который не компилируется, — на удивление частый результат «готово!». Сборка перед приёмкой обязательна.
• Запуск. Тесты проверяют то, что в них написано, и только это. Пять минут ручного прогона основного сценария (запустить, нажать кнопку, посмотреть на результат) регулярно находят то, что зелёные тесты пропустили.

Агент сам умеет прогонять все эти проверки, но не всегда делает это без напоминания. Впишите проверку прямо в постановку задачи: «готово = сборка проходит, npm test зелёный, линтер без замечаний». Тогда агент будет гонять проверки в цикле и приносить вам уже прошедший их результат.

Совет

Требуйте показывать реальный вывод команд, а не пересказ. «Тесты проходят» в исполнении модели иногда означает «я считаю, что они должны проходить». Скопированный вывод npm test не врёт.

Чем проверять тексты и аналитику

Для нетехнических результатов проверка не менее важна, просто инструменты другие:

• Факт-чекинг цифр. Каждое число в отчёте агента должно сходиться с источником. Модели уверенно округляют, путают периоды и «восстанавливают» недостающие значения по правдоподобию.
• Проверка ссылок и цитат. Ссылки могут вести в никуда или не на то; цитаты могут быть перефразированы до искажения смысла. Открывайте и сверяйте.
• Сверка с источником. Если агент суммаризировал документ, встречу или переписку, выборочно сверьте два-три утверждения с оригиналом. Типичная ошибка суммаризации — не выдумка, а потеря критичной оговорки: «согласны при условии X» превращается в «согласны».
• Проверка на пропуски. Спросите себя не только «верно ли то, что написано», но и «не пропущено ли важное». Это же можно спросить у агента в новой сессии: «сравни выжимку с исходником и перечисли, что упущено».

Типичные «тихие» дефекты

Опаснее всего не грубые ошибки, а дефекты, которые выглядят как качественная работа:

• Правдоподобный, но неверный код. Аккуратный, с комментариями, с обработкой ошибок, но с перепутанным условием в ключевой ветке. Читается легко, поэтому читается невнимательно.
• Выдуманные API. Агент вызывает метод, которого нет в библиотеке, но который «должен был бы быть» — это галлюцинация в её самой практичной форме. Ловится компиляцией и запуском, а не чтением.
• Удалённые «мешающие» тесты. Стремясь добиться зелёного статуса, агент может ослабить проверку в тесте, замокать проблемное место или удалить падающий тест. Формально задача решена. Всегда смотрите дифф тестов отдельно.
• Заглушки под видом реализации. TODO, захардкоженное значение или return true там, где должна быть логика, при беглом просмотре выглядит законченным.
• Лишние изменения. Попутный «рефакторинг» файлов, которых задача не касалась. Всё, что вне рамок задачи, откатите и при желании оформите отдельно.

Ревью агентского кода строже человеческого

Это контринтуитивно, но важно. Когда ревью присылает коллега, вы знаете: он сам прогнал код, он понимает контекст, ему будет стыдно за халтуру. У агента нет ни репутации, ни смущения, а его текст выглядит увереннее и чище, чем у большинства людей, но гарантии корректности при этом нулевые. Уверенный тон и корректность у моделей не связаны вообще.

Поэтому дифф агента читается с презумпцией виновности: не «выглядит нормально», а «я понимаю каждую строку и знаю, зачем она здесь». Строку, которую вы не можете объяснить, нельзя принимать. Попросите агента объяснить или упростить.

Чек-лист проверки

1. Сборка проходит, тесты зелёные, линтер молчит, и вы видели вывод, а не пересказ.
2. Дифф прочитан полностью; изменений вне рамок задачи нет.
3. Дифф тестов просмотрен отдельно: ничего не удалено и не ослаблено.
4. Основной сценарий прогнан руками.
5. Для текстов: цифры сверены с источником, ссылки открываются и ведут туда, куда заявлено.
6. Нет строк и утверждений, которые вы не можете объяснить своими словами.
7. Краевые случаи из постановки задачи действительно обработаны, а не упомянуты в комментарии.

Осторожно

Чем лучше становятся модели, тем реже они ошибаются, и тем сильнее соблазн перестать проверять. Это ловушка: редкая ошибка в непроверяемом потоке результатов наносит больше вреда, чем частые ошибки под присмотром.

Что дальше

• Безопасность и приватность: вторая половина темы ответственности: данные, секреты и опасные действия.
• Рабочий цикл с агентом: где именно проверка встроена в процесс.