Статья · Claude · 21 августа 2026

The AI-Native SDLC playbook

Как перестроить разработку вокруг быстрых агентов, проверяемых артефактов и человеческих точек решения.

Автор Louis Claxton Дата 21.08.2026 Чтение 40 мин Источник Claude
Главный тезис

Когда агенты сжимают Build до часов, узкое место переезжает в Plan, Test, Review и Deploy. Выигрыш появляется после перестройки всего цикла, а не только генерации кода.

Традиционный линейный SDLC рядом с циклическим AI-native SDLC вокруг Claude
Линия превращается в цикл · открыть в статье ↗
TL;DR

Суть за минуту

в статье ↗

01Оптимизируйте поток

Скорость генерации кода не равна скорости поставки. Очереди растут на согласованиях, проверках и релизных воротах.

02Коммитьте решения

intent.md, spec.md, plan.md, diff, тесты и review findings образуют цепочку передачи и аудита.

03Автоматизируйте контроль

Skills подсказывают, hooks блокируют, evals ловят регрессии. Человек принимает решения о риске и допуске в production.

01

Build ускорился. Весь цикл пока нет

в статье ↗

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

AОчередь ревью

Построчная проверка рассчитана на человеческий объём diff. Когда diff растёт, reviewer становится узким местом.

BКонтроли отстали

Ручные процедуры не успевают за агентом. Формальная строгость остаётся, а проверить весь поток уже нельзя.

CЦена исключения

Нестандартный случай всё ещё ждёт комитета, который собирается раз в неделю или месяц.

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

Передавайте не контекст, а артефакт

в статье ↗

Каждая стадия пишет результат в version control. Следующая стадия читает его и начинается после принятия. Так handoff запускается автоматически, а история коммитов сохраняет запрос, результат и решение человека.

intent.mdspec.mdplan.md diff+ testsPRfindings incident PlanDesignBuild TestDeployMaintain принятый артефакт запускает следующую стадию; инцидент возвращается как новый intent
цепочка артефактов одновременно передаёт работу и оставляет audit trail
СтадияТрадиционный SDLCAI-native SDLC
PlanКомитеты, workshops, ручная записьИсточники сводятся в intent.md
DesignSpec и дизайн живут в разных handoffОдна сессия под ограничениями skills
BuildКод, тесты и документация пишутся отдельноPlan mode, CLAUDE.md, skills и hooks
TestQA gate на границе стадииFeedback loop и continuous evals
DeployКаждую строку читает человекAI review, human risk approval
MaintainЧеловек замечает и запускает разборДетерминированный trigger создаёт новый intent
03

Внедряйте plays по зависимостям

в статье ↗

Номер стадии не задаёт порядок внедрения. Начинать можно с play без входящих стрелок. Остальные plays требуют указанных на графе controls или артефактов.

Граф зависимостей между plays для поэтапного внедрения AI-native SDLC граф из статьи
Как читать: стрелка входит в play, если перед ним нужен другой play. Capture intent, CLAUDE.md, feedback loop, hooks и plan mode можно начать независимо.
Практический порядок не совпадает со структурой статьи. Сначала уберите конкретное ограничение, затем добавьте зависимые controls.
04

Plan и Design: зафиксируйте намерение

Plan ↗ Design ↗

Идея, тикет или алерт сначала превращаются в intent.md. Product owner, или владелец продукта, уточняет смысл и принимает файл. Затем агент пишет spec.md с учётом правил бренда, безопасности, compliance и UX.

01 / PlanИсточникИдея, ticket или incident
02 / Planintent.mdПроблема, результат, границы
03 / GateProduct ownerИсправляет и принимает
04 / Designspec.mdТребования и дизайн вместе
05 / PolicySkillsПравила применяются при записи
06 / GateВладелец рискаРазрешает конфликт правил
markdown · intent.md в статье
# Intent: claims status self-service

## Problem
Customers call to ask where a claim is.

## Proposed outcome
Show status, next step, expected date.

## Constraints
No new PII. Existing authentication only.

Что измерять

Для Plan статья предлагает время от первого разговора до принятого intent.md и долю intent, дошедших до Design.

Для Design: интервал intent.md → spec.md и число изменений spec после первого plan.md.

Смысл метрик: ускорение не должно увеличивать объём поздних переделок.

05

Build: разделите знание и принуждение

в статье ↗

Plan mode фиксирует решение до правок. CLAUDE.md даёт рабочий контекст, skills применяют институциональное знание, а hooks гарантируют правила без исключений.

plan.md

Файлы, порядок, риски и проверки согласованы до первого edit.

CLAUDE.md

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

SKILL.md

Версионируемая политика с владельцем. Это advisory control: он снижает число нарушений, но не блокирует их.

hooks

Быстрые детерминированные проверки блокируют protected paths, утечки credentials и неформатированный diff.

worktrees

Независимые задачи работают в разных checkout. Для старта достаточно 2–3 параллельных сессий.

markdown · CLAUDE.md в статье
# Payments service

## Commands
- Build: make build
- Test: make test
- Lint: make lint

## Things Claude gets wrong
- Do not bump dependencies.
- The legacy v1/ package is frozen.
Граница контроля: skill уместен для правила, которое нужно применять последовательно. Если нарушение недопустимо, добавьте hook или обязательный review pass.
06

Test: замкните локальный feedback loop

в статье ↗

Сессия получает проверяемую цель и повторяет цикл до успеха. Для bug fix тест сначала должен упасть по ожидаемой причине, а затем оставаться недоступным для правок агента.

изменить кодзапустить checkпрочитать signalисправить build · test · lint или screenshot diff
проверка работает внутри задачи, а не через несколько дней

1Одна команда

Спрячьте знание об окружении за make test или npm test. Неуспех должен возвращать ненулевой exit code.

2Независимый сигнал

Защитите тест от изменений во время исправления. Для UI дайте агенту browser или screenshot tool и ожидаемый mock.

3Evals в CI

Начните с 20–50 реальных задач. Запускайте suite при изменении CLAUDE.md, skills, hooks или модели.

07

Deploy: агент доходит до ворот

в статье ↗

Каждый PR получает одинаковые review passes, то есть проходы проверки. Человек проверяет намерение и риск, а branch protection сохраняет separation of duties. В production агент не проходит без именованного разрешения.

RReview policy

REVIEW.md задаёт passes для bugs, security и соответствия spec.md с plan.md.

SSandbox

CI job получает короткоживущие scoped tokens, network policy и не хранит production credentials.

GHuman gate

Development допускает больше автономии. Production release требует подтверждения release manager, которое проверяет hook.

bash · production-gate.sh в статье
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
  if [ -z "$RELEASE_APPROVAL" ]; then
    echo "Production deploys need a release authorization." >&2
    exit 2
  fi
fi
Не копируйте managed settings вслепую. Статья прямо называет конфигурацию отправной точкой: каждое правило deny ограничивает возможности, а баланс зависит от класса данных репозитория.
08

Maintain: детектор будит агента

в статье ↗

Модель не решает, случилась ли аномалия. Версионируемый скрипт следит за контрольными полосами. После breach конфигурация определяет, может ли Claude только объяснить проблему или открыть разрешённый маршрут.

1σ · log2σ · read-only diagnose3σ · propose through gate записать событиесобрать evidence и intent.mdоткрыть PR или запустить approved runbook детекция остаётся детерминированной; модель включается после breach
autonomy растёт вместе с силой сигнала, но маршрут остаётся gated
Инцидентный канал с диагностикой, человеческим разрешением на rollback и записью post-mortem пример из статьи
Audit trail в канале: запрос, диагностика, разрешение человека и rollback остаются рядом. Post-mortem записывается в version control.
Диагноз становится новым intent.md. После исправления incident добавляют в eval suite, поэтому Maintain замыкает цикл в Plan и Test.

Структура статьи

оглавление ↗

Каждая ссылка открывает соответствующий раздел оригинала.

Почему Build больше не узкое место

читать ↗

Старые стадии остаются на человеческой скорости, поэтому bottleneck смещается наружу.

Build до и после ускорения агентамирис.
Линейный и циклический SDLCрис.

Plays и их зависимости

читать ↗

Граф отделяет стадии жизненного цикла от порядка внедрения controls.

Граф зависимостей playsграф

Stage 1–2 · Plan и Design

читать ↗

intent.md фиксирует замысел, spec.md превращает его в проверяемое решение.

Stage 3 · Build

читать ↗

Plan mode, CLAUDE.md, skills, hooks, worktrees и subagents.

Stage 4 · Test

читать ↗

Локальный feedback loop и регрессионные evals для конфигурации агента.

Stage 5 · Deploy

читать ↗

AI review, sandboxed CI/CD, scoped credentials и production gate.

Stage 6 · Maintain

читать ↗

Control bands запускают diagnosis; результат возвращается как новый intent.

Инцидентный канал как audit trailпример

Closing thoughts

читать ↗

Цикл работает постоянно, а человеческое решение остаётся над ним.

Три опорные фразы

в статье ↗
«Build is no longer the constraint»
Ограничение сместилось в статье ↗
«Every stage commits an artifact the next stage can read.»
Механика handoff в статье ↗
«Human judgement stays above it.»
Граница автономии в статье ↗
#

В цифрах

контекст ↗
6
стадий в цикле
2–3
сессии для старта
20–50
реальных задач в первой eval suite
уровень gated action
< 1
страницы занимает CLAUDE.md
Важно: статья описывает playbook и предлагаемые метрики, но не публикует сравнительный benchmark внедрения или control group.

Как применить

plays ↗

Начните с одного потока и одного наблюдаемого ограничения. Чек-лист можно отмечать прямо на странице.

Найдите bottleneck: измерьте время ожидания в Plan, Review/Test и Deploy, а не только длительность Build.
Назовите source of truth: для каждого artifact выберите repo или legacy system и свяжите записи через commit SHA.
Введите artifact chain: начните с intent.md, затем добавьте spec и принятый plan.
Сожмите CLAUDE.md: оставьте команды, архитектурные границы и ошибки, которые агент повторил дважды.
Формализуйте одно правило: advisory policy оформите как skill; обязательное правило подкрепите быстрым hook.
Дайте агенту проверяемый сигнал: сведите build, test и lint к одной команде; защитите тесты во время bug fix.
Посейте eval suite: возьмите 20–50 недавних задач и добавляйте каждый production incident как regression case.
Разведите автономию: в development агент может deploy без ручного gate; production требует named authorization и проверенного rollback.

Ссылки и понятия

resources ↗

// документы из статьи

Admin setupКарта решений для развёртывания Claude Code в организации.
SettingsManaged settings, precedence и доступные ключи.
Hooks guideДетерминированные guardrails и approval gates.
SandboxingИзоляция filesystem и network для agent jobs.
MonitoringOpenTelemetry для сессий, gate decisions и usage.

// ключевые различия

artifact over handoff deterministic trigger human risk owner skill = advisory hook = enforcement eval = regression line-by-line bottleneck standing prod credentials
iЭто конспект рекомендаций автора, а не независимая оценка продукта или измерение ROI.
× Изображение статьи в полном размере
Открыть в статье