Идея поручить ИИ-агенту написать сложный инструмент с нуля давно перестала быть фантастикой. Но чем масштабнее задача, тем острее вопрос: как заставить агента выдать рабочий код, а не красивую имитацию? Недавний эксперимент, в котором агент реализовывал Pandoc, сравнил несколько подходов к тестированию. Результаты отрезвляют: разница между техниками оказалась небольшой, а привычный TDD не занял первое место. Разберём, что из этого следует для тех, кто использует ИИ в разработке.

Что именно проверяли

Автор эксперимента поставил агенту на современной модели задачу реализовать Pandoc — конвертер документов с большим набором форматов. В каждом прогоне менялось только одно: инструкция о том, как тестировать результат. Всего 25 условий по 25 прогонов, суммарные затраты по розничным ценам — около 90 тысяч долларов. Качество оценивали по скрытым тестам, которые агент не видел.

Ключевая цифра: доля пройденных скрытых тестов колебалась от 40,5% при TDD до 45,1% при дифференциальном тестировании. При этом вариант вообще без указаний по тестированию дал 44,1%. То есть разброс между подходами — единицы процентных пунктов, а «отсутствие стратегии» оказалось в середине. Сам автор честно предупреждает: данных мало, и делать глобальные выводы рано.

Почему TDD не выиграл

Классический TDD предполагает сначала написать тесты, потом код. В контексте ИИ-агента это выглядит логично: тесты задают контракт, агент под него подстраивается. На практике есть нюансы.

  • Тесты пишет тот же агент. Если он неверно понял задачу, тесты закрепят неверное понимание. Получается самообман: код проходит проверку, которую сам же и придумал.
  • Формальные тесты не покрывают крайние случаи. Агент склонен проверять «счастливый путь» и пропускать редкие форматы, битые входные данные, нестандартные кодировки.
  • Дополнительный этап удорожает прогон. Написание тестов — это токены и время, а прирост по скрытым тестам оказался скромным.

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

Что показало дифференциальное тестирование

Дифференциальный подход — сравнение вывода агента с эталонной реализацией на тех же входах. Если эталон есть, это мощный инструмент: он ловит расхождения там, где обычные тесты молчат. В эксперименте этот вариант дал лучший результат — 45,1% против 40,5% у TDD.

Но у метода есть ограничения. Нужен надёжный эталон, а для новых задач его может не быть. Кроме того, сравнение выходов не всегда говорит, почему результат отличается, — приходится разбираться вручную. И всё же как дополнительный слой проверки он себя оправдывает.

Практические шаги для вашей работы

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

  • Пишите ключевые тесты сами. Не отдавайте агенту и постановку задачи, и проверку — иначе он будет оценивать себя по своим же критериям.
  • Комбинируйте подходы. Базовые юнит-тесты от вас, дифференциальное сравнение с эталоном там, где он есть, плюс ручная проверка крайних случаев.
  • Формулируйте критерии приёмки до запуска. Чёткое описание того, что считается правильным результатом, важнее выбора конкретной техники тестирования.
  • Считайте стоимость. Каждый дополнительный этап — это токены. Иногда дешевле прогнать задачу дважды с разными формулировками, чем строить сложную тестовую обвязку.
  • Не доверяйте вирусным выводам. Заголовки вроде «тесты от ИИ доказанно бесполезны» обычно вырастают из одного узкого эксперимента. Проверяйте, на какой задаче и какой модели получены данные.

Типичные ошибки

Самая частая ошибка — воспринимать результат одного прогона как истину. Агент недетерминирован: тот же промпт может дать разный код. Вторая ошибка — экономить на проверке, полагаясь на то, что «модель умная». Третья — путать прохождение тестов с решением задачи: скрытые тесты в эксперименте показали, что даже лучший вариант закрывает меньше половины проверок.

Ещё одна ловушка — переносить выводы с одной задачи на другую. Pandoc — специфичный проект с множеством форматов и краевых случаев. Для простого CRUD-сервиса или скрипта автоматизации соотношение техник может быть совсем другим. Прежде чем строить процесс, прогоните небольшой пилот на своей типовой задаче и посмотрите, где агент ошибается чаще.

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