Эксперимент с 26 техниками тестирования: код ИИ-агентов лучше не становится

Автор блога повторно использовал свой прежний эксперимент, реализацию алгоритма сжатия Zstd на Rust агентом Codex на базе модели, которую источник называет «GPT-5.6 Sol», при среднем и повышенном («xhigh») уровне рассуждений. На этот раз агенту к одному и тому же заданию добавляли разные приписки вроде «используй разработку через тестирование (TDD)», «используй Lean 4», «используй QuickCheck», «используй property-based тестирование», всего 26 таких условий: ACL2, Alloy, «проверь и профаззь рискованные места», «сначала аудит», Creusot, вариант без всяких добавок («по умолчанию»), дифференциальное тестирование, фаззинг, Hegel, Insta, «суждение» (агенту предложили самому выбрать лучшую технику), Kani, Lean 4, «не делай ошибок», метаморфное тестирование, мутационное тестирование, property-based тестирование, Proptest, QuickCheck, rstest, встроенный тест-фреймворк Rust, SMT-солверы (Z3, cvc5, Yices), Spin, TDD, TLA+ и Verus. Дополнительно проверили четыре готовых «скилла»: официальный скилл Hegel, тест-скилл ECC для Rust (ECC, сборник скиллов с 250 тысячами звёзд и 38 тысячами форков на GitHub), скилл для property-тестирования от Trail of Bits и собственный скилл автора. Метрика, доля прогонов, где код прошёл 100% скрытых тестов, в среднем по 80 прогонов на каждое условие и уровень усилий; отдельно то же самое проверили на разборе IMAP RFC (40 прогонов на условие) и ещё нескольких RFC.

Автор заранее зафиксировал прогнозы с оценкой уверенности: TDD не покажет хорошего результата (уверенность 55%), формальные методы не окажутся лучше остальных (52%), приписка «не делай ошибок» не обгонит вариант без инструкций (95%), скилл ECC не обгонит остальных, несмотря на популярность на GitHub (65%), скилл Hegel не обгонит остальных (65%), скилл Trail of Bits не обгонит остальных (55%).

По итогам эксперимента ничего не вырвалось вперёд с большим отрывом. Вариант без всяких дополнительных инструкций держался заметно выше среднего. При повышенном уровне рассуждений (xhigh) условия, связанные с фаззингом и property-based тестированием, в среднем чуть опередили формальные методы; при среднем уровне усилий картина была куда более смешанной. Рекомендованные готовые скиллы в целом показали себя хуже, кроме собственного скилла автора, который справился нормально, по его словам, разница в том, что его скилл специально уводит агента от типичного неудачного поведения, тогда как остальные скиллы больше похожи на учебники. TDD, как и предполагалось, результата не улучшил; скилл, который среди прочего подталкивал агента к TDD, тоже показал себя плохо там, где агент действительно следовал этой инструкции.

При более внимательном разборе оказалось, что агенты в принципе плохо умеют пользоваться этими техниками и библиотеками, независимо от того, что им называли. Автор приводит по этому поводу комментарий Гэри Бернхардта о типичном подходе агентов к тестированию. Когда агенту называли конкретную технику, он либо просто писал те же тесты, что написал бы и так, только обёрнутые в синтаксис нужного фреймворка, либо применял технику поверхностно, не извлекая из неё реальной пользы: в условиях с формальными методами агенты чаще всего доказывали не относящиеся к делу свойства, а в property-based тестировании, налегали на случайные входные данные, в основном попадающие в тривиальные или отбрасываемые (invalid) случаи, либо проверяли тривиальное свойство на малополезных случайных данных. Та же картина повторилась и на разборе IMAP RFC, и на других RFC, вне зависимости от типа задачи агенты не использовали формальные методы, библиотеки или техники тестирования эффективно. На повышенном уровне усилий (xhigh) агенты обычно добивались, чтобы их собственные тесты проходили, но сами тесты были слабыми: например, агент подавал в тест, ожидающий четыре разных битовых потока, четыре одинаковых, и не ловил баг, из-за которого потоки могли перепутаться местами. Более низкий уровень усилий при работе в наивном цикле давал ещё худший результат, по словам автора, агенты в этом случае ещё сильнее скатывались к слабым тестам.

Автор недоумевает, почему лаборатории, разрабатывающие ИИ, до сих пор не создали среды для обучения агентов через reinforcement learning (RL) именно тестированию, хотя качество кода напрямую влияет на то, насколько применимы кодинг-агенты, а сама задача, на его взгляд, вполне поддаётся такому обучению, по аналогии с тем, как агентов уже успешно обучили решать задачи оптимизации времени выполнения с ограничениями. Возможных причин он называет две: либо знание об эффективных техниках тестирования недостаточно широко распространено, чтобы кто-то додумался собрать под него данные для обучения, либо саму задачу труднее упаковать в RL-среду, чем оптимизацию времени выполнения.

Ключевые факты

Проверили 26 условий (техники и библиотеки тестирования, TDD, Lean 4, QuickCheck, property-based тестирование, формальные методы и другие) плюс 4 готовых скилла на задаче реализации Zstd на Rust агентом Codex; вариант без дополнительных инструкций показал результат заметно выше среднего, и ничего не обогнало остальных с большим отрывом.
При повышенном уровне рассуждений (xhigh) условия с фаззингом и property-based тестированием в среднем немного опередили формальные методы; при среднем уровне усилий картина была смешаннее.
Названную технику агенты чаще всего применяли поверхностно: в формальных методах доказывали не относящиеся к делу свойства, в property-based тестировании, налегали на случайные или тривиальные входные данные.
Даже когда написанные агентом тесты проходили на 100%, они бывали слабыми и пропускали реальные баги, например, тест на четыре разных битовых потока агент удовлетворял четырьмя одинаковыми.
Похожий результат подтвердился на отдельном эксперименте с разбором IMAP RFC (40 прогонов на условие) и на других RFC, независимо от типа задачи.

Почему это важно

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

Кому это важно

Инженерам и командам, которые настраивают промпты, инструкции и скиллы для кодинг-агентов вроде Codex, и рассчитывают через них поднять качество генерируемого кода и тестов. Также тем, кто оценивает готовые скиллы по популярности (звёзды, форки на GitHub), эксперимент показывает, что популярность скилла не гарантирует лучшего результата.

Как это применить

Название техники в промпте, не рычаг качества сам по себе: агент может обернуть привычные ему тесты в синтаксис нужного фреймворка, не получив реальной пользы от техники. Более эффективным в эксперименте оказался кастомный скилл, специально уводящий агента от его типичных провальных паттернов, а не скилл-учебник, объясняющий технику. Кроме того, более высокий уровень усилий (reasoning effort) на практике даёт лучший результат тестирования, чем работа в наивном цикле на пониженном уровне.

Можно ли доверять

Источник, собственный количественный эксперимент автора: 80 прогонов на каждое условие и уровень усилий для задачи с Zstd, отдельно 40 прогонов на условие для IMAP RFC, плюс единичные прогоны на других RFC, с оценкой доли прогонов, прошедших 100% скрытых тестов. Захваченный текст статьи обрывается на середине фразы и не включает разбор каждого из 26 условий по отдельности, детальное сравнение по IMAP RFC и итоговый вывод; отдельные абсолютные показатели по каждому условию в захваченном тексте не приводятся, только сравнительные формулировки вроде «немного лучше» или «заметно выше среднего». Источник не указывает, чья это модель и что именно означает «GPT-5.6 Sol».

Риски и подводные камни

Главный риск, ложное чувство безопасности: тесты, написанные агентом, проходят на 100% скрытых проверок, но при этом остаются слабыми и пропускают реальные баги (пример из статьи, тест на четыре разных битовых потока агент удовлетворял четырьмя одинаковыми, не заметив возможную путаницу местами). Второй риск, доверять специализированным техникам или популярным готовым скиллам просто по названию или числу звёзд на GitHub: в эксперименте это не давало преимущества, а иногда (как со скиллом, подталкивающим к TDD) ухудшало результат.

«Подход ИИ-агентов к тестированию, это, если упростить: взять патологические случаи, которые пятнадцать лет назад придумал кто-то, критикующий моки, ни разу их толком не использовав. Наивные фантазии о чрезмерном использовании моков. И сделать эти патологии основой своей стратегии тестирования.»

— Гэри Бернхардт