Инженерия циклов: 14 шагов от промптера к дизайнеру циклов

Большинство разработчиков до сих пор промптят свои кодинг-агенты вручную. Они пишут, ждут, читают диф, снова пишут. 9 из 10 ни разу не написали ни одного цикла, который промптил бы агента за них. Никакой автоматизации, никакого файла состояния, никакого верификатора, никакого расписания. Точка приложения рычага сместилась — от набора промптов к проектированию систем, которые промптят сами. Это и есть путь от промптера к дизайнеру циклов за 14 шагов.

Это дорожная карта из 14 шагов, которая помогает сделать этот переход — собранная из инженерной документации Anthropic, большого материала Эдди Османи об инженерии циклов и свежих исследований с измерениями.

Три уровня: разобраться, нужен ли вам цикл в принципе; изучить пять строительных блоков; собрать самый маленький цикл, который работает и не вредит вам.

14 шагов. 3 уровня. Перестаньте промптить. Начните проектировать.

Часть 1 · Зачем это нужно и тест на необходимость

01. Инженерия циклов заменяет вас как промптера

Два года подряд способ получить что-то от кодинг-агента был один: напишите промпт, дайте контекст, прочитайте ответ, напишите следующий промпт. Агент был инструментом, и вы держали его в руках всё время. Эта эпоха заканчивается.

Инженерия циклов — это сборка небольшой системы, которая сама находит работу, передаёт её агенту, проверяет результат, фиксирует, что произошло, и решает, каким будет следующий шаг. Вы проектируете эту систему один раз. Дальше она промптит агента сама.

Эдди Османи раскладывает это на шесть частей:

Инженеры Anthropic сейчас вливают в продакшн в восемь раз больше кода в день, чем в 2024 году, — цифра, которую сама Anthropic называет «почти наверняка преувеличением реального прироста продуктивности».

Цифра спорная. Механизм — нет: точка приложения рычага сместилась от набора промптов к проектированию цикла, который промптит за вас.

02. Прогоните тест из 4 условий, прежде чем что-либо строить

Цикл оправдывает свою стоимость при четырёх условиях. Не выполнено хотя бы одно — и цикл обходится дороже, чем приносит. Честный взгляд из разбора AlphaSignal и та часть, которую большинство тредов в X пропускают:

Четыре условия простыми словами:

• Задача повторяется. Цикл размазывает стоимость своей настройки по множеству запусков. Для разовой задачи хороший промпт быстрее и дешевле. Если работа не повторяется хотя бы раз в неделю, у вас не цикл — у вас скрипт, который вы один раз запустили.
• Проверка автоматизирована. Циклу нужно что-то, что может забраковать работу без вашего участия. Набор тестов, проверка типов, линтер, сборка. Нет автоматической проверки — и вы снова в кресле, читаете каждый диф, то есть делаете ровно ту работу, которую цикл должен был убрать.
• Ваш бюджет на токены выдержит расход впустую. Циклы перечитывают контекст, делают повторные попытки, исследуют. Это жжёт токены независимо от того, поехало ли что-то в продакшн. Техника масштабируется вместе с бюджетом — поэтому она кажется очевидной тем, у кого токены практически бесплатны, и безрассудной тем, кто сидит на тарифе со счётчиком.
• У агента есть инструменты сеньора. Логи, среда для воспроизведения, возможность запустить написанный код и увидеть, что ломается. Без этого цикл итерируется вслепую.

03. Кто выигрывает, кто проигрывает — циклы на стороне тех, кто может тратить

Экономика здесь не универсальна. Те, кто называет инженерию циклов очевидной, обычно располагают токенами без счётчика. Те, для кого это безрассудство, как правило, сидят на потребительском тарифе за $20 и пытаются гонять тяжёлые проверочные циклы, не упираясь в лимиты и не получая внезапный счёт.

Кому это реально выгодно на практике:

• Командам с повторяющейся, машинно-проверяемой работой и бюджетом, чтобы её гонять, — постоянная сортировка падений тестов, обновление зависимостей, проходы «линтер + автофикс», черновики PR из задач на кодовой базе с хорошим покрытием тестами.
• Кодовым базам с сильными существующими тестами. Если задачу мог бы сделать джуниор по чек-листу, а набор тестов поймал бы его ошибки, — цикл подходит.
• Async-first командам, где уже используются мультиагентные паттерны. Для них рутины — недостающий слой оркестрации.

Кому пока стоит воздержаться:

• Соло-разработчикам на потребительских тарифах — счёт за токены приходит раньше, чем прирост продуктивности.
• Всем, кто работает с кодом без автоматической проверки. Цикл без реальной проверки — это агент, который раз за разом соглашается сам с собой.
• Командам, чьё настоящее ограничение — пропускная способность ревью, а не скорость набора текста. Цикл генерирует больше кода; если ревью и так было узким местом, очередь станет только длиннее.

Для разовых задач, исследовательской работы и всего, где «готово» — это вопрос суждения, по-прежнему выигрывает один точный промпт. Честная версия этой статьи такая: инженерия циклов реальна, но большинству разработчиков она пока не нужна.

04. Проверка цикла за 30 секунд

Тест из 4 условий на шаге 2 — это стратегическое решение. Это тактическое: чек-лист, который вы прогоняете на конкретной задаче, прежде чем превращать её в цикл.

Не отмечен хотя бы один пункт — оставьте задачу ручным промптом.

1. Задача случается минимум раз в неделю. Реже — стоимость настройки никогда не окупится.
2. Тест, проверка типов, сборка или линтер могут отклонить плохой результат. Нет автоматического гейта — агент проверяет сам себя.
3. Агент может запустить код, который меняет. Нет среды для воспроизведения — итерация идёт вслепую.
4. У цикла есть жёсткий стоп. Бюджет токенов, лимит итераций или времени. Без него цикл крутится, пока кто-нибудь не заметит счёт.
5. Человек проверяет перед мержем, деплоем или изменением зависимостей. Всё необратимое требует человеческого approval-гейта перед действием.

Хорошие первые циклы:

• Сортировка падений CI — ночью просканировать падения, классифицировать причины, набросать PR с фиксами для простых случаев.
• PR с обновлением зависимостей — еженедельно искать апдейты, проверять совместимость, открывать PR.
• Проходы «линтер + автофикс» — на каждое открытие PR автоматически применять стилевые правки.
• Воспроизведение флапающих тестов — крутить цикл, пока гипотеза не переживёт тест.
• Черновики PR из задач на коде с сильными тестами, где плохой результат отбраковывается набором тестов.

Плохие первые циклы — здесь нужен человек в кресле:

• Переписывание архитектуры
• Код авторизации или платежей
• Продакшн-деплои
• Размытые продуктовые задачи
• Всё, где «готово» — это вопрос суждения

Часть 2 · Пять строительных блоков

05. Автоматизации: сердцебиение

Автоматизации — это то, что делает цикл настоящим циклом, а не одним запуском, который вы как-то раз сделали. Они срабатывают по расписанию, по событию или по условию-триггеру. Это сердцебиение — всё остальное в цикле висит на нём.

Как это выглядит в двух инструментах, которые имеют значение:

• Codex. Вкладка Automations — выберите проект, задайте промпт, задайте частоту, выберите локальный checkout или фоновый worktree. Запуски, которые что-то нашли, попадают в инбокс Triage; запуски, которые ничего не нашли, сами уходят в архив.
• Claude Code. Три примитива, которые складываются в ту же форму: /loop для частоты в рамках сессии, запланированные задачи Desktop для переживания перезапуска, Routines для облачных запусков с выключенным ноутбуком. В пару к ним — хуки для событий жизненного цикла.

Два примитива внутри автоматизации, которые отделяют рабочие циклы от дорогих:

• /loop перезапускается по частоте. Используйте, когда нужны регулярные проверки независимо от состояния.
• /goal продолжает работу, пока написанное вами условие действительно не станет истинным. Завершение проверяет отдельная небольшая модель, поэтому агент, написавший код, не оценивает его сам.

Это разделение «исполнитель против проверяющего», применённое к самому условию остановки.

> /loop 30m /goal All tests in test/auth pass and lint is clean.
  Scan src/auth for new failures, propose fixes in claude/auth-fixes,
  open draft PR when goal condition holds.

▲ Claude
  CronCreate(*/30 * * * * : auth quality loop)
  Stop condition: tests pass + lint clean (verified by checker)
✓ Scheduled. Will continue past intermediate completions
  until /goal condition is met by independent checker.

06. Worktree-ы: параллельность без хаоса

Как только вы запускаете больше одного агента, файлы начинают сталкиваться. Два агента, пишущие в один файл, — та же головная боль, что и два инженера, коммитящие в одни и те же строки, не договорившись.

Git worktree это чинит — отдельная рабочая директория на своей ветке, делящая ту же историю репозитория, так что правки одного агента физически не могут задеть checkout другого.

Как это проявляется в обоих инструментах:

• Codex встраивает поддержку worktree — несколько тредов работают с одним репозиторием одновременно, не наталкиваясь друг на друга.
• Claude Code даёт git worktree напрямую, флаг --worktree для запуска сессии в собственном checkout и настройку isolation: worktree для субагентов, чтобы каждый помощник получал свежий checkout, который сам за собой убирает.

Worktree-ы убирают механическое столкновение, но потолок — по-прежнему вы. Сколько параллельных агентов вы реально потянете, решает ваша пропускная способность ревью, а не инструмент.

07. Skills: запишите знание о проекте один раз, читайте на каждом запуске

Skill — это способ перестать каждую сессию заново объяснять один и тот же контекст проекта, как золотая рыбка. Оба инструмента используют один формат: папка с SKILL.md внутри, где лежат инструкции и метаданные, плюс опциональные скрипты, справочники и ассеты.

Почему это важно именно для циклов: цикл без skills заново выводит весь контекст проекта с нуля каждый круг. Со skills намерение накапливается.

Договорённости, шаги сборки, «мы так не делаем из-за того одного инцидента» — записаны один раз снаружи, прочитаны каждым запуском.

name: ci-triage
description: Classify CI failures by root cause (env, flake, real bug,
  dependency, infra), draft fixes for the easy ones, escalate the rest.
  Trigger whenever a workflow run fails or on the morning triage loop.
---

# CI triage skill

## Classification rules
- env: missing secret, wrong env var, infra not provisioned. # human
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: failure tied to a version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate

## Fix patterns
- Auth tests → check src/auth/middleware first
- Database tests → verify migration applied in CI env
- E2E tests → check selectors against the latest UI snapshot

## Never do
- Disable failing tests — always file as escalation instead
- Modify CI config without human approval
- Touch src/payments/ or src/billing/ (in claude/permissions.md)

## State
Update STATE.md after each run: file paths checked, classifications,
PRs opened, items escalated.

08. Коннекторы: цикл дотягивается до ваших реальных инструментов через MCP

Цикл, который видит только файловую систему, — крошечный цикл. Коннекторы, построенные на Model Context Protocol (MCP), позволяют агенту читать ваш трекер задач, запрашивать базу данных, стучаться в staging-API, кидать сообщение в Slack.

И Codex, и Claude Code говорят на MCP, поэтому коннектор, написанный для одного, обычно просто работает в другом.

Это разница между агентом, который говорит «вот фикс», и циклом, который открывает PR, привязывает тикет в Linear и пингует канал, как только CI позеленел. Коннекторы — причина, по которой цикл может действовать внутри вашего реального окружения, а не просто рассказывать, что он сделал бы, если бы мог.

Коннекторы, которые окупаются быстрее всего в работе с циклами, по порядку:

• GitHub — читать репозитории, создавать ветки, открывать PR, комментировать задачи, реагировать на события вебхуков. Самый большой выигрыш первого дня для любого кодового цикла.
• Linear или Jira — обновлять тикеты по ходу цикла, привязывать PR к задачам, автоматически закрывать пункты, когда проверка пройдена.
• Slack — постить результаты сортировки, пинговать людей при эскалациях, утром подводить итоги ночных запусков.
• Sentry / ваш трекер ошибок — позволить циклу разбирать живые алерты и набрасывать фиксы для самых частых.

09. Субагенты: держите исполнителя подальше от проверяющего

Самое полезное структурное решение в цикле — с большим отрывом — это разделить агента, который пишет, и агента, который проверяет. Формулировка Османи точна: модель, написавшая код, «слишком добра, когда оценивает собственную домашку». Второй агент с другими инструкциями, а иногда и другой моделью, ловит то, во что первый сам себя уговорил.

Это паттерн «оценщик-оптимизатор» из инженерного поста Anthropic от декабря 2024 года под новым именем. Одна модель генерирует, другая критикует, повторить. Словарь, который завирусился в 2026-м, был задокументирован восемнадцатью месяцами раньше.

Как субагенты выглядят в обоих инструментах:

• Codex порождает субагентов только когда вы просите, гоняет их одновременно, затем сворачивает результаты в один ответ. Своих агентов вы описываете TOML-файлами в .codex/agents/ — имя, описание, инструкции, опционально модель и уровень рассуждения. Ваш security-ревьюер может быть сильной моделью на высоком усилии, а исследователь — каким-нибудь быстрым read-only.
• Claude Code делает то же через субагентов в .claude/agents/ и команды агентов, передающие работу друг другу. Привычное разделение: один исследует, один реализует, один сверяет со спецификацией.

Почему это важно именно внутри цикла: цикл работает, пока вы не смотрите, поэтому проверяющий, которому вы реально доверяете, — единственная причина, по которой можно уйти. Субагенты жгут больше токенов, потому что каждый делает собственную работу с моделью и инструментами, — тратьте их там, где второе мнение стоит оплаты.

Часть 3 · Соберите правильно или не собирайте вовсе

10. Файл состояния — агент забывает, файл нет

Это та часть, которая звучит слишком тупо, чтобы иметь значение, и на деле является хребтом любого рабочего цикла. Markdown-файл, доска в Linear, JSON-состояние — что угодно, что живёт вне одного разговора и хранит, что сделано и что дальше.

Почему это важно: у агентов по умолчанию короткая память. То, что они узнали в этой сессии, завтра исчезнет, если не записать. Правило Османи: агент забывает, репозиторий нет. Цикл без устойчивого состояния перезапускается каждый круг; цикл с состоянием возобновляется.

# Loop state · ci-triage

## Last run
2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated

## In progress
- claude/fix-auth-token-refresh — tests passing locally, awaiting CI
- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring

## Completed today
- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 → merged

## Escalated to humans
- src/billing/refund.ts — tests failing in 3 ways, root cause unclear
- ci/staging-runner — infra timeouts, not a code issue

## Lessons learned (write here, not in chat)
- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.
- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing.

## Stop conditions met since last review
- /goal "all tests pass + lint clean" achieved on commit 3a7b8c1 at 02:14 UTC

Два паттерна, где живёт файл состояния:

• Markdown в репозитории — STATE.md в корне или внутри .claude/. Под версионным контролем. Просто. Читается из дифов. Лучше всего для соло или небольшой команды.
• Внешняя система (Linear, GitHub Issues, база данных) — переживает переезды между репозиториями, поддаётся запросам, даёт видимость всей команде. Лучше всего для продакшн-циклов, где за работой цикла должны следить несколько человек.

Для долгоиграющих циклов, рискующих сползти с цели, к файлу состояния добавьте постоянную высокоуровневую спецификацию — VISION.md или AGENTS.md, — которую агент перечитывает на каждом запуске. Состояние говорит агенту, где он находится. Спецификация говорит, куда ему идти.

11. Минимально жизнеспособный цикл

Если вы прошли тест из 4 условий на шаге 2, сначала соберите самый маленький рабочий цикл, прежде чем что-то усложнять. Четыре части, никакого роя.

Четыре части простыми словами:

• Одна автоматизация. Запланированный запуск, который срабатывает по частоте и останавливается по чёткому условию. Используйте /loop в Claude Code или автоматизацию в Codex. В пару — /goal, когда нужно крутить, пока заявленное условие не выполнится.
• Один skill. Единственный SKILL.md, который хранит контекст проекта, иначе агент выводил бы его с нуля каждый запуск.
• Один файл состояния. Markdown-файл или доска в Linear, фиксирующие, что сделано и что дальше. Завтрашний запуск возобновляется, а не начинает заново.
• Один гейт. Тест, проверка типов или сборка, которые автоматически бракуют плохую работу. Именно эта часть решает, помогает цикл или просто тратит.

Порядок важен: сначала добейтесь надёжности одного ручного запуска. Превратите его в skill. Оберните в цикл. Затем поставьте на расписание. Перепрыгивать — так циклы и падают в продакшене.

Метрика, которая имеет значение, — стоимость одного принятого изменения, а не потраченные токены, не число попыток, не количество запланированных циклов. Если доля принятых изменений ниже 50%, вы делаете ту работу по ревью, от которой цикл должен был вас избавить, — и цикл проигрывает.

12. Цикл Ральфа Виггама — циклы, которые падают тихо

Инженер Джеффри Хантли задокументировал этот режим отказа и дал ему имя. Агент, который должен выдавать токен завершения только когда закончил, выдаёт его рано, и цикл выходит на полусделанной работе. Без жёсткого гейта циклы падают тихо и продолжают тратить.

Цикл Ральфа Виггама случается, когда:

• Нет реального верификатора. Только второй агент, которого попросили «поревьюить», без объективного сигнала. Два оптимиста соглашаются друг с другом.
• Мягкие условия завершения. «Готово» определяется суждением агента, а не тестом, сборкой или проверкой типов.
• Нет жёстких стопов. Цикл крутится, пока его не убьёт что-то внешнее (лимит запросов, ваше внимание), а не пока успех не подтверждён.

Лечение — гейт из шага 11: что-то объективное, что может забраковать работу. Тест, который проходит или падает. Сборка, которая компилируется или нет. Линтер, возвращающий ноль или не ноль. Не верификатор с мнением.

Другие измеренные режимы отказа, которые стоит знать:

• Сползание с цели в долгих сессиях. Каждый шаг суммаризации теряет информацию; ограничения «не делай X» исчезают к 47-му ходу. Митигация: постоянный VISION.md или AGENTS.md, перечитываемый на каждом запуске.
• Смещение в свою пользу. Агент, написавший код, слишком добр к собственной домашке. Митигация: отдельный субагент-верификатор без доступа к рассуждениям исполнителя.
• Агентская лень. Цикл объявляет «достаточно готово» на частичном завершении. Митигация: /goal с объективным условием остановки, которое проверяет свежая модель.

13. Долг понимания и когнитивная капитуляция

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

• Долг понимания. Чем быстрее цикл выкатывает код, который вы не писали, тем больше разрыв между тем, что лежит в репозитории, и тем, что вы понимаете. Болезненный счёт — не за токены. Это день, когда вам придётся дебажить систему, которую никто в команде не читал.
• Когнитивная капитуляция. Тяга перестать формировать мнение и принимать всё, что вернул цикл. Проектирование цикла — лекарство, когда вы делаете это с суждением, и ускоритель, когда делаете, чтобы не думать. Одно и то же действие, противоположный результат.

Митигации здесь не технические:

• Читайте дифы. Если вы не читаете то, что выкатывает цикл, вы берёте долг понимания под сложный процент.
• Выборочно проверяйте гейт. Возьмите несколько PR, открытых циклом, и убедитесь, что тест, который их одобрил, реально ловит тот режим отказа, который вас волнует. Гейты гниют.
• Не пускайте цикл в архитектурную работу. Держите его на маленьких, машинно-проверяемых изменениях. Как только вы пустите его к вопросам суждения, долг понимания ускоряется.
• Проектируйте циклы в паре с коллегой. Вторая пара глаз при проектировании ловит слепые зоны, которые иначе цикл будет эксплуатировать вечно.

14. Налог на безопасность — необслуживаемый цикл это необслуживаемая поверхность атаки

Цикл, работающий без присмотра, — это ещё и поверхность атаки, работающая без присмотра. Модель угроз, от которой ваш цикл обязан защищаться:

• Сгенерированный код едет без ревью. Цикл открывает PR быстрее, чем человек успевает читать. Без гейта, включающего проверки безопасности (SAST, аудит зависимостей, сканирование секретов), небезопасный код мержится автоматически.
• Skills как вектор инъекций. Цикл, который сам ставит skills, наследует каждую промпт-инъекцию, спрятанную в их описаниях. Проверяйте источники skills перед установкой.
• Учётные данные в логах. Подробное логирование во время долгого цикла раскидывает секреты по логам, за которыми вы не следите. Отключайте verbose-логирование в продакшн-циклах; чистите то, что всё-таки логируется.
• Расползание прав. Цикл, протестированный с правами только на чтение, получает «всего одно» право на запись ради удобства, а потом его никто не пересматривает. Пересматривайте права каждые 30 дней.

Ошибки, которые превращают циклы в денежные ямы

• Сборка цикла без теста из 4 условий. Шаг 2 существует не просто так. Большинство разработчиков заваливают хотя бы одно условие.
• Нет объективного гейта. Второй агент, которого попросили «поревьюить» без теста, проверки типов или сборки, — просто второй оптимист.
• Один агент и пишет, и проверяет. Смещение в свою пользу. Исполнитель оценивает свою домашку, и это всегда «пятёрка».
• Нет файла состояния. Завтрашний запуск начинает с нуля вместо возобновления.
• Размытые условия остановки. «Готово, когда выглядит хорошо» никогда не срабатывает. Используйте тест, проверку типов или зелёную сборку.
• Нет потолка бюджета токенов. Циклы перечитывают контекст и делают повторы. Без потолка амбициозные циклы сжигают в 5–10 раз больше токенов, чем вы ждали.
• Запуск циклов на потребительском тарифе с тяжёлой проверкой. Счёт за токены или лимит запросов — один из них вас настигнет.
• Автоустановка community-skills. 520 из 17 022 проаудированных skills сливают учётные данные. Читайте исходник перед установкой.
• Циклы на работе с вопросами суждения. Архитектура, авторизация, платежи, размытые продуктовые решения. Держите цикл на «линтер + автофикс», а не на стратегии.
• Не читать дифы. Долг понимания под сложный процент. День, когда вы дебажите систему, которую никто не читал, обходится дороже, чем когда-либо стоили токены.

Заключение: рычаг сместился. Ваша работа тоже

Два года рычаг в работе с кодинг-агентами был на промпте. Лучше промпты, лучше контекст, лучше результат с одного захода.

Эта фаза заканчивается. Агенты стали достаточно хороши, чтобы следующая точка приложения рычага оказалась этажом выше: система, которая решает, над чем им работать, когда, с каким гейтом и какое состояние переживёт между запусками.

Но честная версия этой истории не в том, что всем нужно бросаться строить циклы. Большинству разработчиков цикл пока не нужен — пока задача не повторяется, проверка не автоматизирована, бюджет не выдерживает расход впустую, а у агента нет инструментов сеньора. Не выполнено хотя бы одно условие — и цикл обходится дороже, чем приносит.

Если вы прошли тест, стройте маленькое. Одна автоматизация. Один skill. Один файл состояния. Один гейт. Добейтесь надёжности ручного запуска. Превратите его в skill. Оберните в цикл. Затем поставьте на расписание. Порядок важен. Перепрыгнете — будете платить за систему, которую никто не понимает.

Мысль Черни не в том, что работа стала легче. В том, что сместилась точка приложения рычага. Постройте цикл. Останьтесь инженером.

По теме

• Статья: Карпатый объяснил, почему вайб-кодинг и агентный инжиниринг — два разных мира
• Блог: Codex /goal: locked-in режим для ИИ и 10 готовых сценариев
• База знаний: Skills: Codex vs Claude Code — сравнение и совместимость

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov