Сначала тест, который падает. Потом код

Практика. Самый короткий промпт, который заметно улучшает работу кодинг-агента, и почему он работает.

· 2 мин чтения

У кодинг-агентов два типичных провала. Они пишут код, который не работает, но выглядит правдоподобно. И пишут лишний код, который никогда не будет вызван. Обе проблемы лечатся приёмом, которому много лет, — разработкой через тесты.

Саймон Уиллисон формулирует его в три слова: «Используй red/green TDD».

Что это значит

TDD (test-driven development) — разработка через тесты. Самая строгая её форма:

  1. Красный. Сначала пишется автоматический тест на нужное поведение. Его запускают и убеждаются, что он падает.
  2. Зелёный. Потом пишется код, пока тест не пройдёт.

Шаг «убедиться, что тест падает» — не формальность. Если его пропустить, можно написать тест, который проходит и без нового кода. Он ничего не проверяет, но создаёт ощущение, что всё хорошо. Агенты делают такие тесты охотно.

Уиллисон замечает, что любая хорошая модель понимает «red/green TDD» как сокращение для «пиши тесты сначала, убедись, что они падают, потом пиши код, пока не пройдут». Длинную инструкцию писать не нужно.

Почему это так хорошо подходит агентам

  • У агента появляется способ проверить себя. Вместо «кажется, готово» — объективный сигнал: тест прошёл или нет. Агент в цикле работает, пока сигнала нет.
  • Лишний код не пишется. Код пишется ровно под тест. Ничего «на будущее».
  • Остаются тесты на потом. Чем больше проект, тем выше шанс, что новое изменение сломает старое. Набор тестов — лучшая защита, и агент строит его сам по ходу работы.

Тот же принцип за пределами кода

Идея шире, чем тесты: дайте агенту измеримую цель и способ её измерить.

  • В OpenAI, в проекте, где весь код писал Codex, агенту открыли логи, метрики и трассировки запущенного приложения. После этого задачи вида «запуск сервиса должен укладываться в 800 мс» стали решаемыми: агент меряет, правит, меряет снова. Отдельные запуски работали над задачей больше шести часов подряд, часто пока люди спали.
  • Любитель математики оставил агента OpenClaw на ночь с задачей укладки кругов в квадрат и скриптом, который считает плотность и сравнивает её с таблицей рекордов. Утром было 10 новых рекордов.

В обоих случаях работает не «умная модель», а счётчик, который говорит модели, стало лучше или хуже.

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

  1. Перед задачей для кодинг-агента допишите в конец: «Используй red/green TDD».
  2. Если проект новый или тестов нет — сначала попросите агента запустить существующие тесты (у Уиллисона это отдельный совет «First run the tests»). Так агент узнает, как их запускать, и увидит исходное состояние.
  3. Проверяйте в истории работы, что красная фаза действительно была: тест запускался и падал до изменения кода.
  4. Для задач без тестов — производительность, размер, качество — сначала сделайте скрипт, который выдаёт число. Потом ставьте задачу «улучши это число».
  5. Если цель нельзя измерить — агент будет крутиться долго и дорого. Задачу стоит переформулировать.