Что доказывает зелёный тест: от задачи агента к наблюдаемому результату

AI-агент получил задачу, написал код и тесты, запустил их и вернул зелёный статус. Что теперь известно наверняка?

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

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

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

Почему тест агента может повторить ошибку агента

В октябре 2026 года Kun Chen опубликовал результаты эксперимента с DeepSWE v1.1 и Sonnet 5.5 High. Система выполнила 111 задач в 444 запусках: 222 запуска в режиме, где агенту разрешалось писать тесты, и 222 запуска с прямым запретом писать тесты.

В первой группе успешными были 145 запусков из 222, или 65,3%. Во второй группе — 147 из 222, или 66,2%. Разница в 0,9 процентного пункта в пользу режима без новых тестов не была статистически значимой.

При этом автор сообщил о меньших затратах во второй группе: 58 часов и 278 долларов против 62 часов и 304 долларов. Снижение времени на 6% и расходов на 9% он отметил как статистически значимое.

Сами написанные агентом проверки на 65% состояли из модульных тестов и на 35% из интеграционных. В опубликованной выборке было только 17 end-to-end тестов и более 3000 модульных и интеграционных. Поэтому этот эксперимент не отвечает на вопрос, помогли бы заранее заданные пользовательские E2E-сценарии.

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

Мы не воспроизводили эксперимент и не проверяли полный протокол и исходный набор данных. Числа выше — атрибутированный пересказ опубликованных автором результатов и ограничений. Они не доказывают эффективность какого-либо отдельного метода разработки.

Сначала нужно установить источник критерия

Допустим, в постановке написано: «После отправки формы пользователь должен получить подтверждение».

Агент реализует форму, сохраняет запись и показывает зелёный баннер. Затем пишет тест: заполнить поля, нажать кнопку, дождаться баннера. Тест проходит.

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

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

Для существенного сценария трасса должна начинаться раньше:

источник или решение → правило спецификации → пользовательский сценарий → исполняемая проверка → доказательство реализации → UAT

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

Семь строк карты приёмки

Перед передачей задачи агенту полезно заполнить короткую карту. Она не заменяет спецификацию. Она выделяет условия, без которых исполнитель начнёт угадывать.

Эта карта задаёт семь разных контрактов. Один тест редко покрывает их все. Часть становится автоматическими сценариями, часть проверяется на уровне инфраструктуры и провайдера, часть остаётся человеческим решением.

Четыре вида доказательства, которые часто смешивают

1. Проверка завершённости

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

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

2. Соответствие сценарию

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

Сила доказательства зависит от охвата. Модульный тест хорошо проверяет правило в изоляции. Интеграционный показывает взаимодействие компонентов. End-to-end сценарий наблюдает путь через систему целиком. Ни один уровень не исправляет ошибочный критерий автоматически.

3. Подтверждение внешнего эффекта

Команда отправила запрос во внешний сервис и получила успешный ответ. Это доказывает только то, что описано контрактом ответа.

Иногда достаточно идентификатора созданного объекта. Для публикации нужен более сильный набор: точный профиль, принятый материал, публичный URL, совпадение тела и визуала, отсутствие дубля. Для другого процесса набор будет иным.

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

4. Человеческая приёмка

UAT отвечает на вопрос, относится ли проверенный результат к исходной задаче и можно ли его оставить в работе. Человек сверяет пользовательский исход, существенные ограничения и остаточный риск.

У этой стадии должен быть владелец. Агент может собрать доказательства и показать отклонения. Решение о принятии не возникает из зелёного статуса автоматически.

Ограниченный кейс: зелёное приложение, заблокированный рабочий контур

В одном из наших внутренних прототипов проходили 46 тестов, сборка и CI были зелёными. Проверки покрывали подтверждение опасных действий, повторный запуск без дублей, скрытие секретов и границы драйвера деплоя.

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

Позже статья с разбором этого примера была опубликована в Дзене и получила отдельный канонический факт публикации с публичным URL: «46 тестов зелёные. Почему я всё равно не называю AI-продукт запущенным».

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

Из него нельзя выводить общую надёжность нашего контура или чужих систем. В нём важна только граница утверждения:

• тесты подтверждали заданное поведение приложения;
• драйвер рабочего контура требовал отдельного доказательства;
• публикация статьи требовала собственного внешнего подтверждения;
• UAT оставался решением ответственного человека.

Как TDPD проводит эту границу

Test-Driven Product Development (TDPD) — оригинальный метод Иннокентия Бодрова. Его каноническая последовательность выглядит так:

бизнес-проблема → спецификация → пользовательские сценарии → E2E-тесты до реализации → реализация агентом → приёмка человеком (UAT)

Контроль переносится с построчного просмотра каждой попытки агента на заранее определённый пользовательский результат. Сценарий становится внешней целью для реализации. Пока проверка не проходит, инженерная работа не завершена. После Green остаётся UAT.

Метод оставляет человеку две обязательные точки решения. На входе человек определяет проблему, scope, существенные ограничения и критерий. На выходе он принимает или отклоняет получившийся результат.

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

Поэтому до Input gate нужен Context Baseline: версии важных источников, дата актуальности, принятые решения, открытые блокирующие противоречия. Если существенный источник или решение изменились, связанные сценарии и тесты становятся устаревшими. Прошлый Green нельзя переносить на новый контекст без оценки влияния.

Пример: публикация как пользовательский сценарий

Слабый сценарий публикации звучит так:

> Вызвать команду публикации и получить успешный статус.

Он проверяет внутреннюю операцию. Наблюдаемый пользовательский сценарий требует большего:

1. материал отправлен именно в целевой профиль;
2. опубликована точная принятая ревизия;
3. обязательный визуал совпадает с одобренным;
4. существует канонический публичный URL;
5. URL открывается и показывает ожидаемый материал;
6. повторный запуск не создаёт дубль;
7. факт публикации записан в системе-владельце с идентификатором результата.

Даже этот список не универсален. Для черновика, закрытого сообщества или канала без публичного URL доказательство будет другим. Карта приёмки заставляет назвать различие до реализации.

Что записывать после запуска

Для значимой агентной задачи одного финального ответа мало. Полезная квитанция связывает:

• версию контекста и существенных источников;
• версию спецификации и критерия;
• модель, инструкции, инструменты и политики доступа;
• вызванные действия и внешние эффекты;
• результаты completion и scenario checks;
• известные отклонения и неизвестные состояния;
• решение UAT, владельца и время принятия.

Полная техническая трасса может содержать чувствительные данные. Аудиторская запись не обязана копировать их целиком: достаточно устойчивых идентификаторов, хешей и ссылок на систему-владельца. Цель записи — воспроизводимость решения и его границ.

Наличие трассы тоже не делает результат правильным. Она позволяет выяснить, как система пришла к нему, и отделить ошибку контекста, критерия, реализации, окружения или приёмки.

Практическая проверка перед следующей задачей агента

До реализации:

1. Назовите решение, которое должен поддержать результат.
2. Зафиксируйте версии существенных источников и открытые конфликты.
3. Опишите наблюдаемый исход с точки зрения пользователя.
4. Добавьте пустую, ошибочную, повторную и частично выполненную ветки.
5. Ограничьте действия агента, профиль, среду и допустимый внешний эффект.
6. Определите доказательство для каждого существенного исхода.
7. Назначьте владельца UAT и условия восстановления.

После реализации:

1. Проверьте завершённость результата до оценки качества.
2. Сверьте исполняемые проверки с исходными сценариями.
3. Подтвердите внешние эффекты в системах-владельцах.
4. Сохраните неизвестные состояния как неизвестные.
5. Проведите UAT отдельно от инженерного Green.

Так слово «готово» раскладывается на проверяемые утверждения. Команда видит, где уже есть доказательство, где нужен следующий гейт, а где решение всё ещё принадлежит человеку.

Источники и границы

• Kun Chen: исходная публикация эксперимента и уточнение автора. Числа использованы по owner-verified source pack; полный протокол и исходный датасет AnalystCraft в рамках этой статьи независимо не проверял.
• TDPD Product Framework. TDPD / Test-Driven Product Development — оригинальный метод Иннокентия Бодрова.
• Разбор четырёх состояний релиза, Planner task #1045, accepted revision 4, canonical publication fact #450. Пример ограничен состоянием конкретного прототипа и фактом публикации конкретной статьи.