«Тесты прошли», — сказал агент. Как я перестал верить ИИ на слово

Я не программист по профессии. Пятнадцать с лишним лет я занимаюсь платным трафиком и аналитикой, сейчас работаю Head of Growth. Код в моей жизни появился из практической нужды: выгрузки из рекламных API, n8n-воркфлоу, серверная передача конверсий.

Раньше на такие задачи приходилось ждать разработчика неделями. Теперь я пишу их сам вместе с ИИ-агентами в терминале. Это и есть вайб-кодинг в чистом виде: описываешь задачу словами, агент читает репозиторий, правит файлы, запускает команды и рапортует. Скорость поражает. Но довольно быстро выясняется неприятная вещь: о результате ты узнаёшь из отчёта самого агента. А отчёт пишет языковая модель. Эта заметка не про конкретный инструмент. Она про привычки, которые я выработал, чтобы агент доказывал, что его код работает, а не просто это сообщал. Всё ниже можно применить с любым агентом. Первое, что приходится принять: фраза «всё работает, тесты зелёные» ничего не значит сама по себе. Типичные варианты того, что за ней стоит: Отсюда правило номер один: тесты я запускаю сам или читаю их вывод целиком, а не пересказ. Если агент пишет «2 теста упали, но это не связано с задачей», я хочу видеть, какие именно и почему. Правило номер два: результат проверки привязан к конкретному коду. Не «тесты прошли», а «тесты прошли на коммите такой-то и на таком-то состоянии файлов». Если после проверки поменялся хоть один файл, проверка считается устаревшей. Самая простая версия на коленке: Неидеально, но уже лучше, чем ничего: грязное дерево не даёт выдать проверку за чистую. Тут есть ловушка, которую я хорошо запомнил по журналу ошибок одного из своих проектов. Агенту нужно было доказать, что серия прогонов шла на одном и том же дереве файлов. Он записывал git rev-parse HEAD плюс git status —porcelain в начале и в конце. Значения совпали. Отлично? Нет. Независимый ревьюер показал, что значение не меняется и при реальном изменении содержимого: между прогонами в файл с тестами добавился новый тест. git status —porcelain сообщает пути и статус, но не байты. Контроль выглядел как проверка свойства, но проверить его не мог. Вывод, который записан в проекте: прежде чем доверять самодельной проверке, прогони её на заведомо плохом случае. Сломай ровно то, что она должна ловить, и убедись, что она сработала. Если проверка молчит на явной поломке, это не проверка, а декорация. Следующая проблема тоньше. Одна и та же модель пишет код и потом «делает ревью». У автора и у ревьюера одинаковые слепые пятна, поэтому такое ревью находит опечатки, но пропускает ровно то, что модель не понимает. Честно скажу, что это не панацея. Если ревьюер из того же семейства моделей, что и автор, изоляция уменьшает общие слепые пятна, но не убирает их. Зато бывает и обратное: ревьюер оказывается прав, а «автор» спорит. В журнале ошибок есть запись, где агент-исполнитель насчитал 352 элемента в рабочей копии, ревьюер в чистом клоне — 346. Исполнитель решил, что ревьюер ошибся. Прав оказался ревьюер, и это подтвердил CI-раннер. Урок: если измерения расходятся, перемеряй в свежем клоне, а не защищай свою цифру. Агенты обожают писать тесты, которые повторяют реализацию. Покрытие растёт, уверенность — нет. Тест проверяет, что функция делает то, что она делает. Лекарство, которое реально работает,…

Источник: ixbt.com — www.ixbt.com/live/sw/testy-proshli-skazal-agent-kak-ya-perestal-verit-ii-na-slovo.html