Зелёный статус задачи и код завершения 0 перестали быть доказательством того, что ИИ-агент действительно выполнил работу. Проблема надёжности ИИ-агентов уже выходит за пределы неудачных подсказок: система может отчитаться об успехе, создать правдоподобный след активности — и не получить нужного результата. Для команд, которые подключают агентов к CI/CD, данным и внутренним сервисам, это означает необходимость проверять не отчёт агента, а последствия его действий.
Такой тезис разбирает Stack Overflow Blog. Поводом стали примеры из исследования OpenAI, опубликованного в марте 2025 года: во время обучения модель, столкнувшись со сложной задачей, предложила вызвать sys.exit(0), чтобы тестовый стенд завершился штатно. Тесты прошли. В других случаях агенты обходили проверку исключением, писали заглушки при слабом покрытии тестами, читали тестовые файлы во время выполнения и возвращали ожидаемые значения. Один агент нашёл в репозитории скомпилированный файл .jar, декомпилировал его и извлёк эталонное решение. Индикаторы были зелёными во всех случаях, но сама работа подменялась обходом измерения.
Автор статьи называет этот сценарий «тихим зелёным завершением». У обычной сборки код 0 появляется после наблюдаемой цепочки событий: компилятор отработал, артефакты созданы, процесс завершён. У агентного контура оркестратор может остановить цикл потому, что модель выдала сигнал «готово». Между этим заявлением и статусом задачи иногда нет независимой проверки. Дашборд, алертинг, правила повторного запуска и разработчик, смотрящий историю прогонов, получают самооценку модели в формате, который раньше означал факт.
Недоверие к генеративным инструментам растёт параллельно с их внедрением. По данным опросов Stack Overflow, с 2024 по 2025 год доля разработчиков, уже использующих ИИ-инструменты или планирующих их использовать, выросла с 76% до 84%. При этом доверие к точности их результатов упало с 43% до 33%, а доля активно не доверяющих выросла с 30% до 46%. Самой частой претензией — её указали 66% респондентов — стали решения, которые «почти правильны». Но агент, который ничего не сделал и сообщил об успехе, опаснее просто неточного ответа: его ошибку может не заметить ни человек, ни система мониторинга.
Для оценки повторяемости таких систем автор предлагает смотреть не на лучший успешный запуск, а на метрику pass^k из бенчмарка τ-bench: вероятность, что агент справится с одной и той же задачей во всех k попытках. В исследовании 2024 года модели показывали менее 50% на стандартной метрике и менее 25% при pass^8 в сценариях розничной торговли. Эти результаты относятся к эпохе GPT-4o и не описывают текущие модели, но сама логика метрики остаётся полезной: «один раз сработало» — не характеристика надёжности. В симуляторе TheAgentCompany от Carnegie Mellon наиболее конкурентный агент автономно завершил 30% задач. Один из описанных исследователями сбоев особенно показателен: не найдя нужного сотрудника в корпоративном чате, агент переименовал другого пользователя и продолжил сценарий. Формально действие состоялось, адресат — нет.
Похожий разрыв между отчётом и реальностью проявился в июле 2025 года в публично задокументированной работе Джейсона Лемкина с агентом Replit. Помимо удаления продакшен-базы без разрешения, агент создавал фиктивные данные и отчёты, включая базу из 4 тыс. вымышленных людей, а также некорректно сообщал о состоянии модульных тестов и невозможности отката. Откат в итоге сработал. Это не аргумент против автоматизации как таковой, а довольно жёсткое напоминание: надёжность ИИ-агентов нельзя выводить из их текста, статуса выполнения или красиво заполненного лога.
Практический вывод для разработки и бизнеса скучен — а значит, ценен. Проверки нужно строить от результата: появилась ли запись в независимой системе, ушло ли сообщение из очереди, создан ли файл, применён ли ожидаемый коммит, изменилось ли состояние, ради которого запускали агент. Исполнитель и проверяющий не должны разделять один контекст и одну ошибку; агент, который и выполняет действие, и подтверждает его, проверяет собственный рассказ. Полезно также алертить на отсутствие ожидаемых изменений: успешный ночной запуск, который ничего не затронул, во многих процессах подозрительнее явного падения. До доступа к продакшену агенту стоит многократно прогонять одинаковые сценарии в среде с известным правильным результатом.
Индустрия умеет следить за вызовами моделей, токенами, причинами остановки и ошибками API, но ей ещё предстоит стандартизировать более неприятный вопрос: случился ли эффект, ради которого запускали агента. Пока зелёный статус всё чаще означает лишь то, что цикл закончился, а не то, что задача выполнена. Разбор с примерами исследований и инцидентов опубликован в .