Сборка и проверка: план как артефакт и эвалы в CI
Как агент пишет код, разобрано в разделе «Практика»: постановка задачи, план до правок, проверяемые шаги, git как страховка. На уровне цикла к этому добавляется организационный слой: план становится закоммиченным артефактом, личные приёмы становятся общими правилами, а проверкой занимается не только человек в конце, но и конвейер на каждом изменении.
План становится артефактом
Заголовок раздела «План становится артефактом»Внутри одной сессии план-файл работает внешней памятью агента, как описано в Контекст-инжиниринге. Цикл добавляет ему вторую роль: утверждённый план коммитится как plan.md до начала реализации, рядом с intent.md и spec.md.
Критерий готовности плана: человек, не видевший диалога, может реализовать задачу по одному этому файлу. Если по ходу работы выяснилось, что план был неверен, правка plan.md входит в тот же коммит, что и изменение кода. Тогда на ревью дифф сверяется с планом, а расхождение между ними само по себе сигнал: либо агент ушёл в сторону, либо план не пережил встречи с кодом.
Память и скилы как знания организации
Заголовок раздела «Память и скилы как знания организации»Файлы памяти и скилы заводятся на уровне команды, и цикл добавляет им дисциплину сопровождения:
- Память короче страницы. CLAUDE.md или AGENTS.md читается агентом целиком в каждой сессии, поэтому туда идут только команды, соглашения и частые ошибки. Рабочее правило пополнения: агент повторил ошибку дважды, значит появляется запись.
- Изменение через пул-реквест. Память и скилы живут в git и меняются так же, как код. Когда скил кодирует политику организации, например регламент безопасного API, изменение подписывает владелец этой политики, а инженеры получают обновление со следующей сессией.
Метрики здесь читаются из той же истории: частота повторных ошибок агента после записи в память и время от изменения политики до обновлённого скила.
Инженер как оркестратор: параллельные сессии
Заголовок раздела «Инженер как оркестратор: параллельные сессии»Когда план разбит на независимые части, один инженер ведёт несколько сессий, каждую в своём git worktree, и роль смещается от написания кода к управлению работами. Делить задачи между сессиями удобно по затрагиваемым файлам: независимость видна прямо из плана, а всё, что трогает общие файлы, остаётся последовательным.
Начинать разумно с двух-трёх параллельных сессий, а субагентам отдавать повторяющиеся узкие проверки внутри одной сессии. Правила и разрешения репозитория действуют на все сессии одинаково, поэтому рост параллельности не ослабляет контроль. Мера успеха: сколько сессий инженер ведёт при том же качестве ревью и какую долю времени он направляет работу, а не ждёт её окончания.
Петля обратной связи: агент проверяет себя
Заголовок раздела «Петля обратной связи: агент проверяет себя»Этап Test начинается ещё внутри сессии: агент прогоняет тесты, сборку и сравнение с макетами сам и итерирует до зелёного состояния, прежде чем результат увидит человек. Чтобы петля работала, ей нужны три вещи: одна команда-обёртка вроде make test, ненулевой код выхода при провале и количественные критерии успеха вместо «должно стать лучше».
Человеческая сторона этой проверки разобрана на странице Проверка результатов агента: финальное «принято» остаётся за человеком.
Эвалы в CI: проверка поведения, а не кода
Заголовок раздела «Эвалы в CI: проверка поведения, а не кода»Тесты проверяют код, но в цикле появился второй движущийся объект: конфигурация самого агента. Смена модели, правка промптов и скилов меняют поведение агента без единой строчки в коде продукта, и ловить это призваны эвалы (evals): наборы реальных задач с ожидаемыми исходами, на которых проверяется качество поведения агента.
Практика выглядит так. Команда собирает двадцать-пятьдесят реальных задач из своей работы, определяет для каждой критерии приёмки и запускает набор в CI при каждом изменении конфигурации агента. Каждый инцидент в продакшене добавляет в набор постоянный регрессионный эвал, а слияние блокируется, пока доля успешных прогонов ниже порога. Работает та же логика, что и с золотым набором вопросов в оценке качества RAG: фиксированный набор задач превращает «вроде стало хуже» в измеримую регрессию.
Метрики этапа: доля успешных прогонов эвалов во времени, скорость превращения инцидента в эвал и число регрессий, пойманных в CI, против дошедших до продакшена.
Что дальше
Заголовок раздела «Что дальше»- Выкатка и сопровождение: что происходит с изменением после зелёных проверок.
- Проверка результатов агента: человеческая половина этапа Test.
- Субагенты и расширения: механика параллельной работы и хуков.