У червні 2026 року три людини незалежно одна від одної дійшли однієї й тієї ж ідеї протягом одного тижня.
Пітер Штайнбергер, творець OpenClaw, публічно заявив, що варто припинити давати підказки кодувальним агентам і натомість почати проєктувати цикли, які дають їм підказки. Майже в той самий час Борис Черні, який керує Claude Code в Anthropic, сказав, що більше не дає підказок Клоду безпосередньо — у нього є цикли, які дають підказки Клоду та вирішують, що робити, а його справжня робота — писати ці цикли. Через кілька днів Едді Османі, інженер з Google, описав це явище та дав йому назву: інженерія циклів.
Ніхто з них не винайшов цю практику з нуля. Вони назвали те, що вже відбувалося, тому що інструменти, які лежали в її основі, непомітно перетнули певний поріг. Кодувальні агенти стали достатньо надійними, щоб виконувати справжнє завдання без нагляду. Планування стало достатньо дешевим, щоб повторювати завдання за таймером перестало здаватися марнотратством. Вартість одного запуску агента впала настільки, що спробувати щось п'ять разів коштує дешевше, ніж один раз ретельно обдумати.
Цей поріг і є причиною існування цієї дорожньої карти. Підказки були навичкою, коли людині потрібно було сидіти за клавіатурою та керувати агентом рядок за рядком. Інженерія циклів — це навичка тепер, коли агенту можна передати ціль і залишити його працювати. Це повний 20-кроковий шлях від одного до іншого, по порядку, тому що порядок важливіший за будь-який окремий крок.
Ось чому порядок має значення, перш ніж перейти до самих кроків. Інженерія циклів — це не єдина навичка, яка в вас або є, або немає. Це стек, де кожен шар залежить від того, щоб шар під ним був справді міцним. Створення тригера планування, крок 14, до того, як у вас є справжня умова зупинки, крок 10, означає лише те, що ви автоматизували систему, яка тепер може марнувати гроші без нагляду, а не лише тоді, коли ви дивитеся. Додавання персистентності, крок 11, до того, як у вас є справжня верифікація, кроки 6 і 7, означає, що ви ретельно записуєте уроки, отримані від Судді, який може просто ставити штампи на погані результати, що робить шар персистентності активно шкідливим, а не просто марним. Перестрибування вперед у цьому списку означає не просто пропуск функції. Це означає будувати захопливі частини на фундаменті, який насправді не може їх витримати, і виявити це лише тоді, коли щось уже пішло не так у масштабі.
Фаза перша: Зміна мислення (Кроки 1-4)
Крок 1: Визнайте, що вузьким місцем є ви, а не модель
Перший справжній крок не є технічним. Це визнання того, що обмежувальним фактором у вашому поточному робочому процесі є не можливості моделі, а ваша власна присутність у циклі. Щоразу, коли ви сидите й чекаєте на відповідь, читаєте її, а потім вводите наступну інструкцію, ви є найповільнішою частиною системи з великим відривом. Модель може діяти, перевіряти та повторювати спроби набагато швидше, ніж ви можете контролювати її в цьому процесі.
До цього кроку не додається жодна підказка. Це рішення. Поки ви насправді не повірите в це, кожен наступний крок здаватиметься непотрібним ускладненням, а не тим, чим він є насправді — усуненням справжнього вузького місця.
Крок 2: Перестаньте плутати довшу підказку з кращою системою
Інстинкт, коли щось йде не так, — додати ще одну інструкцію до тієї самої підказки. З часом це створює підказку, яка є щільною, суперечливою стіною правил, які модель більше не може утримувати в робочій пам'яті одночасно, тому вона підлаштовується під те, що здається найбільш актуальним, і тихо ігнорує решту.
Інженерія циклів повністю замінює цей інстинкт. Замість додавання ще одного правила до підказки, ви додаєте ще один компонент до системи. Крок верифікації. Файл пам'яті. Запланований тригер. Сама підказка має з часом ставати коротшою, оскільки система навколо неї стає більш здатною, а не навпаки.
Крок 3: Навчіться бачити кожне завдання як п'ять дій
Будь-який окремий виток циклу, незалежно від конкретної сфери, розкладається на п'ять дій. Виявлення — з'ясування того, що насправді потрібно зробити. Передача — передача завдання тому, хто його виконуватиме. Верифікація — перевірка результату на відповідність чомусь реальному. Персистентність — запис того, що сталося, щоб не загубити. Планування — визначення, коли це запускатиметься знову.
У більшості людей поточний робочий процес має лише дві з цих дій явними: виявлення та передача, які виконуються вручну у вікні чату. Інші три або не існують, або відбуваються невидимо в голові людини. Інженерія циклів — це практика зробити всі п'ять дій явними та автоматичними.
Крок 4: Визначте своє перше справжнє завдання-кандидат
Перш ніж щось будувати, виберіть одне завдання, яке ви вже виконуєте регулярно, зі стандартом, який ви могли б записати, якби вас попросили. Не вашу найскладнішу проблему. Не щось абсолютно нове. Завдання з реальним, впізнаваним визначенням виконання — те, на що колега міг би подивитися й одразу погодитися, чи виконано його правильно, чи ні. Це обмеження важливіше, ніж здається. Завдання без чіткого визначення виконання не може мати кроку три, верифікації, а цикл без справжньої верифікації — це не цикл, це просто припущення без нагляду.
Фаза друга: Побудова першого циклу (Кроки 5-9)
Крок 5: Напишіть визначення виконання перед тим, як писати будь-яку підказку
Це крок, який більшість людей пропускають, і той, який визначає, чи працюватиме все після нього. Перш ніж написати жодної інструкції для агента, запишіть простою мовою, як саме виглядає правильний результат. Конкретні, перевірювані критерії, а не нечітке відчуття якості.
ВИЗНАЧЕННЯ ВИКОНАННЯ для [назва завдання]:
- [Конкретний, перевірюваний критерій 1]
- [Конкретний, перевірюваний критерій 2]
- [Конкретний, перевірюваний критерій 3] Це завдання НЕ виконане, якщо будь-якого з вищезазначеного бракує, навіть якщо результат виглядає завершеним або відшліфованим.
Якщо ви не можете заповнити це для обраного завдання, поверніться до кроку 4 і виберіть інше.
Крок 6: Розділіть Будівельника та Суддю
Найважливіше архітектурне рішення в будь-якому циклі. Роль, яка створює роботу, і роль, яка перевіряє роботу, повинні бути розділені, тому що модель, яка переглядає власний результат у тому ж контексті, в якому вона його створила, схильна захищати цей результат, а не щиро його критикувати.
Будівельник отримує творчу свободу та створює першу спробу. Суддя отримує результат Будівельника плюс визначення виконання з кроку 5 і більше нічого — його не потрібно переконувати. В ідеалі Суддя також має доступ до того, чого не має Будівельник — до тестового набору, оригінального вихідного документа, живих даних — щоб його вердикт ґрунтувався на реальних доказах, а не просто на другій думці, сформованій так само, як і перша.
Крок 7: Дайте Судді об'єктивну істину, а не просто думку
Суддя, який бачить лише результат Будівельника, може сказати вам, чи виглядає він зв'язним. Він не може сказати вам, чи він насправді правильний. Для завдань з кодування об'єктивною істиною є тестовий набір і фактичний результат виконання. Для завдань зі створення контенту — це оригінальний вихідний матеріал і бриф, поруч із чернеткою. Для дослідницьких завдань — це фактичні документи, які мали бути використані.
Якщо ви не можете назвати конкретну об'єктивну істину, з якою Суддя звірятиметься, ваш цикл ще не має справжньої верифікації, незалежно від того, наскільки впевнено звучить мова Судді.
Крок 8: Напишіть формат передачі перед тим, як писати підказку для передачі
Результат Будівельника та вердикт Судді потребують визначеної структури, а не вільної прози, інакше Менеджер на наступному кроці не матиме на що надійно орієнтуватися.
РЕЗУЛЬТАТ БУДІВЕЛЬНИКА: результат + впевненість + відомі невизначеності
ВЕРДИКТ СУДДІ: ПРОЙДЕНО / НЕ ПРОЙДЕНО / ПОТРІБНА ДООПРАЦЮВАННЯ + конкретні знайдені проблеми + об'єктивна істина, з якою це звірялося
Крок 9: Запустіть його вручну один раз, повністю, перш ніж автоматизувати що-небудь
Перш ніж налаштовувати планування або автоматичні повторні спроби, запустіть повну послідовність "Будівельник, потім Суддя" самостійно, вручну, один раз. Критично оцініть вердикт Судді. Чи погодилися б ви з ним? Якщо Суддя пропустив щось, що, як ви знаєте, є неправильним, або забракував те, що насправді було добре, виправте об'єктивну істину або критерії, перш ніж рухатися далі. Автоматизація зламаного кроку верифікації просто створює зламані результати швидше.
Практичний приклад через кроки 5-9
Щоб зробити останні п'ять кроків конкретними, ось як вони реалізуються на реальному, поширеному завданні: перетворенні необробленого вихідного документа на готовий фрагмент контенту.
Визначення виконання, з кроку 5: кожне фактичне твердження в чернетці походить від чогось, що насправді присутнє у вихідному документі. Чернетка задовольняє всі конкретні вимоги з брифу: обсяг, тон, необхідна структура. Основна аргументація зберігається чітко, без розмивання наповнювачем.
Будівельник, з кроку 6, отримує джерело та бриф і створює чернетку разом із явним зазначенням того, щодо чого він не був впевнений під час написання: число, яке він не був повністю впевнений, що є в джерелі, твердження, яке він вивів, а не знайшов прямо вказаним.
Суддя, з кроку 7, отримує чернетку та оригінальне джерело поруч, ніколи не лише чернетку, і перевіряє кожен із трьох критеріїв визначення виконання окремо, повертаючи результат "пройдено" або "не пройдено" для кожного з них індивідуально, а не одну змішану загальну оцінку. Зведення трьох різних перевірок в один вердикт приховує, який саме вимір насправді не пройшов, що є найпоширенішим способом, як робочий цикл непомітно перестає давати корисний зворотний зв'язок.
Формат передачі, з кроку 8, означає, що вердикт Судді надходить як структурований об'єкт, а не як абзац ухильної прози: три явних результати "пройдено" або "не пройдено" з конкретною причиною, прикріпленою до будь-якого збою.
Запуск цього вручну один раз, відповідно до кроку 9, перед автоматизацією чогось, дозволяє виявити випадок, коли ваш Суддя занадто м'який, пропускаючи чернетку з вигаданою статистикою, тому що стиль написання був відшліфованим, або занадто суворий, забраковуючи чернетку через стилістичну перевагу, якої ніколи не було в брифі. Обидва режими збою поширені при першій спробі, і обидва набагато дешевше виявити вручну один раз, ніж виявити після того, як цикл уже запустився п'ятдесят разів без нагляду.
Фаза третя: Додавання відсутніх частин циклу (Кроки 10-14)
Крок 10: Створіть Менеджера та його умову зупинки
Менеджер читає вердикт Судді та вирішує, що робити далі. Тут також знаходиться умова зупинки циклу, і вона повинна бути записана як жорстка логіка, а не як м'яка інструкція, яку модель може обійти розмовами.
УМОВИ ЗУПИНКИ:
Максимальна кількість редагувань: 3. Якщо 3-й вердикт "не пройдено", передати людині з повною історією, не намагатися виконати 4-й цикл.
Поріг якості: кожен пункт у визначенні виконання повинен показувати ПРОЙДЕНО.
Бюджетна межа: якщо це завдання перевищує [X] вартості або [Y] часу, негайно зупинитися незалежно від поточного стану.
Цикл без справжньої умови зупинки — це не система. Це зобов'язання, яке чекає на день, коли завдання виявиться справді нерозв'язним. Важливо зрозуміти конкретну причину, чому м'яка інструкція тут не працює, а не просто прийняти це. "Зупинитися, коли буде достатньо добре" всередині підказки — це пропозиція, і модель під достатнім тиском, вже маючи кілька невдалих редагувань, часто переконає себе, що поточна спроба достатньо близька, щоб пройти, саме тому, що вона хоче створити задовільне завершення завдання. Жорсткий лічильник ітерацій, який перевіряється механічно кодом або явним правилом, яке Менеджер не може обійти за допомогою міркувань, не має такого режиму збою.
Крок 11: Додайте персистентність, щоб цикл пам'ятав між запусками
Цикл, який починається з нуля щоразу, не пам'ятає, чого він навчився минулого разу. Додайте простий шар персистентності: один файл на кожен справді новий урок, з однорядковим підсумком зверху, записуючи те, що було вивчено або виправлено, і чому це було важливо. Критично важливо: записуйте лише те, що ще не зафіксовано в іншому місці. Дубльована пам'ять — це шум, а не знання.
Дисципліна, яка змушує цей крок працювати в довгостроковій перспективі, — це стриманість під час запису. Інстинкт підказує записувати все, що сталося під час сесії, що створює саме ту проблему роздутого транскрипту, про яку попереджала ця дорожня карта на кроці 2, просто перенесену в папку пам'яті замість підказки. Урок, який варто записати, — це те, що коштувало б реального часу на повторне відкриття, якби його забули, а не запис рутинної роботи, яка пройшла точно як очікувалося.
Крок 12: Додайте періодичний етап консолідації
Сама по собі персистентність з часом створює ту саму проблему, що й роздута підказка: десятки файлів, багато з яких говорять про те саме трохи різними версіями. За регулярним графіком, раз на тиждень — розумно, переглядайте файли пам'яті, об'єднуйте дублікати в єдині, чіткіші уроки та видаляйте все, що згодом виявилося неправильним. Мета — менше файлів, але кожен із більшою щільністю, а не постійно зростаюча купа.
Цей крок — той, який більшість людей пропускають повністю, тому що він сам по собі не створює видимих нових можливостей, він лише запобігає майбутній проблемі. Ця невидимість і є причиною, чому його потрібно планувати явно, а не залишати на той час, коли хтось помітить, що папка пам'яті стала громіздкою, що на практиці означає, що це ніколи не відбувається, доки продуктивність циклу вже не почне погіршуватися під вагою суперечливих, напіврелевантних уроків, які змагаються за той самий контекстний простір.
Крок 13: Додайте крок пригадування
На початку будь-якого нового запуску доручіть циклу сканувати однорядкові підсумки в пам'яті, визначити, які уроки насправді актуальні для поточного завдання, і завантажити лише їх. Явно вкажіть йому сказати, коли нічого в пам'яті не підходить, замість того, щоб насильно вставляти нерелевантний минулий урок у нову ситуацію просто тому, що пам'ять існує.
Крок 14: Додайте тригер планування
Вирішіть, коли цей цикл запускатиметься без вашого ручного запуску. Cron-завдання. Спостерігач за файлами. Повторюваний тригер на основі календаря. Це крок, який перетворює систему, яку ви запускаєте на вимогу, на систему, яка працює, поки ви спите, і це зазвичай найпростіший крок у всьому цьому списку, і той, який більшість людей ніколи не реалізують, навіть побудувавши все інше.
Фаза четверта: Масштабування та зміцнення (Кроки 15-18)
Крок 15: Випробуйте цикл на міцність, перш ніж довіряти йому
Перш ніж покладатися на цей цикл для чогось реального, навмисно перевірте його на чотири режими збою.
Дайте йому справді нерозв'язну версію завдання та підтвердьте, що Менеджер насправді зупиняється, а не зациклюється нескінченно, оскільки цикл, який тестується лише на завданнях, які він може виконати, ніколи насправді не демонстрував, що вміє коректно опрацьовувати невдачі.
Подайте Судді результат, який, як ви знаєте, є тонко неправильним, який добре читається, але містить конкретну фактичну або логічну помилку, яку ви навмисно підкинули, і підтвердьте, що він насправді виявляє недолік, а не пропускає щось правдоподібне на вигляд.
Якщо Будівельник і Суддя використовують одну й ту саму базову модель, подайте Судді помилку, характерну для цієї моделі, і подивіться, чи пропустить він її, оскільки Суддя, який поділяє сліпі плями Будівельника, зводить нанівець всю мету розділення з кроку 6.
Розрахуйте найгіршу вартість запуску циклу до його максимального ліміту редагувань, використовуючи ваші найдорожчі виклики моделей і найдовший розумний результат, і чесно вирішіть, чи злякає вас це число, коли з'явиться на реальному рахунку.
Проведення цих чотирьох тестів перед тим, як довірити циклу щось важливе, виявляє переважну більшість збоїв, які в іншому випадку вперше з'явилися б перед клієнтом, начальником або у вашій власній банківській виписці, а не в контрольованому тесті, який ви провели навмисно.
Крок 16: Направляйте завдання до правильної моделі, а не завжди до однієї й тієї ж
Коли цикл працює, чините опір звичці запускати кожну його частину на вашій єдиній улюбленій моделі. Роль Будівельника зазвичай виграє від вашої найпотужнішої моделі, оскільки вона виконує власне складне міркування, і слабша модель тут створить гіршу першу чернетку, виправлення якої коштуватиме більше циклів редагування, ніж коштувало б згенерувати її добре з першого разу.
Роль Судді, перевірка за конкретним письмовим стандартом, часто працює так само надійно на меншій, дешевшій, швидшій моделі, оскільки від неї не вимагається бути креативною, лише послідовною, і менша модель, яка перевіряє за дуже добре визначеним контрольним списком, часто не поступається більшій моделі при значно менших витратах і затримці.
Менеджеру, який маршрутизує на основі правил, які ви вже записали, майже ніколи не потрібна ваша найдорожча модель, оскільки його робота полягає у виконанні логіки, яку ви вже визначили, а не у відкритих міркуваннях, і він запускається щонайменше один раз за ітерацію незалежно від того, як працюють Будівельник і Суддя, що робить його вартість за виклик важливішою, ніж його сира здатність.
Цей багаторівневий підхід — дорога модель для побудови, дешева та послідовна модель для оцінки рутинних перевірок, дешева модель для маршрутизації — це зазвичай те, звідки беруться справжні заощадження витрат у циклі. Більшість людей припускають, що контроль витрат означає менше циклів або менше редагувань. Насправді це досягається шляхом узгодження вартості моделі з фактичною складністю кожної конкретної ролі у вже побудованому циклі.
Крок 17: Розширтеся до другого циклу, а не до п'яти одразу
Спокуса після того, як перший цикл запрацював, — негайно побудувати ще кілька, взявшись за п'ять різних завдань паралельно, тому що архітектура технічно це тепер підтримує. Чиніть опір цій спокусі довше, ніж здається комфортним. Добійтеся, щоб один цикл працював достатньо надійно, щоб ви справді перестали уважно перевіряти його результати, тобто він постійно проходить ваші власні ручні вибіркові перевірки протягом реального проміжку часу, а не просто одну успішну демонстрацію, за якою всі уважно спостерігали. Лише тоді починайте другий цикл, на іншому завданні, в ідеалі такому, яке мапується на щось зовсім інше, ніж перше, щоб ви перевіряли, чи узагальнюється базова структура, а не просто налаштовували те саме завдання далі.
Крок 18: Створіть спільне представлення для всіх запущених циклів
Коли у вас працює більше одного циклу, відстежуйте спільне представлення витрат і спрацьовувань умов зупинки для всіх них, а не для кожного циклу окремо. Один цикл із розумним бюджетом на завдання виглядає абсолютно нормально сам по собі. Десять циклів, кожен з яких індивідуально вкладається в бюджет, все одно можуть дати тривожну загальну суму, яку ніхто не помічає, доки не надійде сукупний рахунок, саме тому, що відстеження кожного окремого циклу виглядало нормально ізольовано. Записуйте кожне спрацьовування умови зупинки, а не лише успішні завершення. Цикл, який постійно досягає своєї стелі редагувань, у той час як інші рідко, говорить вам, що стандарт його Судді відкалібрований неправильно: занадто суворий, щоб коли-небудь насправді пройти, або перевіряється за неправильною об'єктивною істиною, а не те, що основне завдання просто складне. Ця закономірність невидима, якщо ви відстежуєте лише успіхи та розглядаєте кожне ескалування як ізольовану, непримітну подію, а не як точку даних про дизайн цього конкретного циклу.
Фаза п'ята: Стаючи системним дизайнером (Кроки 19 і 20)
Крок 19: Перестаньте вимірювати себе кількістю написаних підказок
Найочевидніша ознака того, що зміна насправді відбулася, — це зміна того, на що ви звертаєте увагу щодня. Той, хто дає підказки, відстежує, скільки хороших підказок він написав. Системний дизайнер відстежує, скільки циклів працює, наскільки надійний кожен з них і скільки власного часу йому повернули системи, які більше не потребують нагляду. Якщо ви все ще вимірюєте власну продуктивність у кількості введених підказок, зміна мислення з кроку один ще не відбулася повністю, незалежно від того, скільки циклів ви технічно побудували.
Крок 20: Навчіть когось іншого п'яти дій
Останній крок насправді вже не про ваші власні системи. Це підтвердження того, що ви дійсно засвоїли зміну, пояснивши її комусь іншому, не вдаючись до жаргону. Виявлення, передача, верифікація, персистентність, планування. Якщо ви можете провести іншу людину через побудову її власного першого циклу, використовуючи лише ці п'ять дій та описані вище кроки, ви здійснили справжній перехід, який описує ця дорожня карта. Ви більше не людина всередині циклу, яка вводить наступну інструкцію. Ви людина, яка його спроєктувала, яка стоїть зовні та спостерігає, як він працює.
Чотири витрати, які непомітно накопичуються, якщо пропускати кроки
Варто завершити попередженням, оскільки пропуск кроків у цій дорожній карті не призводить до гучних збоїв, він призводить до тихих збоїв, які проявляються лише набагато пізніше.
Борг верифікації накопичується, коли ви пропускаєте кроки 6 і 7, будуючи цикли без справжнього Судді або без справжньої об'єктивної істини. Цикл виглядає так, ніби він працює, тому що результат виглядає добре, аж до того моменту, поки помилка не накопичується непомітно протягом десятків запусків, перш ніж хтось її помітить.
Гниття розуміння настає, коли ви пропускаєте крок 20, запускаючи цикли, які ви колись побудували, але більше не могли б пояснити або налагодити, якби вони зламалися, тому що вам ніколи не довелося внутрішньо засвоїти, чому існує кожна частина.
Когнітивна капітуляція відбувається, коли крок 1 ніколи не реалізується по-справжньому, коли ви продовжуєте вручну перевіряти кожен результат за звичкою, ще довго після того, як система верифікації вже довела свою спроможність, зводячи нанівець всю мету створення системи.
Токенний вибух — це те, що відбувається, коли ви пропускаєте крок 10, запускаючи цикли без справжньої умови зупинки, дізнаючись про реальну вартість лише тоді, коли приходить рахунок.
Кожна з цих витрат є запобіжною, і кожна з них запобігається однією й тією ж дисципліною. Будуйте кроки по порядку. Не пропускайте ті, які здаються непривабливими. Нудні кроки — визначення виконання, умова зупинки, об'єктивна істина — це ті, які насправді виконують роботу. Частини, що звучать цікаво, — хитра підказка, вигадана архітектурна діаграма — мають набагато менше значення, ніж те, чи знає побудована вами система, коли вона права, коли вона неправа та коли потрібно зупинитися.
У цьому вся різниця між тим, хто дає підказки, і системним дизайнером. Не кмітливість. Дисципліна щодо частин, які нудно будувати та легко пропускати.
Підписуйтеся на @cyrilXBT, щоб отримати точні шаблони циклів і конфігурації Будівельник-Суддя-Менеджер для кожного кроку цієї дорожньої карти.
