English Version →

Проект 07. Побудова вашого першого автоматизованого циклу

Пов'язана лекція: L13. Чому вам потрібно припинити писати промпти для свого агента

Що ви зробите

Це перехідний проект від «Harness» до «Loop». Ви вже знаєте, як налаштувати агента належним середовищем, інструкціями та зворотним зв'язком — тепер ви перетворите це налаштування на цикл, який працює самостійно.

Ви проведете три поступових експерименти: спочатку перетворите завдання з ручного на /goal, потім перетворите завдання моніторингу на таймер /loop, і нарешті побудуєте повний цикл maker-checker, щоб відчути, що це коли ви виходите за межі циклу.

Файли проекту

Шлях до репозиторію: projects/project-07/

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

Інструменти, які ви використовуватимете

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

Кроки

Підготовка

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

Експеримент 1: Цикл мети — від ручного запуску до автоматичного

Перейдіть на гілку p07-goal-loop.

1. Напишіть опис мети: Перетворіть вибране завдання у файл goal.md, що містить:

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

2. Перший ручний запуск: Надайте завдання агенту вручну самі. Запишіть, скільки ходів знадобилося, скільки разів ви втрутилися, та якість результату. Це ваш базовий рівень.

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

4. Порівняйте результати:

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

5. Ітеруйте над goal.md: Якщо результати погані, перегляньте опис мети і запустіть знову. Продовжуйте, поки не задовольнитеся результатами, або поки не підтверджите межі того, що може зробити цикл мети для цього завдання.

Експеримент 2: Цикл таймера — перетворіть моніторинг на серцебиття

Перейдіть на гілку p07-timer-loop.

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

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

2. Напишіть промпт/скрипт моніторингу: Чітко викладіть кроки моніторингу — що перевіряти, що робити, коли знайдено проблеми, і коли викликати людину.

3. Запуск з /loop (або автоматизація потоку 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 — Чому вам потрібно припинити писати промпти для свого агента
• Лекція 12 — Чому кожна сесія має залишати чистий стан (кожен раунд циклу потребує чистого стану)
• Лекція 11 — Чому спостережуваність належить всередині hарнесу (вам потрібно бачити, що відбувається всередині циклу)
• Лекція 05 — Чому файли стану є хребтом безперервності (файли стану циклу — це розширення файлів стану)