Всё что тебе нужно знать о агентских циклах

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

Начать стоит с того, что большинство вайбкодеров до сих пор управляют ИИ-агентами вручную.

Они пишут промпт, ждут ответа, читают изменения в коде (это еще в идеале) и пишут следующий промпт. 90% из них ни разу не создавали цикл, который сам ставит агенту очередную задачу.

Раньше сам факт использования ИИ давал тебе преимущество в работе.

Но теперь преимущество создается по-другому. Его получают те, кто умеет проектировать системы, способные самостоятельно ставить задачи агенту.

Такой подход называется loop engineering, или проектированием агентных циклов.

Ниже представлен роадмап из 14 шагов, как строить такие циклы.

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

В общем, если ты устал бесконечно писать промпты и хочешь начать проектировать весь процесс работы сразу, это статья для тебя.

Оглавление:

I. Зачем нужен цикл и как понять, нужен ли он тебе
II. Пять основных элементов
III. Как собрать цикл и не навредить проекту
IV. Ошибки, которые превращают циклы в потерю денег
V. Заключение

I. Зачем нужен цикл и как понять, нужен ли он тебе

1. Проектирование цикла экономит время

В последние один-два года работа с ИИ-агентом выглядела примерно одинаково.

Ты формулировал задачу, передавал контекст, изучал результат и писал следующий промпт. Агент оставался инструментом, которым приходилось постоянно управлять.

Теперь эта схема меняется. Агенты наконец-то получают agency.

Агентный цикл - это небольшая система, которая самостоятельно:

1. Находит следующую задачу.
2. Передает ее агенту.
3. Проверяет результат.
4. Записывает, что произошло.
5. Выбирает следующее действие.
6. Останавливается, когда выполнено заданное условие.

Ты один раз проектируешь эту систему. После этого уже она ставит задачи агенту.

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

2. Перед началом проверь четыре обязательных условия

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

Задача регулярно повторяется

Настройка цикла требует времени. Реально много времени. Эти затраты оправданы только тогда, когда система запускается много раз.

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

Результат можно проверить автоматически

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

Для этого можно сделать набор тестов. Если автоматической проверки нет, тебе все равно придется сидеть перед экраном и читать каждое изменение в коде.

В таком случае реально стоит задуматься, имеет ли смысл создавать цикл?

Бюджет выдерживает лишние расходы

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

Поэтому людям с дешевыми, локальными моделями этот подход кажется очевидным.

Если ты сидишь на подписке Claude Code / Codex по $20 в месяц и работаешь только циклами, лимиты могут кончаться быстро.

У агента есть рабочее окружение

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

Без этих инструментов цикл работает вслепую. Агент меняет код, но не понимает, исправил ли он проблему или создал новую.

В 2026 году это уже само собой разумеется, но на всякий случай оставлю этот пункт.

3. Кто выигрывает от циклов, а кто сливает деньги

Экономика агентных циклов работает не для всех одинаково.

На практике больше всего выигрывают три группы.

Во-первых, команды с повторяющимися задачами, которые легко проверяются машиной. Например, регулярный разбор ошибок, обновление зависимостей и подготовка черновиков PR по задачам.

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

В-третьих, команды, которые уже привыкли к асинхронной работе и нескольким агентам. Им часто не хватает только общего механизма, который запускает процессы и синхронизирует их между собой.

Кому пока лучше отказаться от этой идеи?

Одиночным разработчикам с дешевым пользовательским тарифом (обычно это $20 в месяц). Тогда прирост продуктивности можно почти не заметить, а токены будут таять очень быстро.

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

Командам, у которых bottleneckом уже стала проверка кода. Цикл создаст больше изменений, но очередь на ревью только вырастет.

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

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

4. Проверка конкретной задачи за 30 секунд

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

Если хотя бы один пункт не выполняется, выбирай ручной промпт:

1. Задача возникает не реже одного раза в неделю. При более редких запусках настройка может никогда не окупиться.
2. Плохой результат могут отклонить тест, проверка типов и т.д. Без автоматической проверки агент оценивает собственную работу.
3. Агент может запустить измененный код. Без воспроизводимого окружения он действует вслепую.
4. У цикла есть жесткий предел. Это может быть бюджет токенов, число итераций или ограничение по времени. Без такого предела система работает, пока кто-нибудь не заметит счет.
5. Перед деплоем или изменением зависимостей результат проверяет человек. Любое необратимое действие требует явного одобрения.

Для первого цикла хорошо подходят такие задачи:

• Разбор сбоев. Ночью система изучает ошибки, определяет причины и готовит черновики исправлений для простых случаев.
• Обновление зависимостей. Раз в неделю агент ищет новые версии, проверяет совместимость и открывает PR.
• Подготовка черновиков контента. Агент пишет первый вариант статьи по ТЗ, второй агент проверяет структуру, фактуру, тон и соответствие брифу, затем первый агент переписывает текст. После одной-двух итераций цикл останавливается, а редактор принимает финальное решение.
• Воспроизведение нестабильных тестов. Агент продолжает попытки, пока одна из гипотез не пройдет проверку.
• Подготовка черновика в PR по задаче в проекте с сильными тестами, которые отклонят плохой результат.

А вот что будет так себе выбором для первого цикла:

• Переписывание архитектуры.
• Код авторизации и платежей.
• Деплой в рабочей среде.
• Размытые продуктовые задачи.
• Полностью автономная публикация авторских текстов без редактора. Цикл может подготовить черновик, найти слабые места и переписать текст, но решение «это хороший материал» все равно остается за человеком.
• Любая работа, в которой готовность результата определяется субъективно.

Здесь человек должен оставаться у руля.

II. Пять основных элементов

5. Автоматизация запускает цикл

Автоматизация превращает одноразовый запуск в настоящий цикл.

Она срабатывает по расписанию, после события или при выполнении заданного условия. Это сердце системы, а все остальные компоненты зависят от него.

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

В Claude Code похожая схема собирается из нескольких механизмов. Команда /loop задает периодичность внутри сессии. Запланированные задачи в настольном приложении сохраняются после перезапуска. Облачные сценарии продолжают работать, даже когда ноутбук выключен. События жизненного цикла можно обрабатывать через hooks.

Внутри автоматизации очень важны два механизма.

/loop повторяет запуск через заданный интервал. Он подходит для регулярной проверки независимо от текущего состояния проекта.

/goal продолжает работу, пока сформулированное условие не станет истинным. Выполнение условия проверяет отдельная небольшая модель. Благодаря этому агент, который написал код, не решает сам, достаточно ли хорошо он справился.

Так автор и проверяющий разделены уже на уровне условия остановки.

Пример задачи для цикла может выглядеть так:

/loop 30m /goal Все тесты в test/auth проходят, линтер не находит ошибок.
Проверь src/auth, найди новые сбои, подготовь исправления в отдельной ветке
и открой черновик PR, когда независимая проверка подтвердит условие цели.

Система запускается каждые 30 минут и не принимает промежуточный результат за завершение. Она останавливается только после независимого подтверждения заданного условия.

6. Рабочие деревья: параллельная работа без хаоса

Как только ты запускаешь нескольких агентов, они начинают сталкиваться на уровне файлов.

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

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

Codex позволяет выполнять несколько задач в отдельных рабочих деревьях одного репозитория.

Claude Code позволяет открыть сессию в изолированной копии через параметр --worktree. Для субагентов также можно включить режим isolation: worktree. Тогда каждый из них получает временную рабочую копию, которая удаляется после завершения.

Рабочие деревья устраняют конфликты файлов, но не снимают главное ограничение.

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

7. Скиллы: один раз записать знания проекта и использовать их в каждом запуске

Казалось бы, скиллы сейчас - это что-то само собой разумеющееся, но в контексте циклов важно понимать их архитектуру и то, как они устроены.

Скиллы избавляют от необходимости заново объяснять контекст проекта в каждой сессии.

В Codex и Claude Code используется похожая структура. Обычно это папка с файлом SKILL.md, где хранятся инструкции и метаданные. Рядом могут находиться сценарии, справочные материалы и другие ресурсы.

Для циклов это особенно важно.

Без скиллов система при каждом запуске заново восстанавливает правила проекта. Если скилл есть, накопленные решения сохраняются и используются в следующих итерациях.

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

Пример инструкции для разбора ошибок CI:

name: ci triage
description: Определять причину сбоев CI, готовить исправления для простых
случаев и передавать остальные человеку.

# Разбор ошибок CI

## Классификация
* env: отсутствует секрет, неверна переменная окружения или не подготовлена инфраструктура. Передать человеку.
* flake: тест проходит при повторном запуске без изменения кода. Повторить один раз, затем зарегистрировать проблему.
* bug: воспроизводимая ошибка связана с недавним коммитом. Подготовить исправление.
* dependency: сбой появился после обновления зависимости. Подготовить откат.
* infra: тайм-аут, нехватка памяти или проблема CI-раннера. Передать человеку.

## Типовые проверки
* Для тестов авторизации сначала проверить src/auth/middleware.
* Для тестов базы данных убедиться, что миграция применена в окружении CI.
* Для сквозных тестов сравнить селекторы с последним снимком интерфейса.

## Запрещено
* Не отключай тесты, завершающиеся с ошибкой. Вместо этого всегда создавай эскалацию.
* Не менять настройки CI без одобрения человека.
* Не изменять src/payments и src/billing.

## Состояние
После каждого запуска обновлять STATE.md: проверенные файлы, классификация,
открытые PR и вопросы, переданные людям.

Такой файл закрепляет договоренности и делает их доступными при каждом запуске.

8. Коннекторы: доступ к рабочим инструментам через MCP

Цикл, который видит только файловую систему, сильно ограничен.

Коннекторы на основе Model Context Protocol позволяют агенту читать задачи, обращаться к базе данных, вызывать тестовый API и отправлять сообщения в Slack.

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

Именно коннекторы отделяют агента, который сообщает «исправление готово», от системы, которая открывает PR, связывает его с задачей в трекере и уведомляет команду после успешного прохождения CI.

Цикл получает возможность действовать внутри настоящей рабочей среды, а не просто объяснять, что он сделал бы при наличии доступа.

Быстрее всего обычно окупаются четыре типа подключений.

1. GitHub. Чтение репозиториев, создание веток, открытие PR, комментарии к задачам и реакция на события. Для большинства циклов разработки это самый полезный первый коннектор.
2. Linear или Jira. Обновление задач по мере работы, связь PR с исходной задачей и автоматическое закрытие после успешной проверки.
3. Slack. Публикация результатов разбора, вызов человека при эскалации и утренняя сводка ночных запусков.
4. Sentry или другая система отслеживания ошибок. Исследование реальных сбоев и подготовка исправлений для часто повторяющихся проблем.
   

9. Об опасности самопроверки и о субагентах

Самое полезное инфраструктурное решение внутри цикла простое: разделить две роли.

Один агент пишет код. Другой проверяет результат.

Модель, которая только что создала решение, обычно слишком снисходительна к собственной работе. Она уже объяснила себе, почему выбранный подход правильный, и автоматически защищает его при проверке.

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

Anthropic описывала эту схему еще в декабре 2024 года как сочетание оценки и последовательного улучшения. Одна модель создает результат, вторая критикует, затем цикл повторяется.

В Codex вспомогательные агенты запускаются по явному запросу. Они могут работать параллельно, после чего их вывод объединяется в один результат. Собственные роли описываются в TOML-файлах внутри .codex/agents/. Для каждой роли можно задать имя, назначение, инструкции, модель и глубину рассуждения.

В Claude Code похожая схема строится через вспомогательных агентов в .claude/agents/ и команды агентов, которые передают работу друг другу.

Обычно роли распределяются так:

1. Первый агент исследует задачу.
2. Второй реализует решение.
3. Третий проверяет результат по требованиям.

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

Если система работает без присмотра, надежная независимая проверка становится главным условием, которое позволяет расслабиться и не переживать за результат.

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

III. Как собрать цикл и не навредить проекту

10. Промежуточные сохранения в файлах: агент забывает, файл помнит

Может показаться, что это слишком просто, чтобы быть чем-то важным. На практике это и есть основа нормального цикла.

Состояние можно хранить в .md-файле или в JSON. Формат не так важен. Главное, чтобы информация существовала вне одной беседы и отвечала на два вопроса:

1. Что уже сделано?
2. Что нужно делать дальше?

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

Короткое правило звучит так: агент забывает, а репозиторий помнит.

Без сохраненного состояния цикл каждый раз начинает работу с нуля. С файлом состояния он продолжает с места остановки.

Пример:

# Состояние цикла: разбор CI

## Последний запуск
9 июня 2026 года, 03:30 UTC. Классифицировано 7 сбоев,
подготовлено 3 исправления, 4 проблемы переданы людям.

## В работе
* Исправление обновления токена авторизации. Локальные тесты проходят, ожидается CI.
* Нестабильный webhook платежей. Добавлен повторный запуск, продолжается наблюдение.

## Завершено сегодня
* Обновление axios до 1.7.4. PR объединен после успешной проверки.
* Июньское исправление линтера. PR объединен.

## Передано людям
* src/billing/refund.ts. Тесты падают тремя разными способами, причина неясна.
* CI-раннер тестового окружения. Инфраструктурные тайм-ауты, проблема не связана с кодом.

## Полученные знания
* 8 июня: на этом Windows-раннере возникают проблемы с TLS 1.2 в PowerShell. Использовать bash.
* 7 июня: tests/e2e/checkout требует секрет Stripe webhook. При отсутствии секрета тест не запускать.

## Выполненные условия остановки
* Все тесты проходят, линтер не находит ошибок. Подтверждено для коммита 3a7b8c1 в 02:14 UTC.

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

Простой вариант здесь - это STATE.md в корне репозитория или служебной папке агента. Файл хранится вместе с кодом, иногда читается человеком и удобно демонстрирует изменения. Это удобный выбор для соло-разработчика или небольшой команды.

Для циклов, работающих в реальных проектах, подходит внешняя система: Linear, GitHub Issues или база данных. Такое состояние охватывает несколько репозиториев, поддерживает поиск и остается видимым всей команде.

Если тяжелый цикл может отклониться от цели, одного состояния недостаточно. Рядом нужен постоянный документ с высокоуровневыми требованиями, например VISION.md или AGENTS.md. Агент должен перечитывать его при каждом запуске.

Файл состояния сообщает, где система находится сейчас. Спецификация напоминает, куда она должна прийти.

11. Минимальный рабочий цикл

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

Сначала не нужны десятки агентов и сложная оркестрация. Достаточно четырех простых компонентов.

Одна автоматизация

Запланированный запуск с понятной периодичностью и четким условием остановки. В Claude Code можно использовать /loop. Если работа должна продолжаться до достижения результата, добавляется /goal с объективным условием.

Один скилл

Единственный SKILL.md, в котором записан контекст проекта. Без него агенту пришлось бы восстанавливать эти знания на каждом запуске.

Один файл с сохранением состояния работы

Это отдельный .md-файл, где отмечено, что уже сделано и что остается на очереди. Следующий запуск продолжает работу, а не начинает ее заново вслепую.

Одна автоматическая проверка

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

Когда ты настраиваешь цикл, порядок имеет значение.

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

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

Главная метрика здесь не количество потраченных токенов, выполненных задач или запущенных циклов. Считать нужно стоимость одного принятого изменения.

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

12. Цикл Ральфа Виггама: как системы незаметно проваливают задачу

Инженер Джеффри Хантли описал этот режим и дал ему название.

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

Без жесткой системы проверки твой агент способен тихо провалить работу и при этом продолжать жрать токены (в 99% случаев так и будет).

Такой цикл возникает в трех случаях.

Нет объективной проверки

Второго агента просто просят посмотреть результат, но ему не дают проверяемого критерия. В итоге два оптимиста (а базовая позиция моделек - соглашаться) подтверждают друг друга.

Условие завершения сформулировано расплывчато

Готовность определяет сам агент, а не тест, сборка или проверка типов.

Нет жесткого предела

Цикл работает, пока его не остановит внешний фактор: лимит запросов, ошибка инфраструктуры или человек своими руками.

Здесь помогает автоматическая проверка из предыдущего шага.

Проверка должна выдавать объективный результат. Тест проходит или падает. Проект собирается или не собирается. Линтер возвращает ноль ошибок или сообщает о проблемах.

Мнения второго агента недостаточно.

Есть еще три распространенных режима отказа.

Первый называется дрейфом цели. Во время долгой сессии контекст несколько раз сокращается, и каждое такое сжатие теряет часть информации.

К условному сорок седьмому шагу ограничение «не делать X» может просто исчезнуть. Помогает постоянный VISION.md или AGENTS.md, который перечитывается при каждом запуске.

Второй режим связан с предвзятым отношением к собственному решению. Агент, написавший код, слишком мягко оценивает свою работу. Помогает отдельный проверяющий, который не видел рассуждений автора.

Третий режим связан с преждевременным завершением. Система считает частичный результат достаточным и объявляет задачу выполненной. Помогает объективное условие /goal, которое проверяет новая модель.

13. Долг понимания и отказ от собственного мышления

Эта проблема становится опаснее по мере того, как цикл начинает работать лучше.

Первый риск называется долгом понимания.

Чем быстрее система выпускает код, который ты не писал, тем больше разрыв между тем, что лежит в репозитории, и тем, что ты об этом коде понимаешь.

Самая большая проблема циклов даже не в том, что легко слить огромное количество токенов. А в том, что может прийти день, когда нужно отладить систему, которую никто внимательно не читал.

В команде это еще опаснее, ведь отлаживать такой код придется не только тебе.

Второй риск заключается в постепенном отказе от собственного суждения.

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

Технического решения здесь недостаточно.

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

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

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

Проектируй важные циклы вместе с друзьями-вайбкодерами (если есть такие). Вторая пара глаз на этапе создания замечает слепые зоны, которыми автоматизация будет пользоваться снова и снова, если не поправить сразу.

14. Цена безопасности: автономный цикл создает новые риски

Система, которая работает без наблюдения, создает дополнительные точки атаки, за которыми тоже никто постоянно не следит.

При проектировании нужно учитывать четыре угрозы.

Непроверенный код попадает в продукт

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

Скиллы становятся каналом для внедрения вредоносных инструкций

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

Учетные данные попадают в логи

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

Права постепенно расширяются

Сначала цикл работает только на чтение. Затем ради удобства ему добавляют одно разрешение на запись. Потом еще одно. Повторный аудит никто не проводит.

Права твоего цикла стоит проверять заново хотя бы раз в 30 дней.

IV. Ошибки, которые превращают циклы в потерю денег

Создание цикла без проверки четырех условий

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

Отсутствие нормальной проверки

Второй агент с просьбой «проверь результат» не заменяет полноценную проверку. Это всего лишь оптимистичная надежда.

Один агент пишет и проверяет

Агент сам же оценивает собственную работу и почти всегда ставит себе высший балл.

Нет файлов памяти

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

Размытые условия остановки

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

Нет ограничения бюджета

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

Ресурсоемкие циклы запускаются на дешевом пользовательском тарифе

В этом случае система быстро упирается в лимиты.

Сторонние скиллы устанавливаются автоматически

В одном из упомянутых аудитов утечки данных обнаружили в 520 из 17022 проверенных скиллов. Исходный код нужно читать до установки, а не после инцидента.

Циклу поручают работу, основанную на субъективном суждении

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

Никто не читает изменения

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

V. Заключение

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

Последние два года главное преимущество в работе с ИИ-агентами находилось на уровне промпта. Более точная формулировка, лучший контекст и сильный результат с первой попытки давали заметное преимущество.

Этот этап заканчивается.

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

Но это не означает, что всем срочно нужны циклы.

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

Если хотя бы одного условия нет, система будет стоить больше, чем принесет.

Если все условия выполнены, начинай с малого.

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

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

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

Строй циклы, но не забывай думать как инженер.

Спасибо за прочтение!