Книжный куб

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. В одном обороте такого цикла пять движений: 1) Поиск работы (discovery) 2) Передача задачи (handoff) 3) Проверка результата (verification) 4) Сохранение состояния (persistence) 5) Планирование следующего запуска (scheduling) Реализуются они через планировщики, изолированные git worktree, skills с проектным знанием, подключения к внешним системам, подагентов и состояние вне контекстного окна. По отдельности детали не новы. Новая здесь граница системы: человек перестаёт быть таймером, который после каждого ответа говорит агенту, что делать дальше. И здесь появляется главная инженерная проблема. Ошибка в промпте обычно живёт один ответ. Ошибка внутри цикла может попасть в файл состояния, вернуться в следующем проходе как установленный факт и стать основанием для новых изменений. Чем дольше ошибка остаётся незамеченной, тем больше её радиус поражения (blast radius). Поэтому самая ценная часть цикла - не механизм, который снова говорит агенту «работай», а механизм, способный вовремя сказать «нет». В тексте отдельно есть фокус на разделении исполнителя и проверяющего (generator/evaluator). Агент, который только что написал код, склонен слишком мягко оценивать своё решение. Проверяющий должен приходить с другим контекстом и действовать: запускать тесты, открывать приложение, проходить пользовательские сценарии, проверять API и сравнивать поведение с задачей. Anthropic описывает похожую обвязку, но там проверяющего тоже пришлось калибровать: он пропускал ошибки и иногда уговаривал себя принять слабый результат. Второй LLM - полезная независимая роль, но ещё не доказательство корректности. Из практических кейсов самый заметный - Stripe Minions: по словам инженера Stripe Стива Калиски, система подготавливает около 1300 машинно написанных PR в неделю. Финальное ревью делают люди, а надёжность держится на изолированных облачных средах, детерминированной оркестрации, тестах и CI. Это пример масштаба генерации, но не бенчмарк качества: число PR не говорит, сколько дефектов ушло в рабочую среду и сколько внимания съела проверка. У автономности цикла есть четыре неявные проблемы: 1) Долг проверки (verification debt) - накопленный непроверенный результат; 2) Потеря понимания (comprehension rot) - отставание нашей ментальной модели от кодовой базы; 3) Отказ от собственного суждения (cognitive surrender) - привычка соглашаться с машиной; 4) Раздувание расходов на токены (token blowout) - неконтролируемые повторы. Эти проблемы усиливают друг друга: чем больше непроверенного кода, тем хуже мы понимаем систему; чем хуже понимаем, тем охотнее отдаём ей следующие решения. Практический вывод из материала я бы сформулировал так: первый цикл должен быть маленьким и скучным. Например, ежедневный разбор упавшего CI или новых задач. Ему нужны постоянное состояние, отдельный проверяющий, жёсткий лимит попыток и токенов, изоляция задач и человеческая контрольная точка перед слиянием. Параллелизм стоит увеличивать только после того, как проверяющий действительно поймал несколько реальных ошибок, а не просто ни разу не возразил. А расширенно этот же материал мы разберём сегодня с Максимом Смирновым на стриме в 16:00. Приходите послушать и позадавать вопросы. #AI4SDLC #AI #Agents #Engineering #Architecture #Evals #Research