TGViewer
PRO продукты и системы | Иннокентий Бодров PRO продукты и системы | Иннокентий Бодров @spherical_analyst · 2.62K subscribers
Post #1282 106
Агент написал код. Потом написал тесты. Что именно они доказали?

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

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 остаётся отдельной проверкой исходного замысла.

Если ваши тесты зелёные, какой наблюдаемый результат пользователя они доказывают — и кто проверил, что проверяется именно он?
More from @spherical_analyst
  1. Oct 13, 2026Всем привет, мы в эфире
  2. Oct 12, 2026🔥 Иногда лучший способ улучшить собственный фреймворк — показать его другим аналитикам и…
  3. Oct 11, 2026Почему я всё ещё работаю диспетчером Я собираю систему, которая должна разгружать меня. На…
  4. Oct 8, 2026Сегодня при проверке своей системы управления проектами увидел статус «карта связей устаре…
  5. Oct 7, 2026Анонс стрима "ИИ vs Системный аналитик" 13 октября в 19:00 - стрим «ИИ vs Системный аналит…
  6. Oct 7, 2026Если LLM не ограничить контекстом и критериями, она легко уйдёт в сторону. В коротком фраг…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →