Модуль 04 — Оракулы и проверка

Время: 5 часов · Формат: теория 90 мин + практика 210 мин

Теория

1. Оракул — главный инструмент

Оракул — автоматический источник «да/нет» про результат. Тест, компилятор, линтер, типчекер, запуск приложения, сравнение с эталоном.

Без оракула вайбкодинг превращается в чтение красиво написанного вранья.

Без оракула:  агент говорит "готово" → вы верите → через неделю баг
С оракулом:   агент говорит "готово" → pytest → 2 падения → агент чинит

Оракул не просто ловит ошибки — он даёт модели обратную связь. Это меняет всё: вместо «объясню словами, что не так» вы вставляете вывод команды.

2. Пирамида проверок

От дешёвых и быстрых к дорогим:

1. Синтаксис / компиляция        секунды
2. Типы (mypy, tsc)              секунды
3. Линтер (ruff, eslint)         секунды
4. Юнит-тесты                    секунды-минуты
5. Интеграционные тесты          минуты
6. Запуск приложения / e2e       минуты
7. Ревью человеком               минуты

Правило: агент должен иметь доступ ко всем уровням 1–5 одной командой.

3. Один вход, а не десять

Плохо:

"Запусти pytest, потом ruff, потом mypy, и ещё проверь..."

Хорошо — одна команда в AGENTS.md:

make check      # или: npm run check, ./scripts/check.sh

Внутри:

ruff check . && mypy . && pytest -q

Агент вызывает make check, получает компактный вывод, исправляет. Это дешевле и надёжнее, чем заставлять его помнить пять команд.

4. TDD с агентом

Классический цикл работает лучше, если тест пишет человек (или человек утверждает):

1. Человек: спека + падающий тест
2. Агент: минимальный код, чтобы тест прошёл
3. Человек: читает дифф
4. Агент: рефакторинг, тесты остаются зелёными

Почему тест от человека: тест — это и есть ваша спека в исполняемом виде. Если тест придумал агент, он проверит своё же понимание задачи.

Компромисс для скорости: агент пишет тесты по вашему списку кейсов, утверждённому вами.

5. Ошибка — это данные

Правильный цикл исправления:

1. Прогнать проверку
2. Вставить вывод целиком (не пересказ!)
3. "Исправь причину, не симптом. Объясни в 2 строках."
4. Повторить

Плохо: «у меня тест падает, посмотри». Хорошо: полный вывод pytest с traceback.

6. Golden files и сравнение

Для задач «сгенерируй конфиг/отчёт/текст» — эталонный файл:

tests/golden/expected.json

Тест сравнивает результат с эталоном. Любое расхождение — видимый дифф. Это оракул для «неточных» задач.

7. Чего оракул не ловит

Тест проверяет то, что в нём написано. Пропущенный кейс — не пойман.
Линтер не видит логических ошибок.
Зелёные тесты не значат «правильное поведение для бизнеса».

Поэтому оракул дополняет ревью, а не заменяет.

8. Проверка внешних фактов

Для того, что нельзя проверить в коде (версии API, поведение библиотеки):

запустить минимальный пример;
открыть официальную документацию;
проверить --help реального CLI.

Модель может выдумать флаг. --help — не может.

Чек-лист понимания

Почему оракул важен не только для поиска ошибок, но и для качества ответов агента?
Почему тест на задачу лучше писать человеку?
Что не так с запросом «у меня тест падает, посмотри»?
Какие классы ошибок не ловятся тестами?

Практика

См. practice.md.