Loops: что должен знать каждый AI-инженер в 2026 году

Оригинал опубликован Rahul в X.

Peter Steinberger, создатель OpenClaw, который сейчас работает в OpenAI, недавно написал:

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

«Вам больше не стоит промптить кодинговых агентов. Вам стоит проектировать циклы, которые промптят ваших агентов».

Затем Boris Cherny, руководитель Claude Code в Anthropic, сформулировал ту же мысль иначе:

I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.

«Я больше не промпчу Claude. У меня запущены циклы, которые сами промптят Claude и решают, что делать. Моя работа — писать циклы».

Два очень опытных AI-инженера говорят об одном и том же. Большинство читает это и думает: что это вообще значит?

Ниже — простой разбор без жаргона: ментальная модель, которая нужна, чтобы понять loop engineering.

Сначала: почему большинство людей так и не строит циклы

Циклы звучат отлично — пока вы не видите счёт.

О чём редко говорят заранее: один агентный цикл на задаче средней сложности может съесть 50 000–200 000 токенов. Fleet loop с orchestrator и тремя специалистами — 500 000–2 000 000 токенов. Цикл, который запускается каждое утро по расписанию, — миллионы токенов в неделю.

На стандартных API-ценах неделя серьёзного loop engineering может стоить больше, чем месячный AI-бюджет большинства людей.

Поэтому под постом Peter Steinberger было много ответов в духе: «Легко говорить, когда у тебя безлимитный доступ к OpenAI». И в этом есть правда.

Loop engineering на обычном бюджете быстро ломается. Каждый retry стоит денег. Каждое self-correction стоит денег. Каждый subagent стоит денег. Каждый verification pass стоит денег. Открытый цикл, который свободно исследует пространство решений, сжигает токены с болезненной скоростью.

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

Именно эту проблему решают китайские LLM вроде DeepSeek, Kimi и MiniMax: они делают агентные циклы экономически жизнеспособными.

Главная проблема автономных агентов — не интеллект, а token burn. Циклы потребляют токены очень быстро. Один запуск легко может потратить 50K–200K токенов; несколько агентов, ежедневные расписания или большие кодовые базы быстро разгоняют стоимость.

По словам автора, DeepSeek меняет экономику: большая context window, низкая стоимость токенов, tool calls, JSON output и высокая параллельность делают масштабные циклы практичнее.

Почему большой контекст важен? Циклам нужна память. Кодинговый цикл на большом проекте должен держать в голове предыдущие запуски, текущие ошибки, architecture docs, test results и контекст кодовой базы одновременно. Когда модель теряет контекст на середине, цикл начинает забывать, что уже произошло. Большое окно контекста помогает длинным циклам оставаться связными, а низкая цена не даёт им разорить бюджет.

Часть 1: старый способ против нового

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

Вы пишете prompt. Агент отвечает. Вы проверяете. Вы исправляете то, что не так. Вы промптите снова. То есть вы сами были циклом.

Это начинает меняться.

Вместо того чтобы попросить агента «сделай landing page» и вручную вести каждый шаг, вы настраиваете цикл, который сам проходит discovery, planning, execution, checking и iteration — пока цель не будет достигнута.

Старый способ:

You → Prompt → Agent → Output → You review → You fix → Repeat

Новый способ:

You set the goal → Loop runs → Agent discovers → Plans → Executes → Verifies → Iterates → Done

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

Prompt даёт агенту инструкции. Loop даёт агенту работу.

Часть 2: что такое loop engineering

Loop Engineering — это практика проектирования повторяемых feedback cycles, которые ведут AI-агента от попытки к проверенному результату без постоянного вмешательства человека.

Looping — это не магия. Это настройка, которую вы строите. Почти любой agent harness может её запускать, если правильно связать компоненты.

В самой простой форме один агент работает над собой:

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

Каждый цикл, простой или сложный, проходит одни и те же пять стадий:

DISCOVER → PLAN → EXECUTE → VERIFY → ITERATE

Прошёл verification — ship. Не прошёл — loop again.

Всё остальное — это вопрос того, как правильно построить этот цикл.

Часть 3: один агент против fleet

Есть два масштаба looping.

Single-agent loop

Один агент проходит весь цикл самостоятельно. Это похоже на человека, который переписывает собственный черновик: он выясняет, что нужно, планирует работу, выполняет её, проверяет качество и повторяет, если что-то не так.

Подходит для сфокусированных задач, простых целей и ограниченного scope.

Один мозг. Один цикл. Самоулучшение.

Fleet loop

Более крупная версия — fleet looping.

Вы даёте orchestrator agent цель. Он разбивает её на части и передаёт каждую specialist agent. Специалисты, в свою очередь, могут отдавать узкие задачи subagents. Всё дерево проходит discovery, planning, execution и verification, пока цель не будет достигнута.

Это похоже на команду, которая ведёт проект end-to-end.

Структура:

• orchestrator отвечает за цель;
• specialists отвечают за этапы;
• subagents делают узкую работу;
• eval gates следят, чтобы результат не превращался в slop.

Пример: «построить productivity app». Orchestrator владеет миссией, research specialist изучает рынок, engineering specialist пишет код, QA specialist проверяет качество, а их subagents выполняют ещё более мелкие задачи.

Каждый агент в дереве запускает тот же пятишаговый цикл: Discover → Plan → Execute → Verify → Iterate.

Ключевая мысль: single-agent loop — это человек, переписывающий собственный черновик. Fleet loop — это целая команда, ведущая проект от начала до конца.

Часть 4: open loops против closed loops

Это самое важное практическое различие в 2026 году.

Open looping

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

Это захватывающая часть — именно так, по словам автора, работают Peter Steinberger и другие в OpenAI.

Проблема в цене: open looping сжигает безумное количество токенов. Для 90% людей без безлимитных API-бюджетов он пока не очень практичен. Если направить его на проекты с расплывчатыми стандартами, он быстро превращается в slop machine: быстро, грязно, дорого.

Closed looping

Closed loop ограничен рамками. Человек заранее проектирует end-to-end path:

• понятная цель;
• определённые шаги;
• evaluation на каждом шаге;
• точка, где цикл останавливается или возвращает управление человеку.

Агенты всё ещё loop, но внутри фреймворка, который вы построили. Каждый проход улучшает следующий, потому что результат предыдущего становится feedback. Такой цикл помещается в нормальный бюджет, потому что путь узкий, а standard keeps it honest.

Без quality gate AI drift. С quality gate AI improves.

Для большинства реальной работы сегодня closed looping — тот вариант, который окупается. Начинайте с closed loops. Постройте плотную систему, которая работает надёжно. Потом открывайте её шире, когда quality gates уже есть.

Часть 5: шесть building blocks хорошего цикла

Концептуально loop состоит из пяти стадий, но практически нужно построить шесть вещей. Claude Code и Codex уже имеют все эти элементы.

1. Automations

Automations запускают DISCOVER и приводят loop в движение. Это heartbeat цикла.

Automation превращает loop в настоящий loop, а не в одиночный запуск. Вы задаёте prompt, cadence и goal. Цикл запускается по расписанию, findings приходят к вам, а вы не ходите вручную проверять всё вокруг.

Пример: /loop перезапускается по cadence, /goal продолжает работать, пока написанное вами условие не станет истинным. Дайте условие вроде: «все tests in test/auth проходят и lint clean» — и отходите.

2. Worktrees

Worktrees позволяют нескольким EXECUTE stages работать параллельно, не ломая друг друга.

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

Git worktree даёт каждому агенту изолированную рабочую директорию на отдельной ветке: та же история repo, ноль коллизий. Правки одного агента физически не могут затронуть checkout другого.

3. Skills

Skills ускоряют DISCOVER: агент уже знает проект до старта.

Не нужно объяснять проект с нуля каждый запуск. Skill — это папка с SKILL.md внутри: conventions, build steps, важные запреты и уроки вроде «мы так не делаем из-за того инцидента».

Один раз написали — каждый loop читает.

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

• VISION.md — как выглядит success;
• ARCHITECTURE.md — tech stack и структура папок;
• RULES.md — что агенту никогда нельзя делать.

4. Plugins and connectors

Plugins и connectors делают EXECUTE реальным: loop действует в вашей настоящей среде, а не только в filesystem.

Цикл, который видит только файловую систему, — маленький цикл. Connectors, построенные на MCP, позволяют агенту читать issue tracker, делать queries к database, обращаться к staging API, писать в Slack.

Это разница между агентом, который говорит «вот фикс», и loop, который открывает PR, линкует Linear ticket и пингует канал, когда CI green, — сам.

5. Subagents

Subagents делают VERIFY честным: проверяющий не должен быть тем же агентом, что и создатель.

Держите maker отдельно от checker. Модель, которая написала код, слишком мягко оценивает собственную работу. Второй агент с другими инструкциями — иногда даже другая модель — ловит то, что первый агент сам себе оправдал.

Рабочее разделение:

• один агент исследует;
• один агент реализует;
• один агент проверяет against the spec.

Именно это, по словам автора, /goal делает под капотом: свежая модель решает, завершён ли цикл, а не та, которая выполняла работу.

6. Memory

Memory делает цикл persistent: DISCOVER на запуске 47 знает, что уже пробовали запуски 1–46.

Это backbone всего loop. Markdown-файл, Linear board — что угодно, что живёт вне одной conversation.

Модель забывает всё между runs. Repo — нет. Memory file хранит, что пробовали, что прошло, что всё ещё открыто. Завтра утром loop продолжает там, где остановился сегодня.

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

Часть 6: реальные примеры loop

На практике loops могут выглядеть так:

Coding Loop

Агент пишет, тестирует, исправляет и проверяет сам, без человека в середине.

Research Loop

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

Content Loop

Агент собирает тему, пишет draft, проверяет against style guide, исправляет слабые места и повторяет до готового материала.

Sales Outreach Loop

Агент ищет leads, готовит outreach, проверяет качество и персонализацию, отправляет или возвращает на review.

У всех циклов один skeleton:

Goal → Action → Check → Fix → Repeat until done

Часть 7: Prompt Engineer против Loop Engineer

В 2026 году открывается новый skill gap.

Prompt Engineer

• пишет более качественные инструкции;
• опирается на linguistic skill;
• лучший prompt даёт лучший single output;
• после каждого run человек всё ещё вручную проверяет результат;
• человек остаётся feedback loop.

Loop Engineer

• проектирует лучшие feedback cycles;
• опирается на software engineering skill;
• лучший loop даёт reliable verified outcomes;
• система сама запускается, проверяет и исправляется;
• feedback loop — это система.

Prompt Engineer говорит: «напиши мне функцию». Loop Engineer говорит: «пиши → тестируй → исправляй, пока green».

Инструменты могут быть теми же, но mindset полностью другой.

Prompt engineers просят AI выдать output. Loop engineers проектируют системы, которые производят verified outcomes.

Самые высокооплачиваемые AI-инженеры в 2026 году — не те, кто пишет лучшие английские предложения. Это те, кто пишет логику, управляющую тем, как агенты discover, plan, check their own work и понимают, когда задача завершена.

Заключение

Это и есть Loop Engineering.

Коротко:

• два года мы промптили агентов по одной задаче за раз;
• теперь мы проектируем loops, которые проходят весь цикл;
• automations дают heartbeat;
• worktrees позволяют parallel agents работать без коллизий;
• skills дают проектное знание, которое накапливается;
• plugins и connectors позволяют loop действовать в реальных инструментах;
• subagents разделяют maker и checker;
• memory не даёт loop забыть, что уже было сделано.

Есть два масштаба: single agent и fleet. Есть два типа: open loop и closed loop. Для большинства задач сегодня стоит начинать с closed loop: он ограничен, надёжен и доступен по бюджету.

Пять частей хорошего loop:

• Goal — точно определить, что значит done;
• Context — VISION.md, ARCHITECTURE.md, RULES.md;
• Action — только то, что агенту действительно нужно;
• Feedback — tests, type checks, linters, structured errors;
• Stop condition — момент, когда loop знает, что задача завершена.

Проблема стоимости всё ещё важна: loops быстро сжигают токены. Но дешёвые модели с большим контекстом снижают этот барьер и делают такую работу практичнее.

Главный сдвиг: prompt engineers ask AI for output. Loop engineers design systems that produce verified outcomes.

Peter Steinberger сформулировал это точно: перестаньте промптить агентов — начните проектировать loops.

Один надёжный loop стоит тысячи идеальных prompts.

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

Loop не знает разницы. Вы знаете.

Именно это делает loop design сложнее prompt engineering, а не проще. Мысль Boris Cherny не в том, что работа стала легче. Она в том, что точка приложения усилия сместилась.

Стройте loop. Но стройте его как инженер, который собирается оставаться инженером, а не просто человеком, который нажимает «go».