Ось незручна закономірність, яка стоїть за багатьма впровадженнями agentic coding: етап build помітно прискорюється, а час від ідеї до продакшену майже не змінюється.
З агентами все гаразд. Проблема в усьому, що їх оточує. Гейти погодження, refinement-мітинги, черга на review, щотижневий change board — усе це проєктували для світу, де написання коду було найдорожчою стадією delivery. Того світу вже немає. Процес, збудований під нього, лишився, і тепер саме він — вузьке місце.
У серпні 2026 Anthropic опублікувала The AI-Native SDLC Playbook — довгий практичний документ про те, як перебудувати життєвий цикл розробки під цю реальність. Його варто прочитати повністю. Цей пост — мій інженерський погляд на нього: у чому ключова ідея, які частини, на мою думку, найважливіші, де я був би обережним і як це пов’язано з дисциплінами, які ми розбирали в цій серії, — spec-driven development, context engineering та evals.
Чому старий SDLC ламається з агентами
Класичний життєвий цикл має шість стадій — plan, design, build, test, deploy, maintain — і в кожної є власник. Продукт пише вимоги. Архітектура пише дизайн. Інженери будують. QA верифікує. Release випускає. Ops стежить. Робота переходить між стадіями у вигляді документів, тікетів і sign-off’ів.
Така форма мала сенс. Коли реалізація займала тижні чи місяці, ви хотіли важкого узгодження наперед: PRD, оцінки, security review. Кожен контроль у системі мовчки припускає, що кожен крок виконує людина і що людина може прорецензувати кожен рядок.
Зробіть етап build майже безкоштовним — і трапляються три речі:
- Вузьке місце зсувається. Planning, review і deployment досі працюють зі швидкістю людини. Вони стають найповільнішою частиною системи.
- Рядок-за-рядком review перестає масштабуватися. Коли більшість diff’у пишуть агенти, «людина читає кожен рядок» перетворюється або на нескінченну чергу, або на формальний штамп.
- Governance дорожчає. Винятки, що чекають на щомісячний комітет, тепер блокують роботу, закінчену за один вечір.
Найгостріший приклад — безпека. Команда безпеки, розрахована на людський обсяг, стоїть перед вибором: нехай черга росте або нехай у продакшен потрапляє недостатньо перевірений код. Регульована компанія не може прийняти жодного з варіантів. Її перевірки мають масштабуватися разом з виходом агентів — а отже, не можуть бути суто людськими.
Що насправді означає «AI-native»
Визначення з playbook — найкорисніша для мене частина, бо це не «додайте AI до кожного кроку». Це: збережіть цілі контролю, змініть спосіб їх забезпечення. Ви, як і раніше, хочете traceability, розподілу обов’язків, верифікованих змін і авторизованих релізів. Просто ви перестаєте забезпечувати їх мітингами й читанням руками та починаєте забезпечувати артефактами, hooks і автоматичними перевірками.
З цього випливають три структурні зміни:
- Лінія стає циклом. Сигнали з продакшену автоматично повертаються в planning, а не чекають на post-mortem, за яким, можливо, ніхто нічого не зробить.
- Передачі стають комітами. Кожна стадія завершується комітом артефакту у version control, а наступна стадія його читає.
- Люди переходять від виробництва до судження. Люди лишаються відповідальними за кожне рішення; просто свою увагу вони витрачають на рев’ю артефактів, а не на їх авторство.
Нитка артефактів
Це хребет усієї моделі, і ця ідея — та, яку я б забрав, навіть якщо ігнорувати все інше:
| Стадія | Закомічений артефакт | Хто його оцінює |
|---|---|---|
| Plan | intent.md — проблема словами того, хто її сформулював | Product owner приймає або відхиляє |
| Design | spec.md — вимоги + дизайн, з урахуванням політик | Product owner, а для позначених питань — власники політик |
| Build | plan.md, потім diff і тести | Інженер (tech lead для ризикової роботи) |
| Test | Вивід тестів, результати eval у PR | Автоматичні гейти + code owners |
| Deploy | PR з findings від review, авторизація релізу | Code owner, release manager |
| Maintain | Запис про інцидент → новий intent.md | On-call / власник сервісу виконує triage |
Ранні артефакти навмисно пишуться в Markdown: і product owner, і агент можуть їх читати. Починаючи з build, артефакти — це код і його записи.
Дві речі роблять це потужним. По-перше, ланцюжок і є audit trail: хто що просив, що видав агент, хто це погодив — усе в історії git, без окремої compliance-таблиці. По-друге, кожен прийнятий артефакт може стати тригером наступної стадії. Змерджений intent.md запускає прохід по spec. Затверджений spec.md відкриває сесію в plan mode. Змерджений PR запускає пайплайн. Порушена продакшен-метрика пише наступний intent.md. Це і є «цикл».
Якщо ви читали пост про spec-driven development, це буде знайомо: це та сама ідея «spec як істина, код як кеш», тільки поширена на весь життєвий цикл, а не лише на етап build.
Стадія за стадією: що змінюється
Я не буду переказувати playbook — читайте його самі, — але ось форма кожної стадії та одна ідея на стадію, яка, на мою думку, важить найбільше.
Plan: зафіксуйте intent один раз
Замість того, щоб ідея проходила через запис у беклозі, user story, оцінку в поінтах і два refinement-мітинги — втрачаючи зміст на кожному кроці, — людина, яка мала ідею, обговорює її з агентом і комітить intent.md: проблема, бажаний результат, кого це стосується, обмеження, відкриті питання.
Ідея, що має значення: не-інженери комітять у git (через конектор), тож оригінальне формулювання зберігається. Метрика, за якою варто стежити, — час від першої розмови до закоміченого intent; ціль playbook — щоб тижні стиснулися до годин.
Design: застосовуйте політику під час написання, а не на review
Вимоги та дизайн народжуються в одній сесії. Агент читає прийнятий intent і створює spec.md, обмежений організаційними skills для безпеки, compliance, бренду та UX — і його прямо просять позначати, де політики конфліктують, а не мовчки обирати одну. Позначені питання йдуть до іменованих власників політик до того, як інженери побачать spec.
Ідея, що має значення: застосування політик зсувається ліворуч — з review PR у написання spec. Лагова метрика цікава: порахуйте правки spec.md, зроблені після першого plan.md. Це rework, виміряний у цифрах.
Build: жодної реалізації без прийнятого плану
Сесії починаються в plan mode: агент читає кодову базу без редагування і пропонує план — які файли змінюються, порядок роботи, ризики, як це буде доведено. Ви допитуєте його («що зламається? який крок найризикованіший? що ти відкинув?») доти, доки хтось, хто не бачив розмови, зміг би реалізувати за цим планом. Потім його комітять як plan.md, і PR review згодом звіряє diff з ним.
Навколо цього стоять елементи, що роблять вихід агента надійним:
CLAUDE.mdяк спільний контекст — менше за сторінку, лише те, що потрібно в перший день. Робоче правило: якщо агент двічі робить ту саму помилку — додайте виправлення.- Skills для знань, які мають застосовуватися послідовно в різних репозиторіях (security review, стандарти API). Версіонуються, власник — власник відповідної політики.
- Hooks як детерміновані запобіжники — блокують редагування захищених шляхів, запускають форматер після правок, не пускають секрети в diff’и.
- Паралельні сесії у worktrees і subagents — verifier, який запускає застосунок і звітує проти
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, проходить review до merge. Кожен продакшен-інцидент стає постійним eval.
Ідея, що має значення: налаштування вашого агента — це код, і воно регресує як код. Це саме той аргумент із посту про evals, застосований до harness’а, а не до продукту.
Deploy: агент іде до гейта, але ніколи крізь нього
PR review працює в обидва боки. 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 збірок, що впали, класифікація flaky-тестів, чернетки changelog), потім додаються write-джоби, які завжди лише створюють PR. Deploy і rollback виставляються як інструменти в межах середовища, з рівнями автономності: вільно в dev, обмежено в staging, лише підготовка в продакшені.
Ідея, що має значення: агент може діяти аж до продакшен-гейта, але не крізь нього. Це одне речення — модель governance, яку можна пояснити аудитору за тридцять секунд.
Maintain: замкніть цикл
Попередні стадії потребували людини, щоб їх запустити. Тут тригер — детермінований скрипт, що стежить за продакшен-метрикою з ковзною базовою лінією — частота падінь CI, 5xx після деплою, cycle time PR — з рівневими реакціями: лог на 1σ, діагностика лише для читання на 2σ, пропозиція PR або запуск заздалегідь схваленого rollback на 3σ. Агент записує свою діагностику як intent.md, а людина виконує triage: виправити зараз, запланувати чи відхилити (відхилення підлаштовують межі). Після виходу виправлення інцидент стає eval.
Ідея, що має значення: виявлення детерміноване; судження делеговане. Жодна модель не вирішує, чи є аномалія. Модель лише пояснює її та пропонує реакцію — через ті самі гейти, що й усі.
Три принципи в основі
Приберіть назви продуктів — і playbook тримається на трьох правилах. Я б повісив їх на стіну:
- Артефакти в git — це audit trail. Якщо це не закомічено, цього не було.
- Skills радять, hooks примушують. Ніколи не покладайтеся на добру поведінку моделі там, де політика мусить виконуватися.
- Детерміноване виявлення, делеговане судження, людська авторизація. Скрипти вирішують коли, агенти пропонують що, люди затверджують чи.
Де я був би обережним
Продавати це без застережень означало б зробити вам ведмежу послугу.
- Це документ вендора. Playbook написала Anthropic, і він збудований навколо Claude Code, плюс кілька продуктів, позначених як beta на момент написання. Патерни — закомічені артефакти, детерміновані гейти, evals на конфігурацію, рівнева автономність — не залежать від інструмента і працюють з іншими агентами. Специфіка продуктів зміниться; проєктуйте навколо патернів.
- Ємність review — і далі стеля. Паралельні сесії допомагають лише доти, доки людське review встигає. Playbook радить почати з двох-трьох сесій і додавати більше, лише якщо якість review тримається. Команди, що пропускають це речення, виробляють багато правдоподібного коду, який насправді ніхто не перевірив.
- Lockdown через managed settings — це компроміс, а не шаблон. Кожне deny-правило коштує можливостей. Підбирайте обмеження під класифікацію даних кожного репозиторію, а не копіюйте найсуворіший приклад усюди.
- Legacy-системи не зникають. Jira, Figma і change board існують, бо від них залежать аудитори й інші команди. Відповідь playbook прагматична: для кожного артефакту оголосіть одну system of record — репозиторій, legacy-інструмент або принаймні двосторонній зв’язок (артефакт посилається на ID тікета, тікет — на commit SHA). Співіснування — це нормально; неоднозначність — ні.
- Цикл — це кінцевий стан. Ви не починаєте з headless-агентів, що реагують на 3σ-алерти. Ви починаєте з того, що промптите кожен крок вручну, потім кодифікуєте в slash-команди, потім у тригери. Кілька play’їв не мають передумов —
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 із
REVIEW.md, branch protection без змін. Approval hooks на деплої в продакшен. - Місяць 3+:
intent.md→spec.mdдля product owners. Безперервні evals на конфігурацію агента. Тоді, і лише тоді, один замкнений цикл на одній метриці.
Міряйте по ходу — playbook до кожного play’я додає один випереджальний і один лаговий індикатор, і ця дисципліна варта копіювання, навіть якщо ви змінюєте все інше.
Кар’єрний кут
Опис роботи зсувається під усіма нами. Інженер у цій моделі менше друкує і більше пише плани, гідні затвердження, рев’юїть артефакти, проєктує гейти та оркеструє паралельну роботу. Tech lead’и стають власниками REVIEW.md, CLAUDE.md і eval-набору. Platform-інженери стають людьми, що кодують governance як hooks і managed settings. Engineering-менеджери отримують життєвий цикл, де кожен крок залишає докази — а це, якщо ви колись готувалися до аудиту, не дрібниця.
Навички, що складаються, — це ті, до яких playbook постійно повертається: specs, контекст, верифікація та governance-as-code. Жодна з них не про конкретну модель, і жодна не застаріє, коли вийде наступна.
Глибше
Ми зробили курс саме про це: AI-Native SDLC: Engineering Delivery from Intent to Production. Шість модулів, по одному на кожну стадію життєвого циклу, і кожен завершується закоміченим артефактом на вашій власній кодовій базі — шаблони intent і spec, налаштований CLAUDE.md, skills і hooks, eval-набір для вашої конфігурації агента, AI review gate та один замкнений моніторинговий цикл.
Якщо хочете спершу фундамент: Claude Code Mastery — для щоденного agentic-циклу, Spec-Driven Development Foundations — для методології, і OpenSpec Mastery — для продакшен-workflow зі spec. Для команд, що розгортають це по всій організації, ми також проводимо це як корпоративне навчання.
Джерело: Anthropic, The AI-Native SDLC Playbook (серпень 2026). Цей пост — незалежний виклад і коментар; читайте оригінал, щоб побачити повні play’ї, приклади та референси конфігурацій. Також у цій серії: spec-driven development, context engineering, evals, OpenSpec, впровадження AI coding tools.
