Mark Emelianov
RU

Medium · ИИ-инженерия, разработка программного обеспечения · Черновик

Паттерн четырёх циклов: как вести автономных агентов-программистов без дрейфа

Как сохранить дисциплину в ИИ-инженерии, когда агенты работают быстрее, чем вы успеваете проверять, — в том числе когда от дисциплины отклоняется её автор.

Впервые опубликовано на Medium 12 мая 2026 года; последняя правка 13 мая 2026 года. Читать на Medium. Время чтения: 17 минут.

Как сохранить дисциплину в ИИ-инженерии, когда агенты работают быстрее, чем вы успеваете проверять, — в том числе когда от дисциплины отклоняется её автор.

Это поисковая статья, а не рецепт. Её ценность не в том, что паттерн четырёх циклов уже доказан, а в том, что он даёт язык для реального сбоя: автономные агенты могут быть заняты, локально правы и всё равно не двигать продукт вперёд.

Если вы больше недели запускали агентов для кода на настоящей кодовой базе, вы, скорее всего, упёрлись в ту же стену, что и я. Агенты продуктивны: делают коммиты, проходят CI, обновляют документацию. Репозиторий растёт. Тесты добавляются. Новые механизмы строятся.

Четыре робота в синих, фиолетовых, оранжевых и зелёных вихрях кружат вокруг петли в форме бесконечности, у каждого свой инструмент: куб, лупа, планшет, диаграмма.

А потом вы отступаете на шаг, смотрите на продукт и понимаете: на самом деле ничего лучше не стало.

Агенты заняты. Результат настоящий. Но то, что видит пользователь, примерно там же, где было месяц назад. Кодовая база больше, доктрина толще, метаархитектура изящнее, а нужная вам функция по-прежнему не работает от начала до конца.

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

Режим сбоя

У этой патологии есть название: нейтральные запуски с дрейфом (drifting-neutral fires). «Запуск» (fire) — это одно выполнение цикла агента. Нейтральный запуск с дрейфом — тот, в котором агент работает, делает коммиты, проходит CI и не меняет ничего, что пользователь мог бы увидеть или измерить.

Типичные разновидности:

Каждый из этих сценариев кажется продуктивным, потому что агент ДЕЙСТВИТЕЛЬНО делает коммиты. Запуск «успешен» в тривиальном смысле: не упал, CI зелёный, дифф слит. Но измеримое состояние платформы не изменилось. Умножьте на 50 запусков в неделю — и получите дорогую беговую дорожку.

«Режим сбоя: нейтральные запуски с дрейфом»: инфляция доктрины, размножение заглушек, механизм без измерения, буксовка планов; противоядие — сходимость.

Дисциплина, описанная ниже, нужна для того, чтобы этот сбой нельзя было скрыть.

Архитектура четырёх циклов

Откажитесь от схемы «одного большого агента». Один цикл, пытающийся делать всё (реализацию, ревью, мониторинг, пользовательское тестирование), уходит в дрейф: приоритеты конкурируют, а разделения ответственности, которое могло бы это сдержать, нет.

Четыре цикла, у каждого своя замкнутая зона ответственности:

Каждый цикл работает в отдельной сессии. Общаются они через файловую систему (git для общего состояния; отдельные файлы директив у каждого цикла для передачи дел). Друг друга напрямую они не вызывают.

Ортогональность здесь принципиальна. Исполнитель не может одобрить сам себя; ревьюер не может сам что-то реализовать; аналитик не может выкатить предложенные им изменения; тестировщик не может исправить то, что оценивает. Каждому циклу приходится опираться на результаты других циклов.

Архитектура четырёх циклов: исполнитель (60 мин), ревьюер (30), аналитик (90), тестировщик в роли пользователя (4 ч); у каждого свой список «не может», общее состояние хранится в файлах.

Это то же разделение, что и в здоровой команде инженеров-людей — разработчик, ревьюер, QA, эксплуатация, — только закреплённое для агентов в явном виде. Циклы не «гибче» людей. Они жёстче. В этом и смысл.

Закон сходимости

Параллельность без прогресса хуже, чем отсутствие агентов вообще. Чтобы прогресс был, нужно жёсткое правило:

Каждый запуск заканчивается одним из трёх состояний: СХОДЯЩИЙСЯ (выпустил измеримое улучшение платформы с доказательствами «до/после»), ЯВНО НЕЙТРАЛЬНЫЙ (сознательно ничего не делал, причина названа) или РЕГРЕССИВНЫЙ (что-то ухудшил — требуется немедленный откат и письменный урок). Запуск, который отработал, что-то делал, но не дал измеримых изменений, — это ДРЕЙФУЮЩЕ-НЕЙТРАЛЬНЫЙ и режим сбоя, который цикл-ревьюер отмечает как нарушение дисциплины.

«Измеримое» — несущее слово. Для него нужна эталонная матрица состояния, которую каждый цикл читает при холодном старте: оценки областей функциональности, доля успехов, глубина очередей, задержка развёртывания — какие бы ни были главные оси вашего продукта. Запуск считается сходящимся, если какая-то ячейка матрицы улучшилась И ни одна не ухудшилась. Улучшение должно подтверждаться доказательствами «до/после» в теле PR.

Три робота на дорожках: зелёный сходящийся с растущей диаграммой, янтарный явно нейтральный с блокнотом, красный регрессивный с предупреждением; впереди — матрица состояния.

На практике:

Цикл-ревьюер применяет это правило к каждому PR. PR, не подпадающие ни под одно из трёх состояний, получают REQUEST_CHANGES. Автор должен либо найти измеримое улучшение, либо переклассифицировать PR как нейтральный с указанием причины, либо откатить.

Одно это правило отлавливает примерно 80% проблемы дрейфа. Для остального нужно больше.

Правило погашения

Правила накапливаются. Каждое новое правило, которое придётся читать будущему агенту, — налог на контекстный бюджет каждого будущего запуска. Поэтому:

Добавление нового документа доктрины, определения агента, пункта бэклога или шага процесса ТРЕБУЕТ вывести из обращения хотя бы один существующий (удалить, влить в другой или архивировать). Чистая сложность не может расти без явного одобрения оператора. Исключение: если новый пункт заменяет собой несколько старых за счёт сходимости, это чистое уменьшение и оно допустимо.

Это правило я нарушаю чаще всех. Трудно удалять то, что написал сам. Но альтернатива — документ доктрины, на чтение которого уходит 30 минут в начале каждой сессии, из-за чего агенты читают по диагонали, а значит, не следуют ему, а значит, уходят в дрейф.

Весы с надписью «Чистая сложность не должна расти» между корзиной «Добавить» с новой доктриной и бэклогом и корзиной «Вывести»; чек-лист ревьюера заканчивается пунктом «Одобрить».

Цикл-ревьюер проверяет каждый PR: добавил ли он новые файлы доктрины или пункты бэклога? Если да, вывел ли он что-то равного веса? Если нет, REQUEST_CHANGES с таким текстом: «дисциплина сходимости: этот PR добавляет N новых элементов доктрины, но выводит 0. Либо выведите один, либо задокументируйте, почему чистое добавление оправдано измеримым улучшением, вошедшим в этот PR.»

Правило запрета заглушек

Дисциплина сходимости ловит дрейф на уровне запуска. Дрейф на уровне артефакта она не ловит. За один запуск можно выпустить 10 артефактов, из которых 3 работают, а 7 — заглушки; в сумме запуск посчитается «сходящимся», а число заглушек на платформе тихо вырастет.

Правило для каждого артефакта:

Каждый выпускаемый артефакт — конечная точка, экран, виджет, возможность, определение агента, раздел руководства, что угодно — ДОЛЖЕН находиться в одном из трёх состояний: РАБОТАЕТ(проверено от начала до конца тестом, выводом смоук-теста или скриншотом в теле PR), ГОТОВО К РАБОТЕ(пробел назван явно, пункт для завершения поставлен в очередь в том же PR) или ЗАГЛУШКА С ОЧЕРЕДЬЮ(явная пометка status:stub, ссылка на пункт для завершения и понятное оператору объяснение при обращении к ней). ЗАГЛУШКА БЕЗ ОЧЕРЕДИ— нарушение дисциплины.

Классическое нарушение: выпустить экран с виджетом «Очередь недоступна — Повторить». Форма виджета в порядке; данных за ним не существует; пункта на завершение в очереди нет. Пользователь упирается в стену без объяснений и без пути вперёд.

Роботы на конвейере раскладывают артефакты по корзинам «Работает», «Готово к работе», «Заглушка с очередью» и ещё одной — «Заглушка без очереди», подписанной как нарушение дисциплины.

Более тонкое нарушение: выпустить файл документации со ссылками markdown на соседние файлы, которых не существует. Цель ссылки должна была быть заглушкой с очередью, но это даже не она, а пустота. Проверка ссылок у ревьюера роняет CI; гейт развёртывания отказывает; платформа встаёт. Именно этот сбой я выпустил в сессии, в которой писалась эта статья, и цикл-аналитик поймал его за несколько часов. Подробнее об этом ниже.

Универсальный протокол холодного старта

Каждый цикл при каждом запуске, прежде чем браться за работу, выполняет одни и те же шесть проверок:

Плюс седьмая проверка в цикле мониторинга:

  1. Проверить запас по лимитам. Какая доля текущего расчётного окна израсходована? Какова скорость расхода?

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

Протокол холодного старта перед любой работой: семь проверок от синхронизации с trunk до запаса по лимитам и порядок приоритетов реагирования из пяти шагов.

Это звучит бюрократично. На деле наоборот: протокол лишает агента свободы выбирать плохо. Циклу, который видит «гейт развёртывания отказал, четыре PR не проверены, CI красный, бэклог растёт, самая слабая область функциональности — на F», больше не нужно думать о приоритете. Протокол решает: сначала гейт развёртывания.

Тринадцать инвариантов надёжности

Протоколы проверки состояния по умолчанию хрупки. Проверки зависают по тайм-ауту, файлов не оказывается на месте, сеть отказывает. Поэтому:

Сетка «13 инвариантов надёжности»: жёсткие тайм-ауты, запасные режимы, конкурентность на основе аренды, журнал аудита, верификация после действия, потолок затрат, изоляция через worktree.

I-13 я добавил уже после этой сессии. Остальные двенадцать были у меня правильными. Схема столкновений, которую предотвращает I-13, описана ниже в разделе «Что всё ещё ломает этот паттерн».

Матрица моделей и режимов размышления

Современные платформы для агентов-программистов позволяют выбирать и размер модели, И режим размышления (обычный или расширенный с явным бюджетом на рассуждения). Разброс стоимости между самым дешёвым и самым дорогим вариантом — примерно 60 раз. Если для всех задач по умолчанию брать «самую умную модель с самым глубоким размышлением», вы будете тратить деньги на рутину, которой глубина не нужна.

Соответствие задач и моделей:

Матрица моделей и режимов размышления: девять видов работ сопоставлены с размером модели, режимом размышления, бюджетом на рассуждения и стоимостью; по умолчанию — малая модель с обычным размышлением.

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

Граница между агентом и оператором

Самое важное правило: агенты не перекладывают работу на оператора-человека молча.

Когда автономная система разработки чего-то не может — предметной экспертизы, позиционирования на рынке, тестирования на реальных пользователях, решений по бизнес-модели, — возникает соблазн вписать в документы «оператору следует…». Это нечестно. Так трудные части сбрасываются именно тогда, когда оператор менее всего готов их принять (на раннем этапе жизни продукта, когда MVP ещё нет).

Что агенты СДЕЛАЮТ: поднимут оценки функциональности со «сломано» до «работает»; отполируют дизайн; подготовят конкурентные разборы по открытым источникам; углубят интеграции; проведут UX-тестирование до появления клиентов (через цикл-тестировщик в роли пользователя); сделают сценарии онбординга; сделают функции отчётности.

Что может решить только оператор: стратегический приоритет (какая функция важнее всего для рынка, который он знает); бизнес-модель; окончательный эстетический выбор между двумя допустимыми дизайнами; явное разрешение на обход (когда агент говорит «этот тест нестабилен, можно обойти?»); пересмотр уровней приоритета.

Тестирование на реальных клиентах ОТЛОЖЕНО, а не переложено. Приводить реальных пользователей до MVP значит растрачивать их доброжелательность на сломанный продукт. Цикл-тестировщик в роли пользователя заменяет их, пока не будет достигнут порог MVP. После этого реальные пользователи приходят искать то, что упустил имитационный тестировщик.

Граница между агентом и оператором: агенты выдают исправления, полировку, разборы и UX-тестирование; стратегию, бизнес-модель и обходы решает только оператор.

Эту границу операторам нужнее всего отстаивать. Без неё агентная система превращается в нечто, что требует внимания оператора, вместо того чтобы делать работу.

Единый эталонный файл состояния

Все четыре цикла, все правила дисциплины, все протоколы — всё это бесполезно, если нет общего определения того, «каково состояние платформы прямо сейчас».

Один файл. Таблица трендов, в которую только добавляют. Каждая строка — снимок на момент времени. Столбцы — метрики, важные для продукта: оценки функциональности по областям, доля успехов, число блокеров, глубина очередей.

Каждый цикл читает этот файл при холодном старте. Сходящиеся запуски обновляют его. Нейтральные с дрейфом — нет. Через неделю-две тренд в этом файле И ЕСТЬ ответ на вопрос «приводят ли агенты к сходимости».

Единый state.md как таблица трендов, в которую только добавляют, читается и пишется всеми четырьмя циклами; исходы: сходящийся, нейтральный с дрейфом и застопорившаяся сходимость.

Если 7 снимков подряд не показывают движения, цикл-ревьюер выдаёт «сходимость остановилась — приостановить циклы, нужен метаразговор». Файл — это предохранительный клапан, который ловит случай, когда каждый отдельный запуск заявляет о продуктивности, а в сумме её нет.

Что всё ещё ломает этот паттерн

Этого раздела не было в первом наброске статьи. Чтобы его добавить, мне пришлось заплатить сессией дрейфа.

Дрейф автора

Тот, кто пишет правило (человек или агент), как правило, нарушает его, пока чернила не высохли. Я выпустил дисциплину для каждого артефакта: «каждый артефакт выходит как РАБОТАЕТ, ГОТОВО К РАБОТЕ или ЗАГЛУШКА С ОЧЕРЕДЬЮ» — и в той же сессии выпустил дерево документации с 16 висящими ссылками markdown, не подпадавшими ни под одно из этих состояний. Цикл-аналитик поймал это за несколько часов. Я был автором правила, которое отметило моё же нарушение.

Вывод: самоконтроль дисциплины не работает. Циклы-ревьюер и -аналитик — не приятное дополнение; только они ловят дрейф автора. Стройте их первыми. Правила, которые вы пишете сами, вас не свяжут без внешнего принуждения.

Столкновения в общем рабочем дереве

Если запускать все четыре цикла из одного физического каталога, они будут сталкиваться при каждой операции git. Один цикл делает git checkout <branch>, и у другого цикла git status вдруг показывает другую реальность. Наполовину слитые коммиты приписываются не той сессии. Неотслеживаемые файлы то появляются, то исчезают в зависимости от того, какую ветку последним переключил очередной цикл.

Исправление — инвариант I-13 выше: каждый цикл работает в собственном git worktree. Отдельный рабочий каталог, общая база .git. Команда git worktree add — одна строка, и она раз и навсегда устраняет весь этот класс сбоев.

Я усвоил это, раз за разом сталкиваясь с собственным циклом-аналитиком, пока вёл основную сессию в режиме прямого управления оператора в том же каталоге.

Ловушки запуска

Три ловушки, в которые вы попадёте ещё до того, как циклы начнут запускаться.

Со всеми тремя я столкнулся в одной сессии. Ни одна из них не экзотика — они критичны для любой настройки на хосте с Windows. Ни одна не описана в README платформ для агентов. Заложите день, чтобы их найти.

Разрыв между затратами и ценностью

Сессия, породившая эту статью, обошлась примерно в 157 долларов в пересчёте на вычисления по тарифам API (реальная подписка фиксирована; сумма в долларах — это то, сколько стоила бы та же работа при оплате по факту). В ней было слито девять pull request с доктриной, инфраструктурой и процессами. Ни одного улучшения продукта, видимого пользователю, она не дала. Исправление продукта, которое я закоммитил в начале сессии, так и не дошло до продакшена, потому что гейт развёртывания отказал — из-за 15 падающих тестов и 16 висящих ссылок markdown, которые я выпустил.

Это и есть разрыв между затратами и ценностью, названный прямо. Дисциплина, которую я описываю в этой статье, была выстроена именно в той сессии. Измеримое состояние платформы не улучшилось. Зато теперь существует инфраструктура, с помощью которой будущие сессии смогут его улучшить, — и нужно быть честным с собой (и со своим оператором), если именно на такой обмен вы пошли.

«Что всё ещё ломает этот паттерн»: дрейф автора, столкновения в рабочем дереве, ловушки запуска и сессия за ~157 долларов, слившая 9 PR без единого улучшения продукта.

Правило дисциплины сходимости, применённое задним числом, пометило бы всю сессию как ДРЕЙФУЮЩЕ-НЕЙТРАЛЬНУЮ. Это правило работает как задумано. И оно говорит кое-что неприятное: сессия, затеянная ради статьи о дисциплине, вряд ли способна одновременно двигать продукт вперёд, ведь каждая минута, потраченная на доктрину, — это минута, не потраченная на функцию. Планируйте с учётом этого.

Чего это НЕ сделает

Честные границы того, что дисциплина может и чего не может дать:

«Чего это не сделает»: дисциплина поднимает функции со «сломано» до «работает», но не достигнет высшей оценки, не определит стратегию, не найдёт реальных болей клиентов и не завоюет рынок.

Называть то, чего не случится, — часть дисциплины. Без этого операторы ждут от системы большего, чем она способна дать, и теряют доверие, когда получают меньше.

Во сколько это обходится

Сессия четырёх циклов, работающая по 8 часов в день в темпе, соответствующем матрице, стоит примерно как месячный бюджет инструментов для одного инженера среднего уровня. Реальная подписка фиксирована; ограничением служат лимиты на расчётное окно, а не доллары.

А если для всего брать самую крупную модель с самым глубоким размышлением? Примерно в 5–7 раз больше. Дисциплина матрицы — это разница между устойчивой автономной разработкой и счётом, вышедшим из-под контроля.

Стоимость отдельной сессии колеблется сильнее. Сессия, которая выдаёт чистую доктрину, как та, что породила эту статью, сжигает бюджет и не улучшает продукт. Это не потери, если доктрина окупится сходимостью в будущих сессиях, но ЭТО потери, если доктрина лежит без применения.

Инфографика «Во сколько это обходится»: базовая стоимость сессии из четырёх циклов, подобранная по размеру модель против «всегда самой большой» в 5–7 раз дороже, разбивка затрат по категориям и практические ориентиры.

Именно цикл-ревьюер заставляет доктрину окупаться. Без него доктрина копится мёртвым грузом.

Урок, который я усваиваю снова и снова

Каждый раз, добавляя в эту систему новое правило, агента или процесс, я добавляю нагрузку на будущее. Правило дисциплины сходимости — единственное, которое уменьшает нагрузку: оно заставляет любое другое добавление окупаться измеримым улучшением.

Патология, описанная в начале этой статьи, — «агенты продуктивны, а продукт не движется» — это сбой дисциплины, а не инструментов. Агенты делают именно то, что вы им сказали: делают коммиты, проходят CI, обновляют документацию. Им просто не сказали, что коммиты должны сдвигать измеримую ось.

Скажите им это — с явными правилами для каждого запуска и каждого артефакта, с единым эталонным файлом состояния, с разделением ответственности между четырьмя циклами, с честной границей того, что могут делать только люди, и с изоляцией через worktree, чтобы они не сталкивались, — и агенты становятся полезными.

Не волшебными. Полезными. Иногда.

Это «иногда» — то, чего не хватало в первом наброске статьи. Дисциплина — это цель. Даже когда она записана, даже когда правила явные, даже когда цикл-ревьюер работает, вы (и ваши агенты) всё равно будете дрейфовать. Дрейф ловят — для этого и нужен цикл-аналитик, — но не предотвращают. Механизм самокорректирующийся, а не самопредотвращающий.

Это различие важно. Литература об инструментах ИИ-инженерии полна «волшебных» обещаний. Реальность такова: небольшой набор дисциплинированных паттернов, жёстко обеспечиваемых другими агентами (а не самодисциплиной), которые заставляют автономных агентов выполнять настоящую работу большую часть времени, а в остальное время дрейф ловится и исправляется. Всё остальное — театр.

Робот держит планшет с чек-листом (взять пункт бэклога, написать код, добавить тесты, обновить документацию, открыть PR, сходящийся запуск) и показывает большой палец вверх.

Если вы запускаете агентов для кода на настоящей кодовой базе и видите описанные мной режимы сбоя, приведённые выше паттерны могут помочь. Они не новы; в большинстве своём это записанное то, что хорошие инженерные команды и так делают. Новизна в том, чтобы сделать их несущими для автономных циклов, где в непосредственной близости нет человека, который бы неявно их обеспечивал, — и в том, чтобы назвать режимы сбоя, которые переживают даже дисциплину.

Дополнение. Шпаргалка

Постер паттерна четырёх циклов: четыре цикла с зонами ответственности, общие папки состояния, три исхода запуска, пример матрицы состояния и закон сходимости.

Эта страница — полная копия истории в том виде, в каком она опубликована на Medium. Читать на Medium. Иллюстрации созданы с помощью ИИ.