Loop Engineering: как проектировать циклы, которые сами запускают coding agents

Разговор начинается с проверки статуса источника. Текст HuaShu выглядит как научная публикация, но является независимой working note: он сводит идеи Addy Osmani, Anthropic и других практиков, не проходит peer review, не содержит controlled experiment и не представляет позицию IEEE или Anthropic. Поэтому участники используют его как удобную таксономию и практический playbook, а не как доказательство эффективности подхода.

Главная смена роли состоит в выходе человека из каждого turn. Prompt engineering управляет одним обращением, context engineering — наполнением текущего окна, harness engineering — инструментами и завершением одного run. Loop engineering добавляет повторный запуск, расписание, обратную связь и состояние между runs. Инженер теперь задаёт источники задач, правила проверки, границы доступа, бюджет и точки остановки. Вместе с автономностью растёт blast radius: ошибка может пережить ночь, попасть в persistent state и стать входом следующего прохода.

Один проход loop состоит из пяти обязательных движений. Discovery находит актуальную работу; handoff изолирует её для исполнителя; verification принимает или отклоняет результат; persistence сохраняет состояние вне разговора; scheduling запускает следующий проход. Их реализуют automations, worktrees, skills, connectors, sub-agents и memory. Простой timer ещё не создаёт loop: без discovery, проверочного feedback и внешнего state система лишь повторяет одну команду. Пропуски дают узнаваемые сбои — слепой, запутанный, поддакивающий, забывчивый или полностью ручной цикл.

Самая трудная часть — evaluator, способный сказать «нет». Автор решения уже убеждён собственной цепочкой рассуждений, поэтому отдельный проверяющий начинает с чистого контекста и скептической роли. Он должен оценивать не уверенный self-report и не только diff, а наблюдаемое поведение: запускать тесты, открывать интерфейс, проверять API и состояние данных, собирать evidence. Даже зелёные тесты не доказывают полноту результата, а LLM-evaluator тоже ошибается, поэтому deterministic gates и человеческое review остаются частью конструкции. Дорогая проверка оправдана прежде всего там, где задача выходит за границу надёжной solo-работы модели.

Незаметная работа агентов создаёт четыре связанных долга. Непроверенный output накапливает verification debt; быстрые изменения размывают понимание системы; затем наступает cognitive surrender — человек перестаёт формировать собственное суждение; retries и helpers раздувают расход токенов. Когда генерация кода, планов и PR дешевеет, узким местом становится judgment: решить, какую задачу вообще стоит делать, чему доверять и где остановиться. Throughput без учёта дефектов, времени review и восстановления вознаграждает не тот результат.

Первый production loop советуют делать маленьким, но полным: один источник задач, один finding за проход, изолированный worktree, внешний state, независимый evaluator и обязательное human review. До unattended run нужны лимиты токенов, времени, повторов и действий; для внешнего текста — защита от prompt injection и минимальные права; для изменений — audit trail, rollback и kill switch. Масштабировать discovery и добавлять параллелизм стоит только после собственного eval по качеству, escaped defects, точности evaluator, стоимости, latency и времени человеческой проверки.