Средний

15 мин

1

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

Loop Engineering: сборка небольшой системы, которая сама находит задачу, передаёт её агенту, проверяет результат, фиксирует, что произошло, и решает, что делать дальше. Систему проектируют один раз, дальше она сама промптит агента.

Материал собран из инженерной документации Anthropic, эссе Эдди Османи (Addy Osmani) о loop engineering и недавних замеров продуктивности.

Три уровня:

1. Понять, нужен ли вообще loop

2. Разобрать пять базовых блоков

3. Собрать минимальный рабочий loop, который не выйдет из-под контроля

Часть 1. Зачем это нужно и как себя проверить

1. Loop engineering: замена себя в роли промптера

Османи делит процесс на шесть частей: автоматизация запуска, изоляция через worktree, project knowledge через skills, доступ к внешним инструментам через MCP, разделение ролей между sub-агентами и состояние, которое переживает перезапуск.

Anthropic сообщает, что инженеры компании теперь мержат в восемь раз больше кода в день, чем в 2024 году. Сама компания называет эту цифру «почти наверняка переоценкой реального прироста продуктивности». Число спорное. Механизм не спорный: точка приложения усилий сдвинулась с написания промптов на проектирование системы, которая промптит сама.

2. Тест из четырёх условий перед тем, как строить что-либо

Loop оправдывает себя при выполнении четырёх условий одновременно. Если хотя бы одно условие не выполняется, затраты на loop превышают выгоду от него. Честная оценка из разбора AlphaSignal, которую обычно пропускают авторы восторженных постов в соц.сетях.

Условия по порядку:

1. Задача повторяется. Loop распределяет затраты на настройку по множеству запусков. Для разовой работы хороший промпт быстрее и дешевле. Если задача не повторяется хотя бы раз в неделю, это не loop, а скрипт, который запустили один раз.

2. Проверка автоматизирована. Loop нужен механизм, который может признать работу неудачной без участия человека: тестовый набор, проверка типов, линтер, сборка. Без автоматической проверки человек снова читает каждый дифф, то есть выполняет ту работу, которую должен убрать loop.

3. Бюджет токенов выдерживает потери. Loop перечитывает контекст, повторяет попытки, исследует пространство решений. Это сжигает токены независимо от того, доехала ли итерация до результата. Техника масштабируется вместе с бюджетом: тем, у кого токены фактически бесплатны, она кажется очевидной, тем, у кого тарифный план с лимитом, рискованной.

4. У агента есть инструменты уровня senior-инженера. Логи, среда для воспроизведения, возможность запустить написанный код и увидеть, что ломается. Без этого loop итерирует наугад.

3. Кто выигрывает, кто теряет: loop работает на тех, кто может платить

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

Кому это действительно выгодно:

1. Командам с повторяющейся, машинно-проверяемой работой и бюджетом на её прогон: непрерывный разбор тестов, обновление зависимостей, проходы линт-и-фикс, черновики PR из issue в кодовой базе с сильным покрытием тестами.

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

3. Командам, уже работающим async-first с мультиагентными паттернами.

Кому стоит подождать:

1. Соло-разработчикам на дешевых тарифах: счёт за токены придёт раньше прироста продуктивности.

2. Тем, кто работает с кодом без автоматической проверки. Loop без реальной проверки означает, что агент соглашается сам с собой по кругу, итог известен заранее.

3. Командам, чьё реальное ограничение: пропускная способность ревью, а не скорость печати. Loop генерирует больше кода. Если ревью уже было узким местом, очередь станет только длиннее.

4. Для разовых задач, исследовательской работы и всего, где «готово» определяется человеческим суждением, один точно сформулированный промпт всё ещё выигрывает.

Честный TL;DR этого материала: loop engineering реален, но большинству разработчиков он пока не нужен.

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

4. Проверка за 30 секунд

Тест из четырёх условий в шаге 2 решает вопрос стратегически: применять loop вообще или нет. Чек-лист ниже работает тактически, на уровне конкретной задачи: его прогоняют перед тем, как превращать задачу в loop. Если не отметили хотя бы один пункт, то оставляйте как ручной промпт.

1. Задача повторяется минимум раз в неделю. Реже: затраты на настройку никогда не окупятся.

2. Тест, проверка типов, сборка или линтер могут отклонить плохой результат. Без автоматического шлюза агент сам себе ставит оценку за домашнее задание.

3. Агент может запустить изменённый код. Без среды воспроизведения итерация идёт наугад.

4. У loop есть жёсткий критерий остановки: бюджет токенов, лимит итераций или ограничение по времени. Без неё loop работает, пока кто-то не заметит огромный счёт на оплату.

Перед merge, деплоем или изменением зависимостей результат проверяет человек. Всё необратимое требует ручного одобрения перед действием.

Хорошие первые loopы:

1. Разбор сбоев CI: по ночам сканировать сбои, классифицировать причины, готовить черновики фиксов для простых случаев.

2. PR с обновлением зависимостей: раз в неделю искать обновления, тестировать совместимость, открывать PR.

3. Проходы линт-и-фикс: при каждом открытии PR применять автоматические правки стиля.

4. Воспроизведение нестабильных тестов: повторять, пока гипотеза не выдержит проверку.

5. Черновики PR из issue в коде с сильными тестами, где плохой результат отклоняет тестовый набор.

Плохие первые loop, для них обязательно нужен человек с головой на плечах:

1. Архитектурные переписывания.

2. Код авторизации или платежей.

3. Продакшен-деплои.

4. Размытая продуктовая работа.

5. Всё, где «готово» определяется суждением.

Часть 2. Пять базовых блоков

5. Автоматизации: пульс системы

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

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

1. Codex. Вкладка Automations: выбрать проект, задать промпт, задать частоту, выбрать локальный чекаут или фоновый worktree. Прогоны, которые что-то находят, попадают в инбокс Triage, прогоны без находок архивируются сами.

2. Claude Code. Три примитива, складывающиеся в одну схему: /loop для повтора внутри одной сессии, запланированные задачи Desktop для устойчивости к перезапуску, Routines для облачных прогонов с выключенным ноутбуком. В паре с hooks для событий жизненного цикла.

Внутри автоматизации два примитива разделяют работающие loop от дорогих:

1. /loop перезапускается по расписанию. Использовать, когда нужны регулярные проверки независимо от состояния.

2. /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.

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

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

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

1. Codex встраивает поддержку worktree: несколько потоков работают с одним репозиторием одновременно без конфликтов.

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

Worktree убирает механический конфликт файлов, но ограничением остаётся человек. Пропускная способность ревью определяет, сколько параллельных агентов реально можно запустить, а не возможности инструмента.

7. Skills: знание о проекте, записанное раз и читаемое каждый прогон

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

Почему это особенно важно для loop: без skills loop с нуля восстанавливает весь контекст проекта на каждом цикле. С 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.

8. Коннекторы: loop касается реальных инструментов через MCP

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

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

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

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

1. GitHub: читать репозитории, создавать ветки, открывать PR, комментировать issue, реагировать на webhook-события. Самый значимый результат первого дня для любого кодового loop.

2. Linear или Jira: обновлять тикеты по ходу работы loop, привязывать PR к issue, закрывать пункты автоматически после успешной проверки.

3. Slack: публиковать результаты разбора, пинговать людей при эскалации, резюмировать ночные прогоны утром.

4. Sentry или другой трекер ошибок: давать loop расследовать живые алерты и готовить фиксы для частых случаев.

9. Sub-агенты: исполнитель отдельно от проверяющего

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

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

Как sub-агенты устроены в обоих инструментах:

1. Codex запускает sub-агентов только по запросу, выполняет их параллельно, затем сворачивает результаты в один ответ. Собственные агенты описывают TOML-файлами в .codex/agents/: имя, описание, инструкции, опционально модель и уровень reasoning effort. Security-ревьюер может работать на сильной модели с высоким effort, пока explorer работает на быстрой read-only модели.

Claude Code делает то же через sub-агентов в .claude/agents/ и команды агентов, передающие работу друг другу. Типичное разделение: один агент исследует, другой реализует, третий проверяет соответствие спецификации.

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

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

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

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

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

# 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

Два паттерна для размещения файла состояния:

1. Markdown в репозитории, STATE.md в корне или внутри .claude/. Версионируется, простой, диффы читаются глазами. Подходит для соло или маленькой команды.

2. Внешняя система (Linear, GitHub Issues, база данных): переживает работу с разными репозиториями, доступна для запросов, поддерживает видимость для всей команды. Подходит для продакшен-loop, где результаты работы должны видеть несколько человек.

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

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

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

1. Одна автоматизация: запуск по расписанию с понятным условием остановки. /loop в Claude Code или automation в Codex, в паре с /goal, когда нужно работать до выполнения заявленного условия.

2. Один skill: единственный SKILL.md, хранящий контекст проекта, который агент иначе восстанавливал бы с нуля каждый прогон.

3. Один файл состояния: markdown-файл или доска в Linear, фиксирующая, что сделано и что дальше. Завтрашний прогон продолжает, а не начинает заново.

4. Один шлюз: тест, проверка типов или сборка, автоматически отклоняющие плохую работу. Эта часть решает, помогает ли loop или просто тратит ресурсы.

5. Порядок важен: сначала добиться надёжного ручного прогона, превратить его в skill, обернуть в loop, затем поставить на расписание. Пропуск шагов часто становится причиной, почему loop ломаются в продакшене.

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

12. Ralph Wiggum loop: тихий провал

Это явление описал и назвал инженер Джеффри Хантли (Geoffrey Huntley). Смысл такой: агент должен слать токен завершения только когда задача реально готова. На практике он иногда шлёт его раньше времени, и loop останавливается на середине работы. Без жёсткой проверки этот косяк никто не замечает, а loop продолжает жрать ресурсы.

Ralph Wiggum loop возникает, когда:

1. Нет реальной проверки. Только второй агент, которого попросили «проверить», без объективного сигнала. Два оптимиста соглашаются друг с другом.

2. Мягкие условия завершения. «Готово» определяется суждением агента, а не тестом, сборкой или проверкой типов.

3. Нет жёсткой остановки. Loop работает, пока не сработает внешний ограничитель (лимит запросов, замеченный человеком счёт), а не до подтверждённого успеха.

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

Другие задокументированные сбои:

1. Дрейф цели в долгих сессиях. Каждый шаг суммаризации теряет информацию, ограничения вида «не делай X» исчезают к 47-му ходу. Как избежать: постоянный VISION.md или AGENTS.md, перечитываемый каждый прогон.

2. Self-preferential bias, склонность хвалить себя. Агент, написавший код, слишком добр к себе при оценке. Как избежать: отдельный sub-агент-проверяющий без доступа к рассуждениям исполнителя.

3. Агентная лень. Loop объявляет задачу «достаточно готовой» при частичном выполнении. Как избежать: /goal с объективным условием остановки, проверяемым свежей моделью.

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

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

1. Долг понимания (comprehension debt). Чем быстрее loop выпускает код, который человек не писал, тем больше расстояние между содержимым репозитория и тем, что человек понимает. Болезненный счёт приходит не в токенах. Он приходит в день, когда нужно дебажить систему, которую никто в команде не читал.

2. Когнитивная капитуляция. Желание перестать формировать собственное мнение и принимать всё, что вернул loop. Проектирование loop с включённым суждением лечит эту проблему, проектирование, чтобы не думать, её усиливает. Одно и то же действие, противоположный результат.

Меры против этого нетехнические:

1. Читать диффы. Тот, кто не читает, что производит loop, берёт в долг понимание всей системы под сложный процент.

2. Проверять выборочно. Брать несколько PR, открытых loop, и убеждаться, что тест, который их одобрил, действительно ловит тот сбой, который важен. Проверки со временем теряют точность.

3. Не подпускать loop к архитектурным решениям. Держать его на маленьких, машинно-проверяемых изменениях.

4. Проектировать loop вместе с коллегой. Второй взгляд при проектировании ловит слепые зоны, которые иначе loop будет использовать бесконечно.

14. Налог на безопасность. Без присмотра loop становится поверхностью атаки

Loop, работающий без присмотра, одновременно работает как поверхность атаки без присмотра.

Модель угроз, от которой нужно защищаться:

1. Сгенерированный код уходит в продакшен без ревью. Loop открывает PR быстрее, чем человек успевает их прочитать. Без этапа, включающего проверки безопасности (SAST, аудит зависимостей, поиск секретов), небезопасный код мержится автоматически.

2. Skills как вектор инъекции. Loop, автоматически устанавливающий skills, наследует любой prompt injection, спрятанный в их описаниях. Источники skills нужно проверять перед установкой.

3. Credentials в логах. Подробное логирование во время долгого прогона разбрасывает секреты по логам, которые никто не мониторит. В продакшен-loop подробное логирование нужно отключать и тщательно проверять то, что всё-таки попадает в лог.

4. Расползание прав доступа. Loop, протестированный с правами только на чтение, получает «всего одно» право на запись для удобства, и это право больше никто не пересматривает. Права доступа нужно перепроверять каждые 30 дней.

Ошибки, превращающие loop в способ слить деньги

1. Запуск loop без теста из четырёх условий. Шаг 2 существует не просто так, большинство разработчиков проваливают хотя бы одно условие.

2. Отсутствие объективного шлюза. Второй агент, которого попросили «проверить», без теста, проверки типов или сборки, это просто второй оптимист.

3. Один агент пишет и проверяет одновременно. Self-preferential bias: исполнитель сам себе ставит оценку, и она всегда отличная.

4. Отсутствие файла состояния. Завтрашний прогон стартует с нуля вместо того, чтобы продолжить.

5. Размытые условия остановки. «Готово, когда выглядит хорошо» не работает никогда. Нужен тест, проверка типов или успешная сборка.

6. Отсутствие лимита на токены. Loop перечитывает контекст и повторяет попытки. Без лимита амбициозные loop сжигают в 5-10 раз больше токенов, чем ожидалось.

7. Запуск тяжёлых проверочных loop на потребительском тарифе. Либо счёт за токены, либо лимит запросов догонит первым.

8. Автоматическая установка community-skills. 520 из 17 022 проверенных skills утекают credentials. Перед установкой нужно читать исходники.

9. Loop на задачах, требующих суждения. Архитектура, авторизация, платежи, размытые продуктовые решения. Loop держат на линт-и-фикс, а не на стратегии.

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

Точка приложения усилий сместилась. Работа тоже

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

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

Если тесты прошли, начинают с малого: одна автоматизация, один skill, один файл состояния, один шлюз. Сначала надёжный ручной прогон. Потом skill. Потом loop. Потом расписание. Порядок важен: пропуск шагов означает оплату системы, которую никто не понимает.

Работа не стала легче. Изменилось место, в котором находится точка приложения усилий инженеров.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!