Петли (loops) в AI-кодинге: как заставить агента работать на цель без человека

Видео короткое — около шестнадцати минут — но за это время Мэтью Берман даёт цельную, рабочую модель того, что сейчас называют главным сдвигом в разработке с ИИ. Не «ещё один промпт», а петля: способ отдать агенту цель и сказать «работай сам, пока не достигнешь». Ниже — разбор модели, семь конкретных петель и два честных ограничения.

Триггер × цель: вся механика в двух словах

Любая петля собирается из двух частей, и без любой из них её нет.

Триггер — чем петля запускается. Их три: вручную (вы сами говорите агенту «погнали»), по расписанию (каждую ночь, раз в неделю) и по действию (например, на открытие пул-реквеста). Смысл петель — убрать человека из цикла, поэтому в идеале уходят от ручного запуска к расписанию и событиям; но иногда ручной старт всё же нужен.

Цель — когда считать задачу выполненной. И здесь развилка, от которой зависит вся надёжность петли:

• Проверяемая (verifiable) — успех выражается числом или тестом, который можно прогнать детерминированно: «все страницы грузятся быстрее 50 мс», «100% покрытие тестами». Такую цель легко проверить, поэтому петля получается робастной.
• LLM как судья (LLM-as-a-judge) — успех нельзя свести к числу, и решать «достаточно ли хорошо» вы доверяете самой модели: «рефактори, пока не будешь доволен архитектурой». Гибко, но хрупко: вы отдаёте вкус и суждение на откуп ИИ.

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

Семь петель: от проверяемых к «на суд модели»

Автор не ограничивается теорией и показывает семь готовых петель — все они живут в его бесплатной Loop Library, откуда промпт можно скопировать как есть.

1. Страницы под 50 мс (verifiable, любимая петля автора). «Продолжай оптимизировать код; после каждого значимого изменения замеряй скорость загрузки каждой страницы в одинаковых условиях; продолжай, пока каждая страница не грузится под 50 мс». Агент проходит по всему приложению — окна, страницы, модалки — и грызёт каждую, пока та не уложится в порог. Запускается командой /goal (в Codex и Claude Code): она велит агенту работать, пока условие не выполнено. У автора прогон шёл около 50 минут.

2. Ночной свод документации (LLM-judge, по расписанию). «Каждую ночь просматривай кодовую базу целиком, сверяй документацию с изменениями за день, обновляй и открывай PR». Проверяемого критерия «полноты документации» не существует, поэтому это типичная judge-цель — полноту оценивает сама модель. Ставится через вкладку Automations как повторяющаяся задача.

3. Рефакторинг «пока не доволен» (Peter Steinberger). «Refactor until you are happy with the architecture» — триггер и цель в одной фразе, петля, которой, по словам автора, часто пользуется сам Штайнбергер. «Доволен» можно уточнить критериями: строгая простота, каждая строка DRY. Петля ведёт собственный прогресс в markdown-файле и может запускаться и вручную, и каждую ночь — днём вы деплоите код, ночью петля приводит его в порядок.

4. Покрытие логами (LLM-judge). «Просматривай логирование системы и добавляй недостающее покрытие, пока каждый важный путь не даёт полезные проверенные логи». «Важный» — нечёткое слово, поэтому что важно, а что нет, решает модель. Сама по себе петля скромная, но она — фундамент для следующей.

5. Ночной разбор прод-ошибок (по расписанию). «Каждую ночь просматривай прод-логи на ошибки; нашёл что-то поправимое — доберись до корневой причины, почини, проверь фикс, открой PR и напиши мне в Slack с находками и ссылкой на PR». Здесь и виден смысл петли №4: одна обеспечивает полезные логи, вторая по ним каждую ночь находит и чинит баги. Две простые петли, сложенные вместе, дают конвейер, которого по отдельности не было.

6. SEO/GEO-аудит видимости (по расписанию). «Прогони SEO/GEO-аудит по crawlability, индексации, интенту страниц, заголовкам, внутренним ссылкам, структурированным данным, цитируемости источников и answer-first контенту; ранжируй пробелы; чини самые рычажные; повторяй, пока не останется критичных технических проблем». Ключевое тут — GEO (Generative Engine Optimization): оптимизация не только под Google, но и под цитирование в ответах ИИ-поисковиков. Хорошо живёт на еженедельном запуске.

7. Полная оценка продукта (full eval, самая «размашистая»). «Создай N реалистичных сценариев по всем ключевым возможностям; до тестов задай критерии успеха и единый метод оценки; прогоняй каждый сценарий в одинаковых условиях, фиксируй результат, чини причину провалов и перегоняй, пока все сценарии не пройдут исходную планку качества». Похоже на тест-сьют, но петля недетерминирована: модель сама проходит по всем юзкейсам и решает, «достаточно ли хорошо». У автора такой прогон занимает 12 часов и больше — например, «придумай 100 разных запросов к LLM и суди, точен ли ответ с источниками; если нет — итерируй».

Эти семь — разный баланс надёжности и гибкости: чем ближе к verifiable-краю (петли 1, 5), тем предсказуемее результат; чем ближе к judge-краю (2, 3, 4, 7), тем больше вы доверяете вкусу модели.

Два честных предупреждения

Автор не продаёт петли как панацею и сам очерчивает две границы.

Петли пока не для всего — и особенно не для фич с нуля. Спроектировать петлю не всегда легко, и самое трудное — именно цель. Где успех проверяем («каждая страница под 50 мс») — петля идеальна. Где судит модель — становится хрупко. А для постройки новых фич с нуля честную цель сформулировать вообще нельзя: непонятно, какие фичи и в каком направлении агент решит делать. Показательна история, где автор задал целью «клонировать Excel с паритетом функций»: агент через computer use открыл Excel, кликал по интерфейсу, сверяя возможности, и крутился так сутками, пока его не остановили вручную. Вывод автора прямой: для day-zero разработки петли он не рекомендует.

Петли дорогие. Они автономно прожигают токены, пока не достигнут цели, а прогон длится от десяти минут до нескольких суток. Для «токен-максеров» с большим бюджетом это прекрасно; тем, у кого бюджет ограничен, петли сегодня могут просто не подойти. Отсюда практическое правило: первые прогоны держать при себе, поглядывая на расход, и заранее решать лимит времени на петлю — особенно для judge-целей, которые не всегда останавливаются сами.