Инженеры Google рассказывают, что такое Loop Engineering? Пять блоков + внешняя память, обязательный курс по ИИ в 2026 году

Loop Engineering — это система, которая сама выполняет роль代理prompt, заменяя вас системой, которую вы проектируете. Здесь «цикл» можно понять как рекурсивную цель: вы определяете задачу, а ИИ повторяет итерации, пока не достигнет результата. Я верю, что это может стать нашим будущим способом сотрудничества с кодовыми агентами.

Но предварительно скажу, что это всё ещё очень ранняя стадия, я сам в этом сомневаюсь, и вам обязательно нужно быть осторожным с затратами токенов. Хочу разобрать это по частям: что это такое и что это означает.

Питер Штайнбергер недавно сказал: «Вам больше не нужно promptить ваш кодовый агент. Вам нужно спроектировать цикл, который promptит ваш агент.» Борис Черни, руководитель Claude Code в Anthropic, тоже сказал что-то похожее: «Я больше не promptю Claude. Я запускаю цикл, который promptит Claude, а цикл сам решает, что делать.»

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

Теперь вы создаёте небольшую систему: она ищет задачи, распределяет их, проверяет, что сделано, и решает, что делать дальше — всё это делает система, а не вы лично. Я ранее писал о её близком родственнике — «agent harness engineering», — это создание среды для запуска одного агента, то есть модель «фабрики» для разработки программного обеспечения.

Loop engineering — это уровень выше harness: harness всё ещё есть, но он работает по расписанию, создаёт помощников, сам себя кормит.

К моему удивлению, это уже не просто инструмент. Год назад, чтобы написать цикл, нужно было писать много bash-скриптов и поддерживать их — это было ваше личное дело. Сейчас эти компоненты встроены прямо в продукт. Список Штайнбергера почти полностью совпадает с Codex app и Claude Code. Когда вы понимаете, что формы одинаковы, вы перестаёте спорить о «какой инструмент использовать» — вы просто проектируете цикл, который может работать в любом инструменте.

Пять компонентов, с некоторыми заметками

Для одного цикла нужно пять элементов, плюс место для хранения состояния. Вот список и соответствие.

2. Automations: по расписанию запускает обнаружение и сортировку.
3. Worktrees: изолируют параллельные агенты, чтобы они не мешали друг другу.
4. Skills: записывают знания проекта, которые раньше приходилось угадывать.
5. Plugins / connectors: подключают агента к уже используемым инструментам.
6. Sub-agents: один генерирует идеи, другой проверяет.

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

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

| Название | В роли в цикле | В Codex app | В Claude Code | | --- | --- | --- | --- | | Automations | Расписание обнаружения и сортировки | Раздел Automations: выбрать проект, prompt, частоту, окружение; результаты попадают в Triage; /goal для выполнения до завершения | Расписание и hooks. Можно использовать /loop для повторного запуска, cron, hooks, GitHub Actions | | Worktrees | Изоляция параллельной разработки | Встроенная поддержка worktree в Codex | git worktree, --worktree, изоляция на уровне subagent | | Skills | Запись знаний проекта | SKILL.md, вызывается через $name или автоматически при соответствии | SKILL.md | | Plugins / connectors | Подключение к инструментам | MCP + плагины | MCP-сервера + плагины | | Sub-agents | Генерация и проверка | В .codex/agents/ через TOML | В .claude/agents/ — задачи, команды команд | | State | Отслеживание статуса | Markdown или Linear через connector | Markdown (AGENTS.md, прогресс) или Linear через MCP |

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

Automations: сердце цикла

Automations — это то, что превращает «цикл» из просто однократного запуска в настоящий цикл. В Codex app создаёте автоматизацию: выбираете проект, prompt, частоту, окружение. Запуски, которые находят что-то, попадают в Triage, а те, что не находят — архивируются. Это удобно.

OpenAI использует это для рутинных задач: ежедневное распределение задач, отчёты о сбоях CI, краткое содержание коммитов, поиск багов, добавленных на прошлой неделе. Automation может вызывать skill, так что ваши циклические задачи — это не просто скрипты, а управляемые процессы: вызываете $skill-name, а не вставляете длинный набор команд в расписание.

Claude Code использует похожий подход, но через расписания и hooks. Можно использовать /loop для повторного запуска prompt или команд через интервал, cron, hooks в жизненном цикле агента, или запускать всё через GitHub Actions — всё равно концепция одна: задаёте автоматическую задачу, даёте ей ритм, и она автоматически показывает результаты.

Также важен /loop — повторный запуск по расписанию, а /goal — запуск до тех пор, пока условие не выполнится. Каждая итерация проверяется моделью, которая решает, завершена ли задача. Так что «написать код, который проходит тесты и не ругается линтером» — это условие, при выполнении которого цикл останавливается. В Codex есть аналогичный /goal, который запускается многократно, пока условие не выполнится, и умеет ставить на паузу, возобновлять, очищать.

Это — «выявление работы». Остальная часть цикла — «делать что-то с этими задачами».

Worktrees: не позволяйте параллели превращаться в хаос

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

Codex поддерживает worktree встроенно, так что несколько потоков могут одновременно работать с одним репозиторием без конфликтов. Claude Code использует git worktree, --worktree, и настройку isolation: worktree на уровне subagent (каждый помощник получает чистый checkout, после завершения — удаляет его). В статье о оркестрации я писал, что это устраняет механические конфликты, но ограничение — это ваша проверочная пропускная способность, а не инструмент.

Skills: больше не нужно повторять проект заново

Skills позволяют не объяснять проект заново в каждом сеансе. Оба инструмента используют одинаковый формат: папка с SKILL.md, где прописаны команды и метаданные, а также скрипты, ссылки, ресурсы. В Codex вызываете skill через $ или /skills, или он автоматически запускается, если задача совпадает с описанием skill — так проще, чем писать длинные инструкции. Claude Code делает то же самое, я описывал этот паттерн в статье про agent skills.

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

Важно понять: skill — это формат записи, а plugin — способ распространения. Когда нужно делиться skill между репозиториями или объединять их — создаёте plugin. В Codex и Claude Code это реализовано одинаково.

Plugins и connectors: цикл касается ваших реальных инструментов

Ограниченный цикл, основанный только на файловой системе — это очень узкий цикл. Connectors, построенные на MCP, позволяют агентам читать issue tracker, обращаться к базам данных, вызывать API, отправлять сообщения в Slack. Codex и Claude Code используют MCP, так что один connector обычно подходит обоим. Plugins объединяют connectors и skills в единый пакет, чтобы команда могла установить всё одним действием, а не по памяти.

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

Sub-agents: разделение тех, кто делает, и тех, кто проверяет

Самая важная структурная идея — разделить «писателя» и «проверяющего». Модель, которая сама себе ставит оценки, слишком мягкая. Вторая модель — другой агент, который проверяет работу первого, — помогает обнаружить самопродажу. Codex создаёт subagent только по вызову, он работает параллельно и возвращает результат. В .codex/agents/ описываете агента через TOML: имя, описание, инструкции, модель, reasoning effort. В Claude Code — те же идеи, в .claude/agents/ — задачи, команды, команды команд.

Я уже предлагал два подхода: «оркестровка кодовых агентов» и «адверсариальный код-ревью». В цикле это особенно важно, потому что он работает, когда вы не смотрите. Надёжный проверяющий — это единственный способ быть уверенным, что всё завершится правильно. Subagent — это дополнительные токены, потому что каждый запускает модель и инструменты. Поэтому их лучше использовать там, где нужен второй взгляд. В Claude Code /goal — это механизм, где новая модель решает, завершён ли цикл, а не тот, кто пишет код — «исполнитель» против «проверяющего» в вопросе остановки.

Как выглядит один цикл

Объединив всё, получаете мини-панель управления. Обычно я представляю его так:

• автоматизация запускается каждое утро в репозитории;
• она вызывает skill для triage, читает ошибки CI, открытые issues, последние коммиты;
• результаты записывает в markdown или Linear-доску;
• для каждого найденного пункта создаёт изолированный worktree;
• посылает subagent’у черновик исправлений;
• второй subagent проверяет черновик по проектным skills и тестам.

Connectors позволяют делать PR, обновлять тикеты. Всё, что не успевает — попадает в triage. Статус — это позвоночник всей системы: что сделано, что осталось, что открыто. На следующий день можно продолжить с того места, где остановились.

Вы проектировали всё один раз. Ни одна команда не пишет это вручную — всё автоматизировано. Это и есть конкретное воплощение идеи Штайнбергера. И то же самое работает в Codex и Claude Code, потому что компоненты одинаковы.

Что цикл всё ещё не делает

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

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

Ваше понимание может деградировать. — чем быстрее цикл выпускает «не ваш код», тем больше разрыв между «существующим» и «настоящим». Это comprehension debt — долговое обязательство по пониманию. Быстрый цикл только ускоряет рост этого долга, если вы не следите за тем, что он делает.

Комфорт — опасный друг. — когда цикл работает сам по себе, вы склонны перестать иметь мнение и просто принимать его решения. Это — cognitive surrender — «когнитивное сдавание». Проектировать цикл — это лекарство, когда у вас есть критика, а ускоритель — когда хотите избегать размышлений. Одинаковое действие — противоположные результаты.

Построить цикл, но оставаться инженером

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

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

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

Поэтому проектирование цикла сложнее, чем prompt engineering. Черни не говорит, что работа стала проще, а что «рычаги» переместились.

Строить цикл — как человек, который собирается оставаться инженером, а не как тот, кто просто нажимает старт.