Тесты и git как страховка

Документация Claude Code сама оговаривает: контрольные точки — быстрое восстановление внутри сессии, а постоянная история остаётся за git. Действия во внешних системах (базы, API, деплой) контрольными точками не откатываются: их ограничивают разрешениями (урок 6).

1. 1.Проверьте состояние: git status --short не должен показывать чужих правок. Если они есть, закоммитьте или спрячьте их: иначе в диффе агента смешаются ваши и его изменения.
2. 2.Создайте ветку на задачу: git switch -c feature/short-name. Агент не должен работать в основной ветке.
3. 3.Зафиксируйте базу: убедитесь, что тесты проходят до начала. Красные тесты до сессии лишают смысла проверку после неё.
4. 4.Запишите задачу и критерий (шаблон из урока 5).

Если вы запускаете две сессии одновременно, дайте каждой свой рабочий каталог. В Claude Code для этого есть claude --worktree имя (каждая сессия получает отдельный checkout на своей ветке), в Codex — команда /worktree. Тот же результат даёт обычный git worktree add -b ветка путь. Репозиторию для этого нужен хотя бы один коммит.

Порядок «сначала падающий тест» даёт агенту проверку, которую он может запустить сам, а вам — понятный критерий. Документация Claude Code приводит пример запроса: «напиши падающий тест, который воспроизводит проблему, затем исправь». Документация Codex советует для багов сначала воспроизвести ошибку и только затем предлагать исправление, а после правки просить запустить линтер и самый малый подходящий набор тестов и показать команды и результаты.

Шаги:

1. 1.Попросите написать тест и убедитесь, что он падает по правильной причине. Прочитайте тест сами: он должен описывать требование, а не повторять реализацию.
2. 2.Попросите реализовать код, пока тест не пройдёт.
3. 3.Запустите полный набор проверок сами или потребуйте вывод.
4. 4.Следите, чтобы агент не «починил» красный тест, ослабив или отключив его. Попросите устранять причину, а не проверку, и прочитайте дифф тестов отдельно.

Ритм работы: одна задача — один дифф — один коммит. Агент может сам сделать коммит, если вы попросите, но сообщение и состав коммита проверяйте. Практика для обоих инструментов:

• коммитьте после каждого зелёного шага, а не в конце дня;
• смешанные правки разделяйте: в коммит идут только фрагменты, относящиеся к задаче (приём git add -p разобран в уроке библиотеки);
• в сообщении коммита нет секретов и персональных данных;
• пока вы правите что-то сами, сообщайте об этом агенту, иначе следующим запросом он может перезаписать вашу правку.

Перед git restore посмотрите git status и git diff: команда перезаписывает содержимое указанных путей версией из индекса или HEAD, и несохранённые правки в этих файлах пропадут. Подробнее про reset, reflog и поиск виновного коммита через bisect — в уроке о git при работе с агентом.

После отката перед следующей попыткой поменяйте запрос: если агент дважды ошибся одинаково, причина в постановке (недостаток контекста или критерия), а не в упрямстве модели.

Всё, что вы проверили локально, должно проверяться ещё раз в CI на pull request. Ассистент может не запустить длинный набор, а вы можете не заметить красный тест в чужом файле. Защищённая основная ветка и обязательные проверки превращают договорённость в правило.

Следующий урок — подключения и инструменты: MCP. Если вам нужен независимый взгляд на то, насколько надёжно в проекте работают тесты и откаты, посмотрите услугу аудита ИИ-кода.