Дэн Лу проверил ИИ-агентов: больше тестов не сделало код надёжнее

ИИ-агент может увеличить число тестов и всё равно пропустить ошибки в коде. Разработчик Дэн Лу сравнил инструкции по тестированию на реализации декодера Zstd. 8 сентября его эксперимент обсуждают на Hacker News : одного требования «используй TDD — разработку через тестирование» или «добавь фаззинг» оказалось недостаточно.

В эксперименте использовались Codex с GPT-5.6 Sol, Rust, 26 вариантов инструкций и 4 дополнительных набора правил. Вывод относится к этой постановке задачи, а не ко всем ИИ-моделям и методикам разработки.

Что проверял Дэн Лу

За основу взят его прежний тест с Zstd , форматом сжатия данных. Агент получает спецификацию и пишет декодер в контейнере без интернета. Контрольные тесты ему не показывают: они отдельно проверяют результат. Такой подход позволяет проверить решение на независимом наборе сценариев.

В новом сравнении для каждой комбинации инструкции и уровня вычислительных усилий модели, medium или xhigh, проведено 80 запусков. Основная метрика — доля запусков, прошедших 100% скрытых тестов. Вариант без специальных указаний оказался выше среднего; убедительного универсального победителя автор не выделяет.

Как тесты пропускали ошибки

При явном требовании использовать встроенные тесты Rust их число удваивалось на medium и увеличивалось на 25% на xhigh, но корректность не улучшалась. В отдельных тестах обработки четырёх битовых потоков встречались одинаковые входы: перестановка потоков оставалась незаметной. Фаззинг часто сводился к случайным байтам, которые проверяли преимущественно отказ на некорректном вводе.

Фаззинг — проверка программы на множестве автоматически сгенерированных входов. Если все они отбрасываются в начале, глубокая логика обработки может остаться нетронутой. В тестировании свойств задают правило для целого класса входов: например, после сжатия и распаковки должны восстановиться исходные данные. Библиотека Proptest также умеет уменьшать найденный сбойный пример, чтобы причину было проще разобрать.

Что это меняет для ревью

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

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

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

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

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