Инженерия циклов сейчас на пике популярности. Пролистайте любой технический форум, и вы найдете споры о том, что нам пора перестать относиться к ИИ-агентам как к чат-ботам, которых нужно обучать с помощью хитроумных промптов. Вместо этого, говорят они, мы должны проектировать циклы: автономные процессы, которые позволяют агенту планировать, выполнять, проверять свою работу и итерировать, пока мы спим. Это предложение звучит заманчиво. Если цикл построен грамотно, агент будет придерживаться курса без постоянного контроля человека, превращая сырые намерения в готовый результат за одну ночь.
Это обещание прекрасно работает в теории. На практике большинство агентов уже используют циклы. Они генерируют код, проверяют ошибки компилятора или проваленные тесты, исправляют код и запускают набор тестов снова. Этот базовый цикл обратной связи не нов. То, к чему сейчас призывают сторонники метода, — это нечто более амбициозное: внешний цикл, который управляет всей задачей целиком, а не только синтаксическими ошибками. Создание такого внешнего цикла — вот где начинаются трудности, потому что разработка программного обеспечения редко представляет собой закрытую систему с фиксированными правилами.
Проблема проектирования цикла
Цели продукта часто размыты. Вы редко начинаете с идеального «определения готовности» (definition of done). Чаще вы обнаруживаете реальную цель, когда уже по уши погружены в разработку. Требование, которое казалось простым на доске, на деле оказывается полным набором граничных случаев, полностью меняющих форму решения. Когда вы заключаете агента в жесткий цикл, эта жесткость становится недостатком. Цикл продолжает бить в цель, которая может оказаться неверной. Хуже того, гибкий цикл иногда разрешает тупиковую ситуацию, незаметно подстраивая цель под любой результат, который ему удалось выдать. Ни один из этих исходов не полезен. Один тратит вычислительные ресурсы; другой уверенно выпускает мусор.
Более глубокая проблема — стоимость спецификации. Если вы хотите, чтобы цикл работал без присмотра, вы должны написать спецификацию, которая предвидит почти всё. Что именно должен изменить агент? Какое существующее поведение является священным и должно быть сохранено? При каких именно условиях агент должен прекратить итерации? Какие риски допустимы, а какие побочные эффекты должны вызвать немедленную остановку? Написание такого документа может занять больше времени, чем просто сидение рядом с агентом и управление им в процессе выполнения задачи в реальном времени. Вы платите огромный авансовый налог в обмен на автоматизацию, которая окупается только в том случае, если верификация обходится значительно дешевле, чем само выполнение.
Где циклы действительно оправдывают себя
Это не значит, что инженерия циклов бесполезна. Это значит, что это специализированный инструмент, а не универсальная стратегия. Циклы эффективны, когда затраты на верификацию растут, а критерии успеха однозначны. Есть три области, где это правило работает.
Рутинная механическая работа. Вспомните задачи, из-за которых старшим инженерам хочется уйти на пенсию: запуск приложений в определенной последовательности, прокликивание интерфейса развертывания для подтверждения каждого этапа, поиск известных строк ошибок в логах после релиза или проверка того, что конфигурационный файл был записан на все нужные узлы. Эти шаги утомительны для человека, но тривиальны для проверки. Цикл может «присматривать» за процессом, проверяя эндпоинты состояния после каждой перезагрузки и выполняя откат при первых признаках проблем. Человек по-прежнему определяет план развертывания. Цикл просто выполняет его с терпением машины в два часа ночи.
Измеримые цели оптимизации. Когда успех измеряется числом, циклы невероятно эффективны. Снизить задержку p99 ниже 150 миллисекунд. Уменьшить объем занимаемой памяти на двадцать процентов. Мигрировать «горячий путь» с Python на Rust и убедиться, что все существующие юнит-тесты проходят. Цикл может сгенерировать изменение, провести бенчмарк, оставить тот вариант, который дал результат, и отбросить остальные. Поскольку верификация автоматизирована, а пространство поиска велико, совокупные затраты на ручную проверку сделали бы такую работу непрактичной без цикла. Цель фиксирована. Путь неизвестен. Это идеальное сочетание.
Операционные плейбуки. Реагирование на инциденты и тикеты поддержки часто следуют паттернам, которые люди уже давно изучили. Определенный класс ошибок в продакшене всегда требует ротации учетных данных и очистки кэша. Категория запросов в поддержку может быть решена возвратом средств при соблюдении трех конкретных условий. Цикл может отслеживать эти триггеры и выполнять плейбук, передавая задачу человеку только в том случае, если паттерн нарушается. Он не решает, что плейбук верен; он просто обеспечивает согласованность на масштабе и скорости, с которыми дежурные инженеры не могут сравниться.
Регуляторы, а не составители эталонов
There is a crucial distinction missing from much of the current conversation. Loops are regulators. They keep a system aligned with a predetermined target, much like a thermostat keeps a room at seventy-two degrees. But the thermostat does not choose seventy-two. Someone had to decide that was the right temperature first.
Applied to software, this means an agent inside a loop can fix bugs, refactor functions, or tune parameters all day long. It cannot, however, decide which feature actually helps the customer or whether a bug is worth fixing before the next release. Those choices require judgment about business context, user pain, and strategic priority. Agents execute. Humans decide. Confusing the two is how teams end up with beautifully optimized systems that solve the wrong problem.
Loop engineering is useful, but it is narrow. It helps you run the machine with discipline and speed. It does not decide what machine to build, who it is for, or what success looks like in human terms. The judgment about which feature matters, which risk is acceptable, and when the goal itself needs to change lives with you. Build loops for the work you already understand well enough to verify automatically. Keep yourself in charge of everything else.
This article draws on ideas originally discussed by Isaac Hagoel in “Loop Engineering Minus The Hype.” For more engineering discussions, join our learning community on Telegram.