Сегодня в 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