Представим агента, которому поручили написать декодер Zstd по RFC. Ему можно дать только задачу, добавить инструкцию использовать TDD, генеративное тестирование или формальные методы либо попросить сравнивать несколько реализаций. Кажется, такие подсказки должны помочь. Но в эксперименте иногда происходило обратное: агент выполнял бесполезную работу в нужной библиотеке или сводил сложную технику к набору поверхностных тестов.

Dan Luu проверил это на трёх задачах разного масштаба: реализации Zstd и IMAP по спецификациям, а также на более крупной задаче Pandoc. Это не рецензированная статья и не препринт, а авторская экспериментальная запись в блоге. Полный первичный текст доступен на странице эксперимента с GPT-6 Astra, а методика первоначального сравнения GPT-5.6 Sol описана отдельно в записи об агентном тестировании. Русский пересказ опубликован на Хабре.

Что именно сравнивали

В исходном сравнении для Zstd проверили 26 условий. Среди них были TDD, дифференциальное тестирование, фаззинг, тестирование на основе свойств, QuickCheck и Proptest, встроенные тесты Rust, библиотеки формальной верификации и режим Default без специальных инструкций. В каждом случае агент должен был реализовать декодер по RFC, не видя тестов, по которым затем оценивали результат.

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

В эксперименте с GPT-5.6 Sol каждое условие для Zstd запускали 80 раз. Для IMAP автор также указывает 80 прогонов на условие. Для Pandoc из-за стоимости оставили 25 прогонов, а общая сумма по розничным тарифам составила около 90 тысяч долларов. В Zstd и IMAP основной метрикой была доля прогонов, где агент прошёл все скрытые тесты. В Pandoc после примерно 14 ходов ни одно условие не достигло полной корректности, поэтому считали долю пройденных тестов.

Такой дизайн проверяет не «лучшую технику тестирования вообще», а конкретную связку модели, оболочки, промпта, библиотеки, задачи и числа итераций. Как и в других оценках ИИ, здесь важно заранее связать вопрос, метод и вывод, а не читать одну итоговую цифру вне контекста. Практический разбор такой связи есть в материале о том, почему научному ИИ мало находить закономерности и нужно проверять гипотезы.

Zstd: когда тест не различает методы

Для GPT-6 Astra задача Zstd оказалась слишком лёгкой в выбранном режиме. Автор пишет, что «почти каждое условие почти каждый раз» давало 100% корректности на уровне medium. В другом месте он приводит более точную оценку: агент тратил около одного доллара и проходил все скрытые тесты более чем в 99% случаев.

Этот результат говорит о способности модели решать именно данный бенчмарк, а не доказывает равенство техник. Если почти все условия упираются в верхнюю границу метрики, различия между ними скрываются из-за насыщения. Бенчмарк перестаёт отвечать на вопрос «какой метод лучше», потому что задача уже не различает методы.

При этом автор заметил различия в поведении агентов. GPT-5.6 Sol при просьбе о фаззинге часто создавал случайные входы, которые проходили по одним и тем же путям отказа. Astra чаще строила структурированные входы и находила нетривиальные ошибки. Но изменение поведения не обязательно означает рост корректности: на насыщенной задаче Zstd это нельзя было надёжно измерить.

В первоначальном сравнении GPT-5.6 Sol дифференциальное тестирование оказалось одним из слабых условий. В идеале две независимые реализации получают одинаковые входы, после чего сравниваются их результаты. На практике ни один агент не создал две полноценные независимые реализации. В 135 из 160 прогонов появлялось что-то похожее на дифференциальное тестирование, но обычно агент дважды воспроизводил почти один и тот же способ решения и мог повторить одну ошибку.

С тестированием на основе свойств происходило примерно то же. QuickCheck часто сводился к нескольким простым дымовым проверкам, а полностью случайные входы для Zstd в основном попадали в очевидные ветви обработки некорректных данных. Proptest выглядел лучше: механизм shrinking, который сводит найденный сбой к более простому входу, иногда приносил пользу. Но это наблюдение относится к конкретной связке Proptest, модели и задачи, а не ко всему классу методов.

IMAP: Default остаётся конкурентоспособным

На IMAP верхней границы уже не было. Это более сложный протокол, поэтому результаты сильнее различались. Default снова выглядел достаточно хорошо. Некоторые специальные условия давали немного большую долю полностью успешных прогонов, но требовали больших затрат.

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

IMAP важен ещё по одной причине. Специальная инструкция не гарантировала выигрыша даже там, где задача была достаточно трудной, чтобы различать условия. Но это не значит, что Default универсально лучше. 80 прогонов на условие дают информацию о конкретном эксперименте, а не обо всех протоколах и моделях.

Pandoc: различия появляются, но уверенности мало

Pandoc был заметно труднее. В модифицированной задаче ProgramBench агентам показывали материалы и видимые тесты, а качество затем оценивали и по скрытым тестам. После примерно 14 ходов ни одно условие не достигло 100% корректности, поэтому автор сравнивал долю пройденных тестов и накопленную стоимость.

На Pandoc многие условия выглядели лучше Default. По наблюдению Luu, дифференциальное тестирование заставляло агентов внимательнее разбирать граничные случаи. В его формулировке, переведённой на русский, такая проверка побуждала агентов исследовать тесты и инварианты и лучше разбираться в границах, чтобы написать тесты, которые правильно проверяют обе стороны перехода. Автор считает, что это помогало и при написании самого кода.

Но слово «помогало» здесь описывает авторскую интерпретацию механизма, а не отдельно проверенную причинность. В Pandoc каждое условие запускали всего 25 раз. Агентный цикл зависел от траектории: небольшая случайность на одном ходе меняла код, последующие тесты и дальнейшие решения. Поэтому заметное различие между условиями могло сочетать эффект метода со случайностями конкретных траекторий.

TDD в этих сравнениях снова оказался среди слабых условий. Инструкция действительно меняла поведение: агенты писали примерно вдвое больше тестов, а в 67 из 160 прогонов у них появлялись падающие тесты ещё до существенной реализации. В Default таких случаев не было. Однако это не было полноценным человеческим TDD. Сам автор отмечает, что сторонник метода, вероятно, не назвал бы такую работу настоящим TDD.

Большее число тестов не означало лучшего покрытия трудных случаев. В Zstd агенты с инструкцией TDD чаще ошибались при проверке режима с четырьмя потоками Huffman, хотя писали больше тестов общего случая. В некоторых тестах все четыре потока делали одинаковыми, поэтому ошибка перестановки потоков оставалась незаметной. Число тестов нельзя подменять их диагностической ценностью.

Что можно считать результатом

Автор формулирует вывод осторожно: «Мы можем видеть, что некоторые условия работали лучше других, но трудно понять, что это значит». В другой записи он говорит ещё короче: «У меня недостаточно данных, чтобы сказать, какие условия в целом лучше».

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

  • На задаче Zstd, простой для сильной модели, метрика почти достигла насыщения и плохо различала методы.
  • На IMAP Default оставался конкурентоспособным, а возможный выигрыш специальных условий сопровождался большими расходами.
  • На Pandoc разные условия давали заметно различающиеся траектории, но ни одно не стало убедительным победителем.
  • TDD менял процесс работы агента и в этих сравнениях дал слабый результат, однако причина этого не установлена.
  • Proptest и некоторые другие варианты тестирования на основе свойств иногда давали полезные проверки, особенно благодаря упрощению найденных контрпримеров.
  • Дифференциальное тестирование сработало по-разному. В Zstd агенты обычно применяли его формально, а в Pandoc автор увидел более содержательный анализ границ.

Это различие особенно важно. Результаты Zstd и Pandoc не опровергают само дифференциальное тестирование. Они показывают, что эффект техники зависит от задачи и от того, смог ли агент понять её смысл, а не только воспроизвести названную в промпте процедуру.

Почему 90 тысяч долларов не превращают эксперимент в окончательный ответ

Большая сумма впечатляет, но статистическая сила зависит не только от бюджета. Для Pandoc было 25 прогонов каждого условия и одна задача соответствующего масштаба. Автор сам перечисляет нерешённые вопросы: как изменится результат после большего числа ходов, какая доля вариации связана с малой выборкой, как влияют небольшие изменения формулировки промпта и насколько Pandoc представляет другие крупные задачи.

Есть и проблема независимости наблюдений. Если следующий ход агента зависит от кода, созданного на предыдущем шаге, 14 ходов одной траектории не равны 14 независимым попыткам. Это не делает эксперимент бесполезным, но ограничивает простое толкование средних значений и доверительных интервалов. Luu прямо предупреждает: настоящая неопределённость, по его мнению, шире, чем показывают бутстрэп-интервалы на графиках.

Полный массив исходных данных, код эксперимента и все детали интерактивных графиков не опубликованы в удобном для проверки виде. Кроме того, автор признаёт, что это «быстрый игрушечный» проект и что при проверке подобных оценок почти всегда обнаруживаются дополнительные проблемы. Поэтому перед нами наблюдательное сравнительное исследование в блоге, а не стандартизированная рецензированная работа.

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

Практический вывод скромнее вирусного тезиса «ИИ-тесты бесполезны». Данные не подтверждают ни универсальную пользу, ни универсальный вред тестов, написанных агентами. Они показывают, что Default иногда оказывается сильной отправной точкой, специальные методы иногда дают преимущество, а сравнивать их нужно на скрытых тестах, учитывая стоимость, зависимость от траектории и переносимость на другие задачи.

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

Источники

  1. Dan Luu. Test and verification technique effectiveness with GPT-6 Astra. Авторская экспериментальная запись в блоге, полный текст.
  2. Dan Luu. How well do agents use test and verification techniques?. Авторская запись с описанием первоначального сравнения Zstd и IMAP.
  3. opium. Прогнал агента на $90 тысяч с разными техниками тестирования: TDD снова в хвосте. Русский перевод и обзор оригинальной записи Dan Luu на Хабре.
Схема показывает, почему результаты техник тестирования нельзя превращать в универсальный рейтинг: на Zstd различия скрывает насыщение, на IMAP Default остаётся сильным, а на Pandoc различия наблюдаются при малой выборке.

Фото: markusspiske / Pixabay