Вот неприятный паттерн, который стоит за многими внедрениями agentic coding: стадия build становится радикально быстрее, а время от идеи до продакшена почти не двигается.
С агентами всё в порядке. Не в порядке всё вокруг них. Гейты согласования, refinement-встречи, очередь на ревью, еженедельный change board — всё это проектировалось для мира, где написание кода было самой дорогой стадией delivery. Этого мира больше нет. Процесс, построенный под него, остался, и теперь именно он — узкое место.
В августе 2026 Anthropic опубликовал The AI-Native SDLC Playbook — большой практический документ о том, как перестроить жизненный цикл разработки под эту реальность. Его стоит прочитать целиком. Этот пост — мой инженерный взгляд на него: в чём основная идея, какие части, на мой взгляд, важнее всего, где я бы был осторожен и как всё это связано с дисциплинами, о которых мы говорили в этой серии, — spec-driven development, контекст-инжиниринг и evals.
Почему старый SDLC ломается под агентами
У классического жизненного цикла шесть стадий — plan, design, build, test, deploy, maintain — и у каждой есть владелец. Продакт пишет требования. Архитекторы пишут дизайн. Инженеры строят. QA верифицирует. Release отгружает. Ops наблюдает. Работа движется между стадиями в виде документов, тикетов и sign-off’ов.
Такая форма имела смысл. Когда реализация занимала недели или месяцы, вам хотелось тяжёлого согласования заранее: PRD, оценки, security-ревью. Каждый контроль в системе молча предполагает, что каждый шаг выполняет человек и что человек может прочитать каждую строку.
Сделайте стадию build почти бесплатной — и произойдут три вещи:
- Узкое место смещается. Planning, review и deployment по-прежнему идут со скоростью людей. Они становятся самой медленной частью системы.
- Построчное ревью перестаёт масштабироваться. Когда агенты пишут большую часть диффа, «человек читает каждую строку» превращается либо в бесконечную очередь, либо в резиновый штамп.
- Governance становится дорогим. Исключения, которые ждут ежемесячного комитета, теперь блокируют работу, сделанную за один день.
Безопасность — самый яркий пример. Команда security, рассчитанная на человеческий объём, стоит перед выбором: позволить очереди расти или позволить уходить в продакшен недопроверенному коду. Регулируемая компания не может принять ни то, ни другое. Её проверки должны масштабироваться вместе с выходом агентов — а значит, больше не могут быть чисто человеческими.
Что на самом деле значит «AI-native»
Определение из playbook — самая полезная для меня часть, потому что это не «добавь AI в каждый шаг». Это: сохраните цели контроля, смените способ их обеспечения. Вам по-прежнему нужны прослеживаемость, разделение обязанностей, верифицированные изменения и авторизованные релизы. Просто вы перестаёте обеспечивать их встречами и ручным чтением и начинаете обеспечивать артефактами, hooks и автоматическими проверками.
Отсюда вытекают три структурных изменения:
- Линия становится циклом. Сигналы из продакшена автоматически возвращаются в planning, а не ждут post-mortem, по которому, возможно, никто никогда ничего не сделает.
- Передачи становятся коммитами. Каждая стадия заканчивается коммитом артефакта в систему контроля версий, и следующая стадия его читает.
- Люди переходят от производства к суждению. Люди остаются ответственными за каждое решение; они просто тратят внимание на ревью артефактов, а не на их написание.
Нить артефактов
Это хребет всей модели, и именно эту идею я бы позаимствовал, даже если проигнорировать всё остальное:
| Стадия | Закоммиченный артефакт | Кто его оценивает |
|---|---|---|
| Plan | intent.md — проблема словами инициатора | Product owner принимает или отклоняет |
| Design | spec.md — требования + дизайн с применённой политикой | Product owner, плюс владельцы политик по помеченным вопросам |
| Build | plan.md, затем дифф и тесты | Инженер (tech lead для рискованной работы) |
| Test | Вывод тестов, результаты eval, прикреплённые к PR | Автоматические гейты + code owners |
| Deploy | PR с findings ревью, авторизация релиза | Code owner, release manager |
| Maintain | Запись об инциденте → новый intent.md | On-call / владелец сервиса проводит triage |
Ранние артефакты намеренно написаны в Markdown: их может читать и product owner, и агент. Начиная со build артефакты — это код и его записи.
Две вещи делают это сильным. Во-первых, цепочка и есть аудит-след: кто что просил, что произвёл агент, кто это одобрил — всё в истории git, без отдельной compliance-таблицы. Во-вторых, каждый принятый артефакт может стать триггером для следующей стадии. Смёрдженный intent.md запускает проход по spec. Одобренный spec.md открывает сессию в plan mode. Смёрдженный PR запускает пайплайн. Нарушенная метрика в продакшене пишет следующий intent.md. Это и есть «цикл».
Если вы читали пост про spec-driven development, это покажется знакомым: та же идея «спека как истина, код как кеш», только распространённая на весь жизненный цикл, а не на один шаг build.
Стадия за стадией: что меняется
Я не буду пересказывать playbook — идите и читайте его, — но вот форма каждой стадии и по одной идее на стадию, которая, по-моему, несёт больше всего веса.
Plan: зафиксировать intent один раз
Вместо того чтобы идея проходила через запись в бэклоге, user story, оценку в поинтах и две refinement-встречи — теряя смысл на каждом переходе, — человек, у которого возникла идея, обсуждает её с агентом и коммитит intent.md: проблема, желаемый результат, кого это затрагивает, ограничения, открытые вопросы.
Идея, которая важна: не-инженеры коммитят в git (через коннектор), так что исходная формулировка сохраняется. Метрика, за которой стоит следить, — время от первого разговора до закоммиченного intent; цель playbook — недели, сжатые до часов.
Design: применять политику при написании, а не на ревью
Требования и дизайн делаются в одной сессии. Агент читает принятый intent и производит spec.md, ограниченный организационными skills по безопасности, compliance, бренду и UX — и ему прямо велено помечать конфликты политик, а не молча выбирать одну из них. Помеченные вопросы уходят названным владельцам политик до того, как спеку увидит инженерия.
Идея, которая важна: применение политик сдвигается влево — из ревью PR в написание спеки. Запаздывающая метрика остроумна: считайте правки spec.md, сделанные после первого plan.md. Это rework, измеренный в числах.
Build: никакой реализации без принятого плана
Сессии начинаются в plan mode: агент читает кодовую базу, ничего не редактируя, и предлагает план — какие файлы изменятся, порядок работы, риски, как это будет доказано. Вы допрашиваете его («что сломается? какой шаг самый рискованный? что ты отверг?»), пока кто-то, не видевший разговора, не сможет реализовать по этому плану. Затем он коммитится как plan.md, и позднее ревью PR сверяет дифф с ним.
Вокруг этого стоят элементы, благодаря которым выходу агента можно доверять:
CLAUDE.mdкак общий контекст — короче страницы, только самое необходимое с первого дня. Рабочее правило: если агент дважды делает одну и ту же ошибку, добавьте исправление.- Skills для знаний, которые нужно применять единообразно по репозиториям (security review, API-стандарты). Версионируются, принадлежат владельцу политики.
- Hooks как детерминированные ограждения — блокировать правки защищённых путей, запускать форматтер после правок, не пускать секреты в диффы.
- Параллельные сессии в worktree и subagents — верификатор, который запускает приложение и отчитывается против
plan.md, ничего не исправляя; simplifier; researcher.
Идея, которая важна: skills — это рекомендация, hooks — принуждение. Skill делает соблюдение вероятным. Hook делает его гарантированным. Любой политике, которая обязана выполняться, нужна детерминированная подстраховка. Одно это различие предотвращает большинство инцидентов вида «мы же сказали агенту, почему он всё равно это сделал?», о которых я слышу.
Test: верификация до того, как посмотрит человек
Два слоя. Первый: агент получает feedback loop — одну команду (make test), которая завершается с ненулевым кодом при падении, перечисленную в CLAUDE.md вместе с тем, как выглядит здоровый вывод. Для багов: сначала написать падающий тест, закоммитить его, затем дать агенту починить код, не трогая тест, в идеале с hook’ом, блокирующим правки тестовых файлов в задачах на фикс. «Готово» значит верифицировано, с вставленным выводом в качестве доказательства.
Второй: непрерывные evals конфигурации агента. Соберите 20–50 реальных задач с принятыми исходами, превратите каждую в eval и запускайте сьют всякий раз, когда меняются CLAUDE.md, skills, hooks или модель. Изменение конфигурации, которое роняет pass rate, ревьюится до мёрджа. Каждый инцидент в продакшене становится постоянным eval.
Идея, которая важна: ваша конфигурация агента — это код, и она регрессирует как код. Это ровно тот аргумент из поста про evals, только применённый к harness, а не к продукту.
Deploy: агент идёт до гейта, но не сквозь него
Ревью PR идёт в обе стороны. AI-ревьюер прогоняет одни и те же проходы по каждому PR — баги и логика, безопасность, compliance против spec.md и plan.md — настроенные в REVIEW.md, которым владеет tech lead, с ограничением на придирки. Агент также сам отвечает на review-комментарии в своих PR. Findings никогда не одобряют и не блокируют сами по себе; одобрение code owner по-прежнему обязательно, а авторствующий агент не может одобрить собственную работу.
Hooks эволюционируют от «allow/block» к «ask»: деплой в продакшен приостанавливается, пока названный release manager его не авторизует. CI-джобы начинают с read-only (triage упавших билдов, классификация флаки-тестов, черновики changelog), затем добавляются write-джобы, которые всегда производят только PR. Deploy и rollback выставляются как инструменты, ограниченные окружением, с ярусами автономии: свободно в dev, ограниченно в staging, только подготовка в production.
Идея, которая важна: агент может действовать вплоть до гейта продакшена, но не сквозь него. Это одно предложение — модель governance, которую можно объяснить аудитору за тридцать секунд.
Maintain: замкнуть цикл
Предыдущие стадии требовали, чтобы человек их запустил. Здесь триггер — детерминированный скрипт, следящий за метрикой продакшена со скользящим baseline — доля падений CI, 5xx после деплоя, cycle time PR — с ярусными реакциями: лог при 1σ, read-only диагностика при 2σ, предложить PR или запустить заранее одобренный rollback при 3σ. Агент пишет свою диагностику как intent.md, а человек проводит triage: чинить сейчас, запланировать или отклонить (отклонения подстраивают полосы). После того как фикс выехал, инцидент становится eval.
Идея, которая важна: детекция детерминирована; суждение делегируется. Никакая модель не решает, есть ли аномалия. Модель лишь объясняет её и предлагает реакцию — через те же гейты, что и все остальные.
Три принципа в основе
Отбросьте названия продуктов — и playbook держится на трёх правилах. Я бы повесил их на стену:
- Артефакты в git — это аудит-след. Если это не закоммичено, этого не было.
- Skills советуют, hooks принуждают. Никогда не полагайтесь на хорошее поведение модели там, где политика обязана выполняться.
- Детерминированная детекция, делегированное суждение, человеческая авторизация. Скрипты решают когда, агенты предлагают что, люди одобряют стоит ли.
Где я бы был осторожен
Продавать это без оговорок было бы медвежьей услугой.
- Это документ вендора. Playbook написан Anthropic и построен вокруг Claude Code, плюс несколько продуктов, помеченных на момент написания как beta. Паттерны — закоммиченные артефакты, детерминированные гейты, evals на конфигурацию, ярусная автономия — не привязаны к инструменту и работают с другими агентами. Конкретика продуктов изменится; проектируйте вокруг паттернов.
- Ёмкость ревью по-прежнему потолок. Параллельные сессии помогают, только пока человеческое ревью успевает. Playbook советует начинать с двух-трёх сессий и добавлять больше, только если качество ревью держится. Команды, пропустившие это предложение, производят много правдоподобного кода, который никто по-настоящему не проверил.
- Блокировка через managed settings — это компромисс, а не шаблон. Каждое deny-правило стоит возможностей. Подгоняйте ограничения под классификацию данных каждого репозитория, а не копируйте самый строгий пример повсюду.
- Легаси-системы не исчезают. Jira, Figma и change boards существуют, потому что от них зависят аудиторы и другие команды. Ответ playbook прагматичен: для каждого артефакта объявите одну систему учёта — репозиторий, легаси-инструмент или хотя бы двустороннюю ссылку (артефакт ссылается на ID тикета, тикет — на SHA коммита). Сосуществование — это нормально; неоднозначность — нет.
- Цикл — это конечное состояние. Вы не начинаете с headless-агентов, реагирующих на алерты 3σ. Вы начинаете с ручного промптинга каждого шага, затем кодифицируете в slash-команды, затем в триггеры. Несколько plays не имеют предусловий —
intent.md,CLAUDE.md, feedback loop, approval hooks — и именно с них стоит начинать.
Как бы я внедрял это на реальной команде
Если бы я раскатывал это в следующем квартале, порядок был бы такой:
- Неделя 1–2:
CLAUDE.mdв каждом активном репозитории и feedback loop в одну команду (make test, завершающийся с ненулевым кодом). Ноль предусловий, немедленная отдача. - Неделя 3–4: plan mode по умолчанию. Коммитить
plan.mdдля каждого нетривиального изменения. Начать измерять first-pass merge rate. - Месяц 2: Hooks — защищённые пути, сканирование секретов, защита тестовых файлов во время фиксов. Выбрать одну неровно соблюдаемую политику и превратить её в skill с названным владельцем.
- Месяц 2–3: AI-ревью PR с
REVIEW.md, branch protection без изменений. Approval hooks на деплои в продакшен. - Месяц 3+:
intent.md→spec.mdдля product owners. Непрерывные evals конфигурации агента. И только потом — один замкнутый цикл на одной метрике.
Измеряйте по ходу — playbook к каждому play даёт опережающий и запаздывающий показатель, и эту дисциплину стоит скопировать, даже если всё остальное вы поменяете.
Карьерный угол
Описание работы сдвигается под всеми нами. Инженер в этой модели меньше печатает и больше пишет планы, достойные одобрения, ревьюит артефакты, проектирует гейты и оркестрирует параллельную работу. Tech leads становятся владельцами REVIEW.md, CLAUDE.md и eval-сьюта. Platform-инженеры становятся теми, кто кодирует governance в виде hooks и managed settings. Engineering-менеджеры получают жизненный цикл, где каждый шаг оставляет доказательства — а это, если вы когда-нибудь готовились к аудиту, немало.
Навыки, которые копят отдачу, — те, к которым playbook всё время возвращается: спеки, контекст, верификация и governance-as-code. Ни один из них не про конкретную модель, и ни один не устареет, когда выйдет следующая.
Глубже
Мы построили курс ровно вокруг этого: AI-Native SDLC: Engineering Delivery from Intent to Production. Шесть модулей, по одному на стадию жизненного цикла, каждый заканчивается закоммиченным артефактом на вашей собственной кодовой базе — шаблоны intent и spec, отлаженный CLAUDE.md, skills и hooks, eval-сьют для конфигурации вашего агента, AI-гейт ревью и один замкнутый мониторинговый цикл.
Если хотите сначала основы: Claude Code Mastery для ежедневного agentic-цикла, Spec-Driven Development Foundations для методологии и OpenSpec Mastery для продакшен-воркфлоу со спеками. Для команд, раскатывающих это по организации, мы также проводим это как корпоративное обучение.
Источник: Anthropic, The AI-Native SDLC Playbook (август 2026). Этот пост — независимое резюме и комментарий; читайте оригинал ради полных plays, примеров и справочников по конфигурации. Связанное в этой серии: spec-driven development, контекст-инжиниринг, evals, OpenSpec, внедрение AI coding tools.
