Узкое место переезжает, а не исчезает
Когда генерация кода ускоряется, ограничением становятся формулировка намерения, проверка, выпуск и управление изменениями. Поэтому простое добавление агента в этап Build только увеличивает очередь на review. Процесс становится AI-native не от доли сгенерированного кода, а от того, что каждая стадия оставляет следующей проверяемый вход.
Артефактная цепочка
Минимальная форма цикла:
intent.md → spec.md → plan.md → diff + tests → review findings → incident → новый intent.md| Артефакт | Что фиксирует | Кто ставит gate |
|---|---|---|
intent.md |
проблема, ожидаемый результат, ограничения и метрики | владелец продукта |
spec.md |
поведение, интерфейсы, политики и критерии приёмки | продукт и архитектура |
plan.md |
затрагиваемые файлы, порядок, риски и способ доказать результат | инженер |
| diff + tests | реализацию и исполнимое свидетельство | CI и reviewer |
| review findings | принятые риски и незакрытые замечания | человек на релизном gate |
| incident record | наблюдённое последствие и доказательства | эксплуатация |
Переход заканчивается принятым и версионированным артефактом в его канонической системе, а не сообщением в чате. Следующий агент читает устойчивый контракт и durable linkage между стадиями. В Git-first процессе цепочка коммитов становится аудитом движения от намерения к последствию; при внешнем источнике эту роль выполняет связка record ID ↔ commit/PR (Evidence Spine).
plan.md проверяется простым тестом: сможет ли другой исполнитель реализовать его, не видя исходный разговор. Если во время реализации план изменился, изменение синхронизируется с артефактом — иначе план превращается в ложное свидетельство.
Источник истины выбирается по виду артефакта
Не обязательно переносить весь процесс в Git. Для каждого вида артефакта нужен один источник истины: например, intent живёт в трекере, а plan и diff — в репозитории. Между системами хранится двусторонняя минимальная связь: ID записи ↔ commit SHA/PR. Копия без такой связи быстро расходится с оригиналом.
Мягкий контур не заменяет жёсткий
Skills и файлы инструкций применяют политики в момент проектирования и сборки, но остаются советующим контуром. Критические инварианты принуждаются детерминированно: hook, permission, branch protection, CI, изоляция среды или ручной gate (Agent Harness).
Особый конфликт интересов возникает в цикле починки: агенту, который исправляет реализацию, нельзя позволять ослабить тест или evaluator, заставивший её упасть. Проверяемый артефакт замораживается на время цикла либо его изменение выносится в отдельный review (Generator Evaluator).
Эксплуатация замыкает разработку
Рабочая схема on-call начинается с детерминированного сигнала и только затем включает агента для сбора фактов и гипотез. Агент не должен сам создавать себе полномочия на исправление: read-only расследование, подготовка proposal/PR и выпуск — разные роли.
Инцидент не заканчивается постмортемом. Его след превращается в:
- новый
intent.md, если требуется изменение продукта; - регрессионный тест или eval-кейс;
- уточнение политики или инструмента только после доказанного повторяемого пробела (Skill Change Control).
Так Maintain становится входом следующего цикла, а не хвостом линейной схемы.
Что в playbook является примером, а не нормой
Рекомендации вроде 20–50 задач в eval-наборе, двух-трёх параллельных сессий и границ 1σ/2σ/3σ полезны как стартовые иллюстрации, но не переносятся без калибровки. Anthropic описывает собственный продукт и клиентскую практику; методики независимого сравнения и универсальных порогов публикация не даёт.
Связано с
- ADLC — жизненный цикл самой агентной системы, а не разработки с помощью агента
- Agent First Repository — почему договорённость должна стать доступным агенту артефактом
- Agent Harness — где мягкая инструкция превращается в исполнимый gate
- Evidence Spine — сквозная связь намерения, решения, действия и последствия
- Generator Evaluator — внешний критерий и защита evaluator от генератора
- Skill Change Control — почему инцидент сначала создаёт evidence и proposal