Риск зеленых тестов: AI-агент прошел проверки, но не решил задачу

Самый спокойный момент в AI-assisted development часто оказывается самым опасным: агент принес PR, проверки зеленые, в описании все выглядит логично.

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

Но зеленые тесты доказывают только одну вещь: выбранные проверки прошли. Они не доказывают, что агент решил исходную бизнес-задачу.

Под coding agents я имею в виду инструменты, которые уже не просто подсказывают код, а читают репозиторий, строят план, меняют файлы, запускают проверки и собирают PR.

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

Тест может быть полезным. Проверка может быть корректной. PR может быть аккуратным. И все равно результат может не отвечать на вопрос, ради которого задача появилась.

Я называю это ложной приемкой.

Что кажется происходящим

Команда дает агенту задачу:

"Закрой экспорт отчетов для пользователей на бесплатном тарифе."

Агент находит компонент кнопки Export, добавляет проверку тарифа, обновляет UI-тест, запускает проверки и приносит PR.

Снаружи все выглядит нормально:

- кнопка скрылась;
- тесты зеленые;
- diff небольшой;
- описание PR понятное;
- агент ничего явно не сломал.

Если смотреть только на техническую проверку, работа похожа на завершенную.

Но продуктовая задача была не "спрятать кнопку". Продуктовая задача была "пользователь бесплатного тарифа не должен получить экспорт отчета".

Это уже другой уровень проверки.

Что зеленые тесты не доказывают

Зеленые тесты не отвечают на все вопросы, которые важны для результата.

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

Они не доказывают, что проверен негативный сценарий.

Они не доказывают, что ограничение работает не только в UI, но и на backend.

Они не доказывают, что старые платные пользователи не потеряли доступ.

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

В этом и ловушка: проверка может быть настоящей, но проверять не то.

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

Для бизнеса неполная проверка опасна тем, что создает ощущение завершенности.

Где появляется стоимость

Проблема не в том, что тесты плохие.

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

Так появляются дорогие ошибки:

- фича вроде бы закрыта, но через API все еще доступна;
- баг вроде бы исправлен, но только для удобного сценария;
- ограничение вроде бы работает, но ломает соседнюю группу пользователей;
- PR вроде бы принят, но QA находит расхождение с исходной задачей;
- задача вроде бы завершена, но product lead не может объяснить, какой результат реально проверен.

Здесь AI не создает новую категорию проблемы. Он ускоряет старую: команда и раньше могла спутать "тесты прошли" с "задача решена".

Разница в том, что агент делает это быстрее и увереннее.

Пример

Плохо:

"Закрой экспорт отчетов для free users."

Что может сделать агент:

- скрыть кнопку Export в интерфейсе;
- обновить UI-тест;
- проверить, что кнопки нет на странице;
- написать, что экспорт закрыт.

Почему этого мало:

- прямой запрос к backend может все еще отдавать отчет;
- старый открытый экран может сохранить действие;
- платный пользователь может попасть под слишком широкое условие;
- сообщение в интерфейсе может не объяснять, почему экспорт недоступен;
- в задаче может быть бизнес-правило про trial, которого агент не увидел.

Лучше:

Пользовательский результат: Пользователь на бесплатном тарифе не может получить экспорт отчета ни через UI, ни через прямой запрос.

Сценарии проверки: Free user не видит действие Export. Free user получает отказ при прямом запросе к backend. Paid user сохраняет доступ к экспорту. Trial user проверяется отдельно, если у него есть особое правило.

Что не считается достаточным: Только скрытая кнопка. Только зеленый UI-тест. Только краткое описание агента.

Решение о приемке: Результат принимается не по факту зеленых тестов, а по прохождению пользовательских сценариев.

Такой формат не делает тесты ненужными. Он возвращает им правильное место.

Тесты помогают доказать конкретную проверку. Но сначала команде нужно понять, какую именно проверку надо доказать.

Минимальная рамка проверки AI PR

Перед тем как принимать PR от агента, я бы задавал не вопрос "прошли ли тесты".

Я бы задавал другой вопрос: "что именно эти тесты доказывают?"

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

2. Негативный сценарий Что проверить: кому результат должен быть недоступен, запрещен или отклонен. Плохой сигнал: проверен только happy path.

3. Соседний пользователь Что проверить: кто не должен пострадать от изменения. Плохой сигнал: условие стало шире, чем задача.

4. Уровень системы Что проверить: где реально должно действовать правило - UI, backend, права доступа, данные или интеграция. Плохой сигнал: проверка есть только на самом удобном уровне.

5. След проверки Что проверить: понятно ли из PR, какие сценарии агент проверил и чем это подтверждено. Плохой сигнал: есть только фраза "проверки прошли".

6. Решение о приемке Что проверить: кто смотрит на результат с точки зрения задачи, а не только diff. Плохой сигнал: PR принят потому, что не сломал существующие тесты.

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

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

Какие тесты особенно легко вводят в заблуждение

Не все зеленые проверки одинаково полезны.

Самые рискованные случаи:

- тест проверяет то, что агент сам только что добавил;
- тест повторяет реализацию, а не пользовательский сценарий;
- проверен только happy path;
- проверка проходит на mock-данных, где нет реального ограничения;
- тест не покрывает роль, тариф, права доступа или состояние пользователя;
- проверка не связана с исходной формулировкой задачи;
- PR содержит много изменений, а тест проверяет только маленький удобный кусок.

В таких случаях зеленый статус успокаивает, но не дает достаточной уверенности.

Для инженерной команды это не повод отказаться от AI. Это повод перестать принимать зеленые проверки как финальный ответ.

Что смотреть вместо "проверки прошли"

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

Полезные сигналы:

- Доля PR, где проверен исходный пользовательский сценарий.
- Доля PR, где есть негативный сценарий.
- Доля PR, где проверено, что соседние пользователи не пострадали.
- Количество возвратов из QA из-за неверной трактовки задачи.
- Количество случаев, где тесты были зелеными, но продуктовая приемка не прошла.
- Доля PR, где ревьюер понимает, что именно доказали проверки.

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

Зеленый PR может быть полезным сигналом. Но он не должен быть единственным основанием для приемки.

Где подход не работает

Эта рамка может быть избыточной для простых механических изменений.

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

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

Она не заменяет продуктовую ясность. Если команда не понимает, какой пользовательский результат нужен, агент не угадает это надежно.

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

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

Вывод

Зеленые тесты - хороший сигнал. Но это не финальный ответ.

В AI-assisted development лучше явно разделять три вещи:

- код изменился;
- проверки прошли;
- исходная задача решена.

Первые два пункта может быстро показать агент. Третий остается ответственностью команды.

Если этого не разделять, команда получает не ускорение, а красивую иллюзию контроля: PR зеленый, задача закрыта, а реальный пользовательский результат никто не проверил.

Где у вас чаще всего ломается эта связка: тесты зеленые, а задача на самом деле не решена? Интересно собрать реальные failure modes в комментариях.