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