Loop Engineering: почему главная часть агентного цикла - это право сказать «нет» (Рубрика AI4SDLC)
Сегодня в 16:00 по Москве мы будем разбирать на стриме с Максимом Смирновым материал "Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents", поэтому мне пришлось подготовиться и прочитать его заранее:) Ниже я оставлю короткую выжимку, а за расширенной версией приходите на стрим.
Начну с того, что мне сложно было понять статус статьи - несмотря на название и вёрстку под IEEE, это не статья Anthropic и не публикация IEEE. На ASIXIV материал появился 25 июня 2026 года в разделе curated; PDF прямо называет себя независимой переработкой гайда HuaShu в формате конференционной статьи. В основе - статья Addy Osmani, инженерный блог Anthropic и публичный кейс Stripe. Сведений о рецензировании нет, поэтому я бы читал текст как практический плейбук, который ещё предстоит проверять на своей системе.
Если убрать очередное xXx Engineering из названия, главный тезис простой: следующий шаг - не лучше управлять одним запуском агента, а спроектировать систему, которая сама находит работу, отдаёт её агенту, проверяет результат, сохраняет состояние и решает, когда запуститься снова.
В статье приводится такая лесенка знакомых концепций - Prompt engineering отвечает за одну инструкцию; - Context engineering - за то, что модель видит сейчас; - Harness engineering - за обвязку, инструменты, ограничения и критерий завершения одного запуска; - Loop engineering - за повторяемый цикл поверх harness.
В одном обороте такого цикла пять движений:
- Поиск работы (discovery)
- Передача задачи (handoff)
- Проверка результата (verification)
- Сохранение состояния (persistence)
- Планирование следующего запуска (scheduling)
Реализуются они через планировщики, изолированные git worktree, skills с проектным знанием, подключения к внешним системам, подагентов и состояние вне контекстного окна. По отдельности детали не новы. Новая здесь граница системы: человек перестаёт быть таймером, который после каждого ответа говорит агенту, что делать дальше.
И здесь появляется главная инженерная проблема. Ошибка в промпте обычно живёт один ответ. Ошибка внутри цикла может попасть в файл состояния, вернуться в следующем проходе как установленный факт и стать основанием для новых изменений. Чем дольше ошибка остаётся незамеченной, тем больше её радиус поражения (blast radius). Поэтому самая ценная часть цикла - не механизм, который снова говорит агенту «работай», а механизм, способный вовремя сказать «нет».
В тексте отдельно есть фокус на разделении исполнителя и проверяющего (generator/evaluator). Агент, который только что написал код, склонен слишком мягко оценивать своё решение. Проверяющий должен приходить с другим контекстом и действовать: запускать тесты, открывать приложение, проходить пользовательские сценарии, проверять API и сравнивать поведение с задачей. Anthropic описывает похожую обвязку, но там проверяющего тоже пришлось калибровать: он пропускал ошибки и иногда уговаривал себя принять слабый результат. Второй LLM - полезная независимая роль, но ещё не доказательство корректности.
Из практических кейсов самый заметный - Stripe Minions: по словам инженера Stripe Стива Калиски, система подготавливает около 1300 машинно написанных PR в неделю. Финальное ревью делают люди, а надёжность держится на изолированных облачных средах, детерминированной оркестрации, тестах и CI. Это пример масштаба генерации, но не бенчмарк качества: число PR не говорит, сколько дефектов ушло в рабочую среду и сколько внимания съела проверка.
У автономности цикла есть четыре неявные проблемы:
- Долг проверки (verification debt) - накопленный непроверенный результат;
- Потеря понимания (comprehension rot) - отставание нашей ментальной модели от кодовой базы;
- Отказ от собственного суждения (cognitive surrender) - привычка соглашаться с машиной;
- Раздувание расходов на токены (token blowout) - неконтролируемые повторы. Эти проблемы усиливают друг друга: чем больше непроверенного кода, тем хуже мы понимаем систему; чем хуже понимаем, тем охотнее отдаём ей следующие решения.
Практический вывод из материала я бы сформулировал так: первый цикл должен быть маленьким и скучным. Например, ежедневный разбор упавшего CI или новых задач. Ему нужны постоянное состояние, отдельный проверяющий, жёсткий лимит попыток и токенов, изоляция задач и человеческая контрольная точка перед слиянием. Параллелизм стоит увеличивать только после того, как проверяющий действительно поймал несколько реальных ошибок, а не просто ни разу не возразил.
А расширенно этот же материал мы разберём сегодня с Максимом Смирновым на стриме в 16:00. Приходите послушать и позадавать вопросы.
#AI4SDLC #AI #Agents #Engineering #Architecture #Evals #Research