Агент написал код. Потом написал тесты. Что именно они доказали?
В худшем случае — что две версии понимания одной задачи не спорят друг с другом. Если и реализацию, и тесты пишет один агент из одного описания, зелёный прогон может подтверждать внутреннюю согласованность, а не пользовательский результат.
Kun Chen недавно показал это в [своём DeepSWE eval](https://x.com/kunchenguid/status/2108030810691629403). Когда Sonnet 5.5 High запретили писать тесты, доля успешных задач оказалась немного выше, но разница не была статистически значимой. Зато агент статистически значимо тратил меньше времени и денег: 58 часов и $278 против 62 часов и $304. В базовом прогоне 65% написанных агентом тестов были модульными, 35% — интеграционными; ни одна из этих групп не дала прироста относительно режима без тестов. Отдельная выборка из 44 задач, где не запускались даже существующие тесты, тоже не показала разницы в доле успешных задач.
Ограничение здесь важнее громкого вывода. В исследовании было всего 17 E2E-тестов против более чем 3000 модульных и интеграционных. Автор отдельно уточнил: это не аргумент «не пишите тесты» и не проверка ценности E2E. Человеческая постановка теста тоже может изменить результат, но в этом эксперименте это не доказано.
У меня есть свежий пример из контура публикации. Адаптер сообщил об успехе, статус стал зелёным, а публичной публикации не появилось. Такая проверка доказала, что команда отработала и внутреннее состояние обновилось. Она не доказала пользовательский исход.
Полный сценарий здесь должен проверять:
1. публикация появилась именно в целевом профиле;
2. опубликован точный принятый материал;
3. получен публичный URL и он открывается;
4. повторный запуск не создаёт дубль.
Это пример того, как я бы сформулировал E2E-сценарий. Такой защиты у этого контура пока нет.
Поэтому в своём методе Test-Driven Product Development (TDPD) я ставлю порядок так:
бизнес-проблема → спецификация → пользовательские сценарии → исполняемые E2E до реализации → код агента → приёмка человеком (UAT).
Модульные и интеграционные тесты всё равно нужны: они помогают быстро понять, где сломалась логика, граница или интеграция. Но даже зелёный E2E может закрепить неверную реализацию, если сам сценарий описывает не тот результат. Поэтому UAT остаётся отдельной проверкой исходного замысла.
Если ваши тесты зелёные, какой наблюдаемый результат пользователя они доказывают — и кто проверил, что проверяется именно он?
Post #1282
106
