← Все курсы · Все руководства

Как проверить, что агент ИИ действительно выполнил свою работу

Пять проверок, которые показывают, выполнил ли агент ИИ заявленную работу · Часть Analyst Prep Kit

К Майкл Носито, аналитик данных · Обновлено 30 июля 2026 г.

Агент ИИ сообщает вам, что работа завершена. Вот пять проверок, которые покажут, так ли это.

Каждая проверка занимает минуту-две. Каждый смотрит на вещь, которая была доставлена, а не на отчет о ней. Они применяются независимо от того, написал ли агент код, переместил данные или выполнил миграцию.

Вот почему это различие имеет значение. Изучая это руководство, я попросил исследовательского агента опубликовать жалобы на агентов ИИ, которые сообщают, что работа завершена, хотя на самом деле это не так. Он вернул три цитаты, каждая из которых относилась к конкретному общедоступному отчету об ошибке. Я сверил их с источником. Один был настоящим. Двое других нигде не существовали. Они были правдоподобными, хорошо написанными, по теме и придуманными.

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

Как часто это происходит на самом деле

Это не редкое событие, и оно измерено. В препринте 2026 года было проанализировано 20 574 реальных сеанса шести инструментов агента и закодировано 16 118 подтвержденных случаев, когда агент и разработчик разошлись. Примерно 23% из них были агентами, которые неточно сообщали о своей работе, что делает их третьей по величине категорией. Неправильная реализация, на которую все жалуются, была меньше – около 18%.

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

Два отраслевых исследования дают цифры о том, как люди адаптировались. В опросе Сонар, в котором приняли участие 1149 разработчиков, 96% заявили, что не полностью верят в то, что код, сгенерированный ИИ, функционально корректен. Еще 61% согласились, что он «часто создает код, который выглядит правильно, но ненадежен». Переполнение стека опросил 33 244 разработчиков о том, что им больше всего не понравилось. Победителем с 66% стали «Решения ИИ, которые почти верны, но не совсем».

Почти прав – это тяжелый случай. Очевидно неправильное заявляет о себе. Почти правильно проходит каждую дешевую проверку.

Проверка 1: претензия не является доказательством

Перед проверкой вспомните, когда в последний раз что-то говорило вам о завершении. Сборка, скрипт, помощник. Вы это проверили или поверили? Честный ответ обычно — второй, и именно вокруг него построена каждая проверка на этой странице.

Начните с самого простого вопроса и задавайте его при каждом заявлении о завершении: какая команда докажет это, и выполнялась ли эта команда?

Не «пройдёт». Запускался ли он в этом сеансе и что напечатал? Заявление о том, что тесты пройдены, стоит ровно столько же, сколько и результаты теста, находящиеся рядом с ним, и ничего без него.

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

Проверка 2: сообщение об успехе инструмента также не является доказательством

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

Открытый отчет об ошибке в файле документов Клод Код пишет, что оно автоматически усекается или заполняется нулями. Стоит процитировать то, что говорится об обратном чтении файла:

Инструмент чтения не может проверить запись. Он возвращает намерение, а не состояние диска.

выпуск антропики/клауд-кода № 53940, открыт 27 апреля 2026 г.

Журналисты в этом треде увидели, что файл прочитан правильно, хотя байты на диске были неправильными, и решили проверять количество байтов после каждой записи. Вот краткое изложение общего урока: проверьте другой путь, отличный от того, по которому выполнялась работа. Если агент записал файл одним инструментом, проверьте его другим. Прочтите его из оболочки, посчитайте байты, хешируйте, откройте.

Тот же принцип охватывает более тонкую версию проблемы. Если агент работает в одном каталоге, а ваше приложение запускается из другого, изменения могут корректно вноситься, корректно сообщаться, но при этом никогда не достигать исполняемого кода. Ничего не ошибается. Изменения просто не там, где они должны быть.

Проверка 3: зеленый тест дает меньше результатов, если агент может редактировать тест

Пройденный набор тестов является свидетельством выполненных тестов. Это не свидетельство о существовавших ранее тестах.

Измерение здесь резкое. Тест 2025 года намеренно давал моделям задачи, которые тесты не могли быть честно выполнены. В одном варианте ведущая модель использовала тестовые примеры, а не проблему в 76% случаев. Важная половина этого результата — смягчение последствий: уровень эксплуатации падал почти до нуля, когда тесты были скрыты от модели или изолированы от нее. Не тогда, когда модели сказали не изменять. Когда это конструктивно не могло.

Вы можете увидеть такое же поведение в дикой природе. Самый старый отчет об этом на трекере Клода Кода датируется мартом 2025 года и описывает, как его попросили пройти все тесты:

он просто обновил файл делать, чтобы запускать только те тесты, которые прошли успешно. Они назвали это «тестами безопасности».

выпуск № 319 по антропике/клауд-коду, открыт 4 марта 2025 г.

Задача выполнена, как и было заявлено. Все проведенные тесты пройдены. А отдельное исследование более 1,2 миллиона коммитов, проведенное в 2026 году, показало, что тестовые коммиты, созданные агентами, больше опираются на макеты, чем на человеческие: 36% против 26%. Авторы осторожно заявляют, что более частое использование макетов само по себе не является доказательством худших тестов.

Так что проверка — это счет, а не чувство. Сколько тестов было до этого сеанса и сколько сейчас? Если число уменьшилось или появились новые маркеры пропуска, это первое, на что следует обратить внимание, и чтобы это узнать, достаточно одной команды.

Проверка 4: прокси не является границей доставки

Лично мне это стоило больше всего, пока я не научился его проверять.

Изменение можно зафиксировать, отправить, протестировать, но при этом оно не будет реализовано. Я объявил, что работа будет выполнена благодаря чистому толчку. Развертывание незаметно провалилось, поэтому сайт продолжал обслуживать предыдущую версию до тех пор, пока я считал иначе. Коммит был реальным. Толчок был реальным. То, что на самом деле увидит пользователь, не изменилось.

Кто-то другой пришел к тому же уроку с другой стороны и записал его более кратко, чем я:

Программное тестирование не равнозначно проверке приложения в реальном времени.

выпуск антропики/клауд-кода № 47247, открыт 13 апреля 2026 г.

У каждого вида произведения есть граница, за которой оно перестает быть описанием и становится самой вещью. Найдите свой и проверьте там:

• Веб-сайт: извлеките действующий URL-адрес с помощью средства очистки кеша и найдите в ответе строку, которая существует только в этом изменении.
• Число в отчете: пересчитайте по первоисточнику, а не по сводной таблице, составленной агентом.
• Изменение данных: запросите количество строк с обеих сторон и согласуйте их, вместо того, чтобы доверять собственному журналу преобразования.
• Установленное приложение: запускайте установленную копию, а не исходное дерево.
• Опубликованный пакет: установите его из реестра в пустой каталог.

Проверка 5: шлюз, в который агент может писать, не является шлюзом.

Это самая глубокая версия проблемы и самая последняя. Именно это делает проверку структурным вопросом, а не вопросом, требующим более жестких вопросов.

Разработчик создал автоматическую проверку, которая предотвращала завершение сеанса, пока работа еще открыта. Это разумный дизайн. Вот что произошло, согласно отчету:

модель отложила ошибку, которую она уже диагностировала и могла исправить в тот же ход, зарегистрировала ее как «открытый элемент для будущего сеанса», а затем написала собственный файл обхода стоп-хука пользователя (touch ~/.claude/.allow-stop), чтобы завершить поворот, самосертифицированное завершение вокруг ограждения, специально построенного для предотвращения этого.

ограждение завершения, которое доверяет самоаттестации модели, не имеет зубов против модели, желающей написать обход. Модель одновременно определила «готово» и очистила ворота.

выпуск антропики/клауд-кода № 80700, открыт 23 июля 2026 г.

Это не единичный недостаток конструкции. В отдельном отчете описывается, как агент прошел проверку перед фиксацией, используя --no-verify, тайник и тихие флаги. Шесть последовательных коммитов были выполнены в то время, когда тесты проваливались, и все шлюзы были «тихо обойдены».

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

флаг должен иметь возможность только поднимать требование одобрения, никогда отказаться это.

клин / клин выпуск №12020, открыт 1 июля 2026 г.

Это правило проектирования, и оно распространяется далеко за пределы программного обеспечения. Решение о том, выполнена ли работа, не должно быть чем-то, что работник может редактировать. Если ваш контрольный список находится в файле, в который агент может писать, это рекомендация. Если вы определяете готовность как предложение, которое производит агент, то это предложение.

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

Полное до и после

Та же работа, тот же сеанс. Разница в том, что читатель может подтвердить, не переделывая.

До

Done. I implemented the reconciliation check, fixed the failing
test, and verified everything works. All tests pass. The change
is live.

Четыре заявления, ноль доказательств, и каждое из них можно проверить менее чем за минуту. «Проверено, все работает» — самое слабое предложение в абзаце, поскольку оно вообще не содержит проверки.

после

Implemented the reconciliation check.

Tests:      npm test  ->  exit 0,  41 passed, 0 failed
            Test count before: 41.  After: 41.  No skips added.
Wrote:      src/reconcile.js  ->  wc -c = 4,812 bytes on disk
            (checked from the shell, not read back through the editor)
Deployed:   curl -s "https://example.com/?cb=$RANDOM" | grep -c "reconcile-v2"
            -> 1   (marker from this change is being served)

Not verified: behaviour on empty input. No test covers it and I
did not add one.

В каждой строке указывается команда, ее вывод, а также то, что этот вывод делает, а что нет. Особенно обратите внимание на последний раздел. Отчет, в котором указываются собственные пробелы, заслуживает большего доверия, чем тот, в котором ни один из них не упоминается. В длительной работе отсутствие «непроверенного» раздела само по себе является небольшим предупредительным знаком.

Подписи, которые стоит знать

Почему это происходит

Здесь стоит быть точным, потому что популярная формулировка заключается в том, что агент ведет себя нечестно, и эта формулировка приводит к неправильному решению.

Эти системы обучены на основе сигналов, которые вознаграждают результаты, которые выглядят завершенными. Исследование 20 574 сессий напрямую связывает этот шаблон с сигналами вознаграждения, которые способствуют правильности кода, придавая при этом меньший вес соблюдению ограничений и честному самоотчету. В собственном отчете одного агента о таком поведении оно описывается как «градиент обучения, а не принцип», и это справедливо. Это справедливо независимо от того, какое намерение вы хотите в это вложить.

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

Это приводит к принципу дизайна, на котором основано все руководство. Проверка работает, когда она не зависит от сотрудничества проверяемой вещи. Это не новая идея. Вот почему аудиторы не работают в отделе, который они проверяют. Вот почему человек, который считает кассу, не является тем, кто ею управляет. И именно поэтому тест, который вы можете редактировать, не является тестом.

Использование этого в своей работе

Представьте себе последнюю вещь, которую агент создал для вас и которую вы отправили, не открывая. Что бы вы проверили в первую очередь, если бы открыли его сейчас? Что бы вам ни пришло на ум, это ваша самая ценная проверка, и именно с нее вам следует начать приведенный ниже список.

Аудит всего — не цель, и вы остановитесь в течение дня. Вместо этого сделайте это примерно в следующем порядке:

1. Запросите команду и ее вывод один раз. Добавьте «покажите мне команду, которую вы выполнили, и что она напечатала» к тому, как вы запрашиваете работу. Эта одна привычка улавливает большую часть этого и ничего не стоит.
2. Узнайте границу доставки и проверьте ее вручную несколько раз. Какой бы ни была ваша работа, найдите место, где она станет реальной, и посмотрите на нее. Делайте это вручную, пока не будете точно знать, как выглядит настоящий успех.
3. Подсчитайте свои тесты до и после сеанса. Одна команда. Если нужно, запишите номер где-нибудь.
4. Уберите самый важный чек из зоны досягаемости агента. Выберите одну вещь, которая должна быть правдой, и сделайте ее проверку тем, что вы запускаете, а не тем, что она сообщает. Только один для начала.
5. Спросите то, что не было проверено. Явный запрос пробелов дает вам гораздо более полезный ответ, чем вопрос, все ли работает, потому что на второй вопрос есть простой ответ, а на первый нет.

Если вы начинаете что-то новое, а не проверяете существующее, решите, что будет считаться доказательством, прежде чем начнется работа. Записав это в первую очередь, вы меняете запрос, обычно к лучшему, и это означает, что никому не придется обсуждать определение выполненного постфактум.

Шпаргалка

В одном я искренне не уверен и хотел бы узнать опыт других людей. Я подскажу, что проверки, которые стоит автоматизировать, — это скучные механические проверки: подсчет строк, подсчет тестов, сравнение байтов, получение URL-адреса. Они дешевы и с ними невозможно спорить. Но неудачей, которая стоила мне больше всего времени в этом месяце, была сфабрикованная котировка, которую не выявила бы никакая механическая проверка. Только обращение к источнику помогло. Где вы нашли грань между тем, что стоит автоматизировать, и тем, что еще нужно посмотреть?

Все на этой странице представляет собой контрольный список, который вы выполняете вручную. Докажи это это тот же метод, что и система, которую ваш агент запускает сам на себе: восемнадцать правил с ошибкой за каждым, два хука, которые блокируют ложное «он живой» вместо вежливого запроса, и протокол шести препятствий, который заставляет его сообщать, где человек заблудился. Докажите это, $49 →

Ссылки

Все три статьи ниже являются препринтами arXiv. На момент написания ни одна из них не содержала ссылки на журнал или поддающийся проверке DOI, поэтому ни одна из них не упоминается как рецензируемая. Идентификаторы даны, чтобы вы могли прочитать их самостоятельно.

• Тан Н., Чен К., Сюй Г., Ши Ю., Хуан Ю., Макмиллан К., Донг Т. и Ли Т.Дж.-Дж. (2026). Как агенты кодирования подводят своих пользователей: крупномасштабный анализ несовпадения разработчика и агента в 20 574 реальных сеансах. Препринт arXiv arXiv: 2605.29442.
• Чжун З., Рагунатан А. и Карлини Н. (2025). НевозможноСкамейка: измерение склонности студентов магистратуры к использованию тестовых примеров. Препринт arXiv arXiv:2510.20270.
• Хора А. и Роббс Р. (2026). Генерируют ли агенты кодирования переработанные тесты? Эмпирическое исследование. Препринт arXiv arXiv: 2602.00409.
• Сонар (2026). Отчет об опросе разработчиков кода о состоянии. п = 1149. Примечание. Полевые исследования проводились в октябре 2025 года, и издатель продает инструменты, обеспечивающие качество кода.
• Переполнение стека (2025 г.). Опрос разработчиков 2025 года: раздел искусственного интеллекта. н = 33 244 по вопросам точности.
• Публичные отчеты об ошибках, цитированные выше, каждый из которых перед публикацией сверяется со своим источником: проблемы антропики/клауд-кода № 319, № 47247, № 53940, № 80700; Клайн / Клайн, выпуск № 12020.