English Version →

Проект 07. Постройте свой первый автоматизированный цикл

Связанная лекция: L13. Why You Need to Stop Prompting Your Agent

Что вы будете делать

Это переходный проект от «Harness» к «Loop». Вы уже знаете, как настроить агента с правильным окружением, инструкциями и обратной связью — теперь вы превратите эту настройку в цикл, который работает сам по себе.

Вы проведёте три прогрессивных эксперимента: сначала превратите задачу из ручной в /goal, затем превратите задачу мониторинга в таймер /loop, и наконец построите полный цикл maker-checker, чтобы ощутить, что это такое, когда вы выходите за рамки цикла.

Файлы проекта

Путь в репозитории: projects/project-07/

Директория	Что внутри	Что вы делаете
starter/	Небольшой проект базы знаний с полным комплектом harness (финальное состояние P06), включая AGENTS.md, feature_list.json, init.sh, session-handoff.md, clean-state-checklist.md.	Превратите этот комплект harness в тот, что может циклически работать автоматически.
solution/	Полные реализации трёх циклов: целевой цикл, таймерный цикл, цикл maker-checker, плюс файлы состояния цикла и скрипты верификации.	Справочный материал по паттернам дизайна циклов и управлению состоянием.

Инструменты, которые вы будете использовать

• Claude Code или Codex
• Git
• Ваш полный комплект harness из P06
• Терминальный мультиплексор (tmux или screen, для наблюдения за долго работающими циклами)
• Опционально: GitHub Actions или cron (для продвинутых событийно-ориентированных / запланированных экспериментов)

Шаги

Подготовка

1. Начните с того же коммита, на котором вы закончили P06.
2. Создайте три ветки: p07-goal-loop, p07-timer-loop, p07-maker-checker.
3. Подтвердите, что ваш harness работает: запустите init.sh, проверьте, что файл состояния, список функций и документы передачи на месте.
4. Выберите целевую задачу, над которой цикл будет работать повторно. Выберите что-то среднего размера с чёткими критериями завершения — например, «добавить модульные тесты ко всем модулям, достигнув 80% покрытия» или «добавить валидацию входных данных ко всем API-точкам».

Эксперимент 1: Целевой цикл — от ручного запуска к автозапуску

Переключитесь на ветку p07-goal-loop.

1. Напишите описание цели: Превратите выбранную задачу в файл goal.md, содержащий:

   • Чёткая цель («что считается готовым»)
   • Метод верификации («как подтвердить, что готово» — запустить тесты? запустить линтер? проверить покрытие?)
   • Условие остановки («когда следует остановиться» — максимальное количество шагов? лимит времени? лимит бюджета?)
   • Ограничения («чего не трогать» — производственная конфигурация, схема базы данных и т.д.)

2. Первый ручной запуск: Дайте задачу агенту вручную, сами. Запишите, сколько шагов потребовалось, сколько раз вы вмешались, и качество результата. Это ваша базовая линия.

3. Запуск с /goal: Используйте тот же goal.md как вход и запустите его в режиме /goal. Агент циклически повторяет сам, пока цель не будет достигнута или не сработает условие остановки.

4. Сравните результаты:

   • Разница в количестве шагов
   • Разница в количестве ваших вмешательств
   • Разница в качестве результата (используя тот же стандарт верификации)
   • Разница в потраченном вами времени

5. Итерируйте над goal.md: Если результаты плохие, пересмотрите описание цели и запустите снова. Продолжайте, пока не будете удовлетворены результатами, или пока не подтвердите предел того, что может сделать целевой цикл с этой задачей.

Эксперимент 2: Таймерный цикл — Превратите мониторинг в сердцебиение

Переключитесь на ветку p07-timer-loop.

1. Выберите задачу мониторинга: Найдите повторяющуюся проверку, которую вы обычно делаете вручную. Например:

   • Запускать набор тестов каждый час, исправлять падения
   • Проверять обновления безопасности зависимостей каждое утро
   • Проверять нарушения стиля кодирования после каждого коммита
   • Периодически сканировать комментарии TODO, чтобы увидеть, какие из них устарели

2. Напишите запрос/скрипт мониторинга: Чётко изложите шаги мониторинга — что проверять, что делать при обнаружении проблем и когда вызывать человека.

3. Запуск с /loop (или Thread automation в Codex):

   • Установите разумный интервал (рекомендуется 10-30 минут — слишком коротко и вы будете раздражены, слишком долго и вы не увидите эффекта)
   • Дайте ему работать как минимум 2 часа (или займитесь чем-то другим и вернитесь позже)

4. Запишите результаты:

   • Сколько проблем он нашёл?
   • Сколько он исправил сам?
   • Сколько было ложных срабатываний?
   • Сколько он усугубил?
   • Сколько времени вы потратили на сопровождение его результатов?

5. Размышление: Стоит ли автоматизировать эту задачу мониторинга? Сравните сэкономленное время против времени, потраченного на сопровождение. Если не стоит — вы выбрали не ту задачу, или цикл плохо спроектирован?

Эксперимент 3: Цикл Maker-Checker — Выйдите из цикла

Переключитесь на ветку p07-maker-checker.

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

1. Спроектируйте структуру цикла:

   • Maker-агент: реализует, пишет код, изменяет файлы
   • Checker-агент: верифицирует, запускает тесты, делает ревью кода, проходит / не проходит
   • Файл состояния (loop-state.md): записывает текущий раунд, что было сделано, результаты верификации, что дальше
   • Условие остановки: N последовательных прохождений, или достигнуто максимальное количество раундов

2. Напишите три запроса:

   • Инструкции для maker (что делать, как делать, чего не трогать)
   • Инструкции для checker (что верифицировать, как верифицировать, что считается проходом, как давать обратную связь)
   • Логика управления циклом (кто ходит первым, как работает передача, как запустить следующий раунд)

3. Запустите как минимум 5 раундов:

   • Раунд 1: Maker реализует → Checker верифицирует → Не прошло → Обратная связь maker'у
   • Раунд 2: Maker дорабатывает на основе обратной связи → Checker верифицирует → ...
   • ...
   • До последовательного прохода, или пока вы не остановите

4. Запишите состояние каждого раунда:

   • Номер раунда
   • Что сделал Maker
   • Какие проблемы нашёл Checker
   • Прошло / не прошло
   • Вмешались ли вы? (если да — почему?)

5. Финальный ретроспектив:

   • Сколько раз вы вмешались? Почему?
   • Что бы случилось, если бы вы не вмешались?
   • Пропустил ли Checker какие-то проблемы?
   • Продолжал ли Maker делать одну и ту же ошибку?
   • Где потолок качества этого цикла? Возможности maker, или возможности checker?

Как измерять результаты

Метрика	Эксп 1 (Цель)	Эксп 2 (Таймер)	Эксп 3 (Maker-Checker)
Скорость завершения задачи	Была ли достигнута цель?	Сколько циклов мониторинга отработало?	Сколько раундов до прохода?
Человеческие вмешательства	Сколько раз вы вмешались?	Сколько времени вы потратили на сопровождение?	Сколько раз вы вмешались?
Качество результата	Как это сравнивается с ручным?	Уровень ложных срабатываний? Пропущенные проблемы?	Сколько проблем нашёл Checker, которые вы бы не нашли?
Экономия времени	Сколько времени вы сэкономили?	Стоит ли автоматизировать?	Время, потраченное на проектирование цикла против сэкономленного времени
Надёжность	Было ли условие остановки доверительным?	Убежало ли оно?	Может ли цикл застрять на одном месте?

Что сдавать

• goal.md (описание цели эксперимента 1, как минимум две итерации)
• Заметки со сравнением эксперимента 1: ручной режим против целевого цикла
• Запрос мониторинга эксперимента 2 + журнал 2-часового запуска
• Три запроса эксперимента 3 (Maker / Checker / Управление циклом)
• loop-state.md эксперимента 3 (записано как минимум 5 раундов)
• Финальный ретроспектив: выводы из всех трёх экспериментов, как изменилось ваше понимание loop engineering, что хорошие кандидаты для циклизации, а что — нет

Связанные лекции

• Лекция 13 — Why You Need to Stop Prompting Your Agent
• Лекция 12 — Why Every Session Must Leave a Clean State (каждый раунд цикла нуждается в чистом состоянии)
• Лекция 11 — Why Observability Belongs Inside the Harness (вам нужно видеть, что происходит внутри цикла)
• Лекция 05 — Why State Files Are the Backbone of Continuity (файлы состояния цикла — это расширение файлов состояния)