ИИ-агенты умеют быстро писать код, добавлять тесты и уверенно сообщать, что задача выполнена. Проблема в том, что уверенность агента и зеленый отчет тестов еще не доказывают, что изменение действительно работает.
Ошибку часто находят позже: в собранном пакете, развернутом приложении или сценарии, который не попал в тесты. Код прошел проверку, но проверка отвечала не на тот вопрос.
Проблема: агент проверяет сам себя
Один и тот же агент обычно реализует задачу, пишет тесты и оценивает результат. В такой схеме он склонен подтверждать собственное решение, а не искать способ его опровергнуть.
Даже полностью зеленый набор тестов может не показать:
- какое существующее поведение сломало изменение;
- соответствует ли фактический результат требованиям;
- та ли ревизия была собрана и развернута;
- работает ли код за реальной границей поставки;
- способны ли важные проверки вообще обнаружить ошибку;
- что осталось непроверенным.
Это не означает, что тесты бесполезны. Они дают доказательства только в пределах сценариев, которые действительно выполняют. Главная ошибка — принять эти ограниченные доказательства за подтверждение всей задачи.
Решение: отдельная состязательная роль
Gopnik — навык состязательной проверки для ИИ-агентов. Когда реализация объявлена готовой, он начинает с противоположного предположения: изменение содержит ошибку, и ее нужно найти.
Вместо повторного чтения отчета агента Gopnik формулирует поведение, которое могло сломаться, атакует код внутри репозитория, а затем по возможности проверяет собранную или развернутую ревизию там, где ею пользуются. Он также требует доказать, что важная проверка способна завершиться ошибкой.
Типичный результат выглядит так:
BLOCKER — скидка округляется дважды.
Воспроизведение:
POST /orders с {"discount": 0.1}
Получено: 23.94
Ожидалось: 23.95
Проверенная ревизия: 8f31c2a
Verdict: NOT READY
Вердикт привязан к конкретной ревизии и области проверки. Если нужная среда недоступна, Gopnik сужает вывод и явно перечисляет, что не удалось доказать, вместо того чтобы считать отсутствие данных успехом.
Как это встраивается в работу
В проект входят три связанных навыка:
gopnik-criticпроверяет важное утверждение или предложенное решение до реализации;gopnik-setupвыясняет, как проект можно проверить на самом деле;gopnikатакует уже завершенное изменение.
Это не замена тестам, ревью или ответственности команды за релиз. Это дополнительный независимый проход с другой целью: не подтвердить выполненную работу, а найти основание считать ее незавершенной.
Попробуйте на реальном изменении
Gopnik бесплатный, распространяется по лицензии MIT и не имеет платного тарифа. Установите его, выберите завершенное изменение и попросите агента прогнать навык перед тем, как переводить задачу в Done.
Лучший способ оценить подход — проверить его на задаче, которую ваш агент уже считает готовой, и посмотреть, какие утверждения действительно выдержат попытку их опровергнуть.