Ещё пару лет назад самым дорогим и медленным этапом разработки было само написание кода. Ради этого выстраивали ритуалы оценки задач, требования проходили через десятки согласований, а архитекторы неделями превращали идею в техническое задание. Сегодня агенты вроде Claude Code пишут код за часы, а не недели, но процессы вокруг него остались прежними — те же согласования, ревью и передачи между отделами. Anthropic выпустила плейбук о том, как это исправить: не ускорить написание кода ещё сильнее, а пересобрать весь цикл разработки (SDLC) вокруг того, что агенты умеют делать уже сейчас.
Код больше не бутылочное горлышко
Классический SDLC состоит из шести стадий: планирование, дизайн, сборка, тестирование, деплой и поддержка. Каждая стадия традиционно принадлежит своей роли: продакт-менеджеры пишут требования, архитекторы превращают их в дизайн, инженеры реализуют, QA проверяет, релиз-команда выпускает, а операционная команда следит за тем, что уже работает в проде. Между этапами работа передаётся через документы, тикеты и подписи — процесс тяжёлый, но он был спроектирован ради контроля и подотчётности в эпоху, когда написание кода само по себе занимало больше всего времени.
Когда сборка кода перестаёт быть узким местом, происходит три вещи одновременно. Во-первых, бутылочное горлышко смещается на шаги слева и справа от сборки — планирование, ревью и деплой, которые всё ещё идут в темпе человека. Во-вторых, старые контроли перестают соответствовать реальности: построчная проверка кода имела смысл, когда его писал один человек, но не масштабируется, если агент генерирует большую часть диффа. В-третьих, растёт стоимость управления — исключения из процесса всё ещё маршрутизируются через еженедельные и ежемесячные комитеты, которые просто не успевают за темпом агентов. Показательный пример — служба безопасности: она рассчитана на человеческую производительность, и когда агенты умножают объём кода, очередь на проверку либо растёт, либо код уходит в прод недопроверенным. Ни один вариант не подходит регулируемой организации.
Что такое AI-native SDLC
AI-native SDLC — это не отказ от старых целей контроля, а новый способ их достигать. Вместо линейного потока процесс становится циклом, а ИИ встроен в каждую точку этого цикла. Ключевая идея — автоматизированная передача между стадиями: принятый артефакт одной стадии сам запускает следующую, без ручных пинков и совещаний по расписанию.
Через все стадии проходит одна и та же нить — зафиксированный артефact. Каждая стадия заканчивается тем, что в систему версионирования сохраняется файл: intent.md, spec.md, plan.md, дифф с тестами, PR с находками ревью, запись об инциденте. Следующая стадия начинает работу, читая этот файл. На ранних этапах это markdown-файлы, потому что их могут одинаково читать и человек, и агент. Начиная со стадии сборки, артефактом становится сам код и записи о нём. Цепочка коммитов при этом одновременно служит журналом аудита: кто что попросил, что сделал агент и кто это одобрил.
Заметка
Человек остаётся ответственным за каждое решение, требующее суждения. Меняется не то, что решает человек, а то, на чём концентрируется его внимание — вместо старта каждой стадии с нуля он проверяет то, что агент уже пометил как важное.
Traditional vs AI-native: что меняется на каждой стадии
Anthropic сравнивает два полюса — традиционный SDLC и AI-native SDLC — признавая, что большинство компаний находятся где-то между ними.
| Стадия | Традиционный SDLC | AI-native SDLC |
|---|---|---|
| План | Требования собирают комитетом, через воркшопы и подписи, пишут вручную | Claude синтезирует боли прямо из источников и фиксирует их в intent.md — читаемом человеком и исполняемом машиной |
| Дизайн | Спецификацию пишут аналитики, дизайнеры её разбирают | Требования и дизайн сжимаются в одну рабочую сессию с агентом, по стандартам, закодированным в skills и версионированным в git |
| Сборка | Тесты и код пишутся вручную, документация — постфактум | Тесты и код генерирует ИИ, знания хранятся в версионированных CLAUDE.md и skills |
| Тест | QA-ворота на границах стадий | Непрерывные evals прямо внутри реализации |
| Деплой | Человек проверяет каждую строку, управление непоследовательно | Слои агентского ревью, человек — только для регулируемого и критичного кода, контроль через hooks |
| Поддержка | Люди следят за багами в проде | Агенты мониторят продакшен и при нарушении контрольных границ пишут новый intent.md |
Стадия 1 — План: intent.md вместо совещаний
В традиционном процессе идея проходит через backlog, юзер-стори, оценку в story points и серию совещаний, прежде чем кто-то сможет начать над ней работать — и то, что доходит до инженеров, уже несколько раз пересказано и потеряло смысл оригинала. В AI-native подходе автор идеи брейнштормит с Claude напрямую и получает на выходе intent.md — прото-спецификацию своими словами, где зафиксировано, что нужно, почему и в каких рамках. Claude задаёт те же вопросы, что задал бы аналитик: про масштаб, пользователей, ограничения и критерии успеха.
Дальше файл коммитится в общий репозиторий — например, папку intent/ внутри репозитория продукта — и продакт-оуэн подхватывает идею оттуда. Важно, что человеку не обязательно уметь работать с git: коннектор к GitHub позволяет Claude коммитить markdown от имени человека прямо из claude.ai или Cowork. Измеряют это так: время от первого разговора до закоммиченного intent.md (ожидание — упасть с многонедельного цикла до нескольких часов) и «выживаемость» — доля intent.md, принятых продакт-оуэном в стадию дизайна, а не закрытых как нерелевантные.
Стадия 2 — Дизайн: спецификация за одну сессию
На этой стадии требования и дизайн, которые раньше писали разные люди в разных документах, сжимаются в одну рабочую сессию с агентом. Стандарты компании — архитектурные принципы, требования к безопасности, паттерны кода — закодированы как skills и версионированы в git, поэтому Claude применяет их автоматически, а не по памяти отдельного архитектора. Результат стадии — spec.md, который читает следующая стадия.
Это тот момент, где особенно заметен эффект от инструментов вроде Tool use — агент не просто пишет текст, а обращается к реальным системам компании, проверяет существующие API и ограничения инфраструктуры прежде, чем зафиксировать дизайн на бумаге.
Стадия 3 — Сборка: код и тесты пишет агент
Здесь традиционный SDLC предполагал, что код и тесты пишут вручную, а документация появляется постфактум — если появляется вообще. В AI-native версии тесты и код генерирует ИИ, а институциональные знания живут не в головах инженеров, а в версионированных CLAUDE.md-файлах и skills, которые может прочитать любой следующий агент или человек. Подробнее о том, как выстраивать надёжное тестирование вместе с ИИ, можно почитать в материале «Тесты с Claude».
Именно на этой стадии становится особенно наглядно то, что описано во вступлении: скорость сборки перестаёт быть проблемой, а вот качество передачи знаний между агентами и людьми — становится ключевым фактором. Если CLAUDE.md не поддерживается в актуальном виде, следующий агент будет работать по устаревшим правилам, и весь выигрыш в скорости обесценится на следующем этапе.
Стадия 4 — Тест: непрерывные проверки вместо ворот
Традиционный QA стоит на границах стадий как отдельные ворота, через которые нужно пройти перед релизом. AI-native подход вплетает eval'ы прямо в процесс реализации — проверки идут постоянно, а не одним большим блоком перед выпуском. Это меняет саму природу тестирования: вместо того чтобы «протестировать перед релизом», команда постоянно наблюдает, не отклонилось ли поведение системы от ожидаемого.
Такой подход требует, чтобы критерии успеха были зафиксированы заранее и машинно-читаемо — иначе непрерывные проверки превращаются в шум. Здесь помогает тот же принцип, что и в планировании: чёткий, версионированный артефакт с критериями, который агент может сверять сам, без участия человека на каждом шаге.
Стадия 5 — Деплой: слои агентского ревью
Раньше человек проверял каждую строчку кода, и управление происходило в циклах ревью — часто непоследовательно, в зависимости от того, кто именно занимался проверкой в этот раз. AI-native подход выстраивает слои агентского ревью, а человеческое внимание резервируется для регулируемого и по-настоящему критичного кода. Управление здесь не откладывается на потом, а встроено в момент действия ИИ — через hooks, которые работают как ворота одобрения прямо в процессе.
Это прямое решение проблемы, обозначенной в начале плейбука: служба безопасности не может расти пропорционально объёму кода, который выдают агенты. Вместо этого сама проверка становится многослойной и автоматизированной, а человек включается точечно — там, где риск действительно требует его суждения.
Стадия 6 — Поддержка: агенты дежурят в проде
В традиционном цикле люди наблюдают за продакшеном и реагируют на баги, когда их находят — часто постфактум, по жалобам пользователей. В AI-native SDLC агенты мониторят живые деплои напрямую, и когда какая-то контрольная граница нарушена, происходит не просто алерт человеку, а диагностика и автоматическая запись нового intent.md, который снова запускает цикл с самого начала. Похожий подход к дежурству описан в материале про Claude Tag как дежурного по CI/CD — там agentic мониторинг тоже закрывает разрыв между инцидентом и его формализацией в задачу.
Так цикл замыкается: последняя стадия становится первой стадией следующей итерации. Именно эта петля, а не просто ускорение написания кода, и есть суть AI-native SDLC — процесс перестаёт быть линией с началом и концом и становится непрерывным контуром, в котором каждый принятый артефакт запускает следующий шаг автоматически.
С чего начать
Плейбук специально построен так, что плеи модульны: не нужно перестраивать все шесть стадий одновременно. Anthropic советует начинать с любого «листового» плея — того, у которого нет входящих зависимостей, — и двигаться дальше по графу зависимостей, ориентируясь на свои узкие места.
Как измерять, что это работает
Для каждого плея в плейбуке заявлена пара метрик: опережающий индикатор (leading) и запаздывающий (lagging). Например, для стадии планирования опережающий индикатор — время от первого разговора до закоммиченного intent.md, а запаздывающий — доля intent.md, которые продакт-оуэн принимает в следующую стадию, а не закрывает. Такой парный подход не даёт спутать «стало быстрее» с «стало лучше»: скорость без принятия результата — это просто больше шума на входе в систему.
Это перекликается с тем, как в целом Anthropic подходит к внедрению ИИ в команды — не как к разовой замене инструмента, а как к изменению рабочих привычек с постоянным замером эффекта. Похожий принцип разбирается в материале «Как Anthropic учит людей работать с ИИ»: важно не просто дать доступ к Claude, а перестроить процесс так, чтобы агент и человек дополняли друг друга на каждой границе передачи работы.
Частые вопросы
Что такое AI-native SDLC и чем он отличается от обычного цикла разработки?
Это не новая методология, а пересборка привычного цикла из шести стадий (план, дизайн, сборка, тест, деплой, поддержка) в непрерывный контур, где каждая стадия заканчивается версионированным артефактом (intent.md, spec.md, диффом с тестами и так далее), а следующая стадия автоматически запускается по этому артефакту. Человек остаётся ответственным за решения, но включается точечно — на границах, а не на каждом шаге вручную.
Зачем нужен файл intent.md, если можно просто завести тикет в Jira?
Тикет обычно требует нескольких раундов пересказа идеи разными людьми, и то, что доходит до инженеров, отличается от исходного замысла. intent.md пишется вместе с Claude напрямую от автора идеи, содержит контекст, ограничения и открытые вопросы в машиночитаемом виде, и коммитится в git — поэтому следующая стадия может сразу читать и действовать по нему, без пересказа.
Почему служба безопасности становится узким местом при ускорении разработки?
Команды безопасности и ревью традиционно рассчитаны на объём кода, который пишут люди. Когда агенты в разы увеличивают объём диффов, у команды просто не хватает часов на построчную проверку — либо очередь ревью растёт, либо код уходит в прод недопроверенным. Плейбук решает это через слои агентского ревью с governance-хуками, оставляя человеческую проверку только для регулируемого и критичного кода.
Нужно ли перестраивать все шесть стадий сразу?
Нет, плеи в плейбуке модульны и организованы как граф зависимостей. Можно начать с любого плея, у которого нет входящих зависимостей (например, со стадии планирования), и двигаться дальше исходя из того, где у команды сейчас самое болезненное узкое место.
Главный вывод плейбука прост: ускорять написание кода дальше почти бессмысленно, если процессы вокруг него остаются рассчитанными на человеческую скорость. AI-native SDLC не отменяет контроль и подотчётность — он переносит их в артефакты, которые может читать и агент, и человек, и делает передачу между стадиями автоматической. Начать можно с одной стадии, посмотреть на leading и lagging метрики, и двигаться дальше по графу зависимостей, не пытаясь переделать всё сразу.
Если хочешь попробовать всё это руками — начни с бесплатного курса «Claude Code и терминал: с 0».
Источник
По мотивам статьи Anthropic «The AI-Native SDLC playbook». Пересказали по-русски для новичков.