Хватит писать промпты: как собрать ИИ-агента, который работает за вас круглосуточно

Каждое утро один и тот же ритуал: открываешь ноутбук, запускаешь агента, объясняешь ему задачу, ждёшь результат, правишь, объясняешь заново. А теперь представьте, что агент просыпается сам, сам находит задачи, сам замечает проблемы и к вашему приходу уже держит готовый результат на столе. Именно про это разговор в индустрии, который получил название loop engineering, инженерия циклов.

Идея не возникла на пустом месте. В июне 2026 года несколько известных инженеров почти одновременно сказали одно и то же: пора переходить на новый уровень. Питер Штайнбергер, создатель OpenClaw, написал в X две строчки, которые собрали почти девять миллионов просмотров. Смысл простой: перестаньте промптить кодинг-агентов, начните проектировать циклы, которые будут промптить их за вас. Борис Черни добавил, что давно не пишет промпты сам, у него крутятся циклы, и уже они разбираются, что делать. Эдди Османи сформулировал ещё жёстче: инженерия циклов это когда вы заменяете себя как человека, который сидит и промптит, и вместо этого строите систему, которая делает это сама.

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

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

Первый шаг это обнаружение задач. Здесь важна одна мысль: автоматизация должна запускать навык, то есть записанное и обновляемое знание о проекте, а не простой промпт, вклеенный в расписание. Вклеенный промпт гниёт, потому что его никто не обновляет. Навык же читает источники сам, решает, что стоит внимания, и записывает результат. Самая важная часть тут это раздел с запретами. Если вы не напишете никогда не делай мердж, однажды цикл сделает мердж за вас. Главная опасность этого шага в том, что вы автоматизировали исполнение, но не автоматизировали выбор. Если вы каждое утро всё ещё сами говорите агенту, что делать, цикл никогда вас не удивит.

Второй шаг это раздача работы и её изоляция. Самый естественный порыв это запустить сразу пять агентов и помчаться быстро. Именно так рождается запутанный цикл: несколько агентов правят одни и те же файлы в одной папке, и день слияния превращается в археологию. Противоядие в одной строке: каждая задача получает свой отдельный worktree, изолированную рабочую директорию. Агенты никогда не работают на главной ветке, она остаётся посадочной полосой для человеческой проверки. И обязательно нужен потолок параллелизма, причём выбирать его нужно не по мощности машины, а по честному вопросу: сколько PR вы реально способны проревьюить. Stripe прогоняет больше тысячи PR в неделю через подобные циклы, и люди всё равно ревьюит каждый. Человек не ушёл из процесса, он просто пересел за другой стол: от написания кода к его ревью.

Третий шаг самый тяжёлый. Инженер Anthropic Притви Раджасекаран заметил: если попросить агента оценить код, который он только что написал, он почти всегда похвалит себя, даже если человек с первого взгляда видит посредственность. Дело не в глупости модели. Проверять собственную работу структурно бессмысленно: к моменту, когда код готов, контекст агента забит цепочкой самооправданий. Глядя на свой вывод, он видит не результат, а аргументы в пользу результата. Внутри цикла это превращается в катастрофу: каждый оборот кивает сам себе, и чем дольше всё работает, тем дальше уходит от реального качества. Решение структурное: привести отдельного агента-оценщика с другими инструкциями, в идеале другую модель, которая смотрит на код с нуля и по умолчанию считает его сломанным, пока не доказано обратное. Оценщик должен судить по поведению, а не по намерению: запустить тесты, открыть страницу, кликнуть, а не просто прочитать код и поверить ему.

Четвёртый шаг это память. Если вердикты оценщика живут только в окне контекста, то завтра в шесть утра цикл проснётся с чистым контекстом и ничего не вспомнит. Он заново переберёт всё с нуля, споткнётся о вчерашнюю нерешённую задачу или вообще пропустит её. Контекст это окно, которое агент видит сейчас и которое очищается. Память это состояние, записанное на диск, в markdown, базу или на доску задач. Цикл связывает сегодня с завтра только через память. Файл состояния обязательно коммитится в репозиторий, иначе завтрашний облачный запуск его просто не увидит. И есть тихая дисциплина, которая приходит вместе с памятью: читайте один образцовый PR в день и заставляйте себя объяснить, что цикл изменил и зачем. Как только вы не можете этого объяснить, ваша карта кодовой базы отстала от реальности.

Пятый шаг это расписание. Пока вы не повесили цикл на триггер, он останавливается в тот момент, когда вы перестаёте жать кнопку. Самое опасное здесь не ошибиться с cron, а наоборот настроить его правильно, потому что тогда цикл действительно начинает жить сам, и один баг может гонять его всю ночь, пока вы не проснётесь от счёта, который не узнаёте. Поэтому лимиты ставятся до первого автономного запуска, а не после первого страшного счёта: лимит на запуск, на день и на число повторов. Токен-лимит это не про экономию денег, а предохранитель, который превращает открытый риск в ограниченный. Uber ограничил инженеров суммой полторы тысячи долларов на человека в месяц на каждый инструмент после того, как сжёг бюджет на ai за четыре месяца. И всегда оставляйте одну дверь открытой: PR не сливаются автоматически, всё сомнительное отправляется человеку.

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

Цикл это честный усилитель. Принесёте понимание, он усилит понимание, принесёте лень, он усилит лень. Генерация кода становится почти бесплатной, а дефицитным остаётся суждение: какой план верный, на какой строке остановиться, что работает, но неверно в корне. Стоит строить цикл как человек, который собирается остаться инженером, а не просто тем, кто нажимает кнопку старт.