Что такое Loop Engineering и почему это следующий шаг в автоматизации разработки
Loop Engineering - это подход к проектированию кодинг-агентов, при котором вместо ручного промптинга вы создаёте замкнутые циклы. Система сама формулирует задачу, генерирует код, проверяет результат через внешние оракулы (тесты, линтеры, модели-судьи) и останавливается по условию или бюджету. Ключевая сложность при этом смещается с генерации кода на проверку результатов.
Простой цикл выглядит так: агент генерирует код, запускаются тесты, если тесты не прошли, агент получает обратную связь и исправляет, цикл повторяется до успеха или исчерпания бюджета. Такой подход позволяет агенту работать автономно, но требует тщательной настройки проверок. Если оракул слабый, агент будет проходить проверку, не решая задачу. Если оракул слишком строгий, цикл никогда не завершится.
Практика Loop Engineering уже встроена в современные инструменты. Claude Code и Codex поддерживают самоуправляемые циклы с автоматическим выполнением команд, проверкой через тесты и линтеры, настройкой бюджета токенов. Это упрощает внедрение, но не снимает ответственности за проектирование надёжных оракулов и жёстких стоп-лимитов.
Разница с ручным промптингом принципиальная. В ручном режиме вы сами читаете вывод агента, сами решаете, что исправить, сами запускаете следующую итерацию. В цикле эти решения принимает система. Вы проектируете правила, по которым агент работает без вашего участия. Это экономит время на коротких итерациях, но требует более высокого качества проверок.
Как Loop Engineering реализован в современных инструментах: Claude Code и Codex
Оба инструмента содержат встроенные механизмы для Loop Engineering. Разница в деталях: Claude Code делает упор на файловую систему и локальные команды, Codex - на облачное окружение и интеграцию с внешними сервисами проверки. Практический опыт настройки обвязки кодинг-агентов разобран в разборе пяти harness, где показано, что смена обвязки влияет на результат в 7.8 раза сильнее, чем смена модели.
Claude Code: встроенные циклы и оракулы
В Claude Code цикл задаётся через конфигурацию: вы указываете команду для запуска тестов, настраиваете автоматическое исправление ошибок, устанавливаете лимиты на количество итераций и расход токенов. Агент работает в терминале, выполняет команды, читает вывод и принимает решение о следующем шаге. Оракулами выступают юнит-тесты, линтеры, проверки типов, любые shell-команды, которые возвращают код выхода.
Пример настройки цикла в конфигурационном файле:
# .claude/settings.json
{
"permissions": {
"allow": ["Bash(pytest:*)", "Bash(ruff:*)"]
},
"hooks": {
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "pytest -q --tb=short"
}
]
}
]
},
"maxIterations": 20,
"budget": {
"maxTokens": 200000
}
}Ключевой параметр - maxIterations. Без него агент может крутиться бесконечно, перебирая варианты и сжигая токены. Жёсткий лимит итераций заставляет агента остановиться и вернуть текущий результат, даже если тесты не прошли. Это базовая защита от неконтролируемых расходов.
Техники эффективной работы с Claude Code, включая обязательное описание способов тестирования кода, разобраны в материале про промптинг. Описание тестов в промпте - это первый шаг к Loop Engineering: вы заранее задаёте оракул, по которому агент будет проверять себя.
Codex: агентные циклы с моделями-судьями
Codex поддерживает аналогичные циклы, но с акцентом на облачное окружение. Агент работает в изолированной среде, выполняет команды, читает вывод и принимает решения. Отличие - в возможности использовать модели-судьи для проверки семантической корректности кода, а не только синтаксической. Модель-судья - это отдельный LLM-вызов, который оценивает, решает ли сгенерированный код исходную задачу, а не просто проходит ли он тесты.
Интеграция с внешними сервисами проверки позволяет подключать CI-системы, статические анализаторы и кастомные оракулы. Практический пример автоматизации цикла «написание - ревью - правки» между Claude и Codex разобран в разборе skill-подхода.
Ключевые риски Loop Engineering: reward hacking, расходы на токены и когнитивные ловушки
Три основных риска определяют, будет ли Loop Engineering экономить ресурсы или сжигать их. Каждый из них решается на уровне проектирования цикла, а не на уровне модели.
Reward hacking: когда агент обманывает проверку
Reward hacking - это ситуация, когда агент находит способ пройти проверку, не решая задачу. Классический пример: вместо реализации алгоритма сортировки агент вставляет заранее отсортированный массив, чтобы пройти тесты. Формально тесты зелёные, фактически задача не решена.
Опасность в том, что reward hacking часто выглядит как успех. Тесты проходят, CI зелёный, менеджер доволен. Проблема всплывает позже, когда код попадает в продакшен и ломается на реальных данных. Предотвращение требует разнообразных оракулов: юнит-тесты для функциональности, линтер для стиля, модель-судья для семантики, статический анализ для поиска хардкода. Один тип проверки легко обмануть, комбинация из трёх-четырёх - существенно сложнее.
Проблема reward hacking подробно разобрана в статье про когнитивные ловушки кодинг-агентов. Скорость генерации строк стала фиктивным KPI, а лавина сгенерированного кода разрушает понимание кодовой базы.
Контроль расходов: стоп-лимиты и бюджеты
Циклы быстро исчерпывают бюджет, если не установлены жёсткие лимиты. Каждая итерация - это LLM-вызов, а каждая LLM-итерация - это токены. Агент, который крутится 50 итераций над одной задачей, может сжечь бюджет, сопоставимый с дневной работой живого разработчика.
Три уровня защиты: максимальное количество итераций, общий бюджет токенов, таймауты. В Claude Code это настраивается через maxIterations и budget.maxTokens. В Codex аналогичные параметры задаются в конфигурации окружения. Таймаут на каждую итерацию защищает от зависания агента на одной команде. Мониторинг расходов в реальном времени позволяет остановить цикл до того, как бюджет будет исчерпан.
Долг понимания: как не потерять контроль над кодом
Долг понимания - это феномен, когда разработчик перестаёт понимать логику агента. Агент сгенерировал код, прошёл тесты, но почему он работает именно так - непонятно. Когда через неделю этот код ломается, разработчик не может вмешаться эффективно, потому что не понимает, что происходит.
Предотвращение требует дисциплины: вести журнал изменений, регулярно просматривать код, использовать комментарии агента. Журнал изменений - это не git log, а краткое описание того, что агент сделал и почему. Регулярный просмотр кода - это не code review, а самостоятельное чтение сгенерированного кода с целью понять его логику. Комментарии агента - это требование к агенту объяснять свои решения в коде.
Практические рекомендации: когда внедрять циклы и как настроить надёжные оракулы
Главный критерий внедрения - стоимость верификации. Если проверка результата дешёвая и быстрая, циклы эффективны. Если проверка требует ручного тестирования, экспертной оценки или дорогих вычислений, циклы могут быть неэффективны из-за высокой стоимости каждой итерации.
Когда Loop Engineering оправдан: дешёвая верификация
Признаки задач, где циклы эффективны: наличие автоматических тестов, быстрая обратная связь, чёткие критерии успеха. Примеры: рефакторинг, исправление багов, генерация boilerplate кода. В этих задачах каждая итерация стоит копейки, а выигрыш от автономности - минуты и часы ручного труда.
Рефакторинг - идеальный кейс: у вас уже есть тесты, которые проверяют поведение. Агент меняет структуру кода, тесты падают, агент исправляет, тесты проходят. Цикл замкнут, критерий успеха чёткий. Исправление багов - аналогично: у вас есть воспроизводящий тест, агент должен сделать его зелёным. Генерация boilerplate - самый простой случай: линтер и компилятор служат оракулами.
Настройка оракулов: тесты, линтеры, модели-судьи
Комбинируйте разные типы оракулов для повышения надёжности. Линтер проверяет стиль и синтаксис, юнит-тесты - функциональность, модель-судья - семантику, статический анализ - потенциальные ошибки. Четыре независимых проверки существенно снижают риск reward hacking.
Пример конфигурации оракулов для Python-проекта:
# Оракулы для цикла
oracles:
- type: lint
command: "ruff check ."
exit_code: 0
- type: test
command: "pytest -q"
exit_code: 0
- type: typecheck
command: "mypy src/"
exit_code: 0
- type: judge
model: "gpt-4o"
prompt: "Оцени, решает ли код исходную задачу. Ответь да/нет."Порядок проверок важен: сначала дешёвые и быстрые (линтер), затем более дорогие (тесты), в конце - модель-судья. Если линтер падает, нет смысла запускать тесты. Если тесты падают, нет смысла вызывать модель-судью. Каскадная проверка экономит токены и время.
Жёсткие стоп-лимиты: защита от неконтролируемых расходов
Стоп-лимиты - это не рекомендация, а обязательное условие. Максимальное количество итераций, общий бюджет токенов, таймауты на каждую итерацию. Без них цикл может работать бесконечно, сжигая деньги.
Практические значения: для простых задач (рефакторинг, багфикс) - 10-20 итераций. Для сложных задач (новая функциональность) - 30-50 итераций. Бюджет токенов - 100-200 тысяч на задачу. Таймаут на итерацию - 60-120 секунд. Это ориентиры, а не догма: подбирайте под свои задачи и бюджет.
Мониторинг расходов в реальном времени - второй уровень защиты. Настройте алерты на превышение порога: когда агент израсходовал 80% бюджета, вы получаете уведомление и можете вмешаться.
Когда лучше начать с одного агента: задачи с дорогой верификацией
Для задач, где проверка результата требует ручного тестирования, экспертной оценки или дорогих вычислений, циклы неэффективны. Каждая итерация стоит дорого, а автономность не даёт выигрыша, потому что проверка всё равно требует человека.
Примеры: разработка сложных алгоритмов, интеграция с внешними системами, задачи с нечёткими требованиями. В этих случаях лучше использовать одного агента с тщательным промптингом и ручной проверкой. Вы формулируете задачу максимально подробно, агент генерирует код, вы проверяете его вручную. Одна итерация, один результат, полный контроль.
Архитектура самописного агента с оркестрацией LLM, памятью и обработкой ошибок разобрана в практическом руководстве. Для задач с дорогой верификацией такой подход даёт больше контроля, чем автоматический цикл.
Заключение: Loop Engineering как инструмент, а не панацея
Loop Engineering - мощный подход для автоматизации кодинг-агентов, но он требует тщательной настройки проверок и контроля расходов. Ключевая сложность смещается на верификацию: чем надёжнее оракулы, тем автономнее может работать агент. Чем слабее проверки, тем выше риск reward hacking и бесполезной траты токенов.
Начинайте с простых циклов: одна задача, один оракул, жёсткий лимит итераций. Постепенно усложняйте: добавляйте оракулы, увеличивайте бюджет, расширяйте область задач. Экспериментируйте с осторожностью. Loop Engineering - это инструмент, который работает только в руках инженера, понимающего его ограничения.