Playbook SDLC AI-native w pomiarach: czasy etapów, podatek od bramek, tabela werdyktów

TL;DR

• Każdy z sześciu etapów playbooka kończy się zacommitowanym artefaktem (intent.md, spec.md, plan.md, PR, incident record). Post startowy i 14-lekcyjny kurs opisują ten kształt, ale żadne z nich nie publikuje pomiaru.
• Przepuszczony end to end przez prawdziwe repo Express + Prisma, pełny łańcuch naprawił jeden bug w 11 min 31 s za $3.46, a bezpośredni prompt zrobił to w 2 min 13 s za $0.70: ×5.2 czasu, ×4.9 kosztu, oba z zielonymi testami.
• Prawdziwy podatek to czytanie: 5,488 słów artefaktów przy poprawce jednej linii w klasie, czyli około 27 min przy 200 słowach na minutę. Łańcuch zamienia czas pisania na czas czytania.
• Trzy z sześciu etapów się opłaciły w tym kontekście: Plan (intent.md), Build (plan mode + CLAUDE.md + TDD), Deploy (REVIEW.md + hook). Design i ciągłe evale nie opłaciły się solo; Maintain nie był uruchamiany.
• Etap spec sam zgłosił swój warunek wstępny: nie istniały żadne skille organizacji, więc spec nigdy nie został sprawdzony pod kątem polityk brandu, bezpieczeństwa czy UX. Playbook zakłada, że te skille są już napisane.
• Deterministyczna bramka działa: hook PreToolUse zablokował deploy w 14 s z kodem exit 2. Model odmówił już wcześniej z własnej oceny, zanim hook w ogóle się odpalił.

Co mówią pomiary

Playbook przedstawia zmianę jako "kod przestał być wąskim gardłem" i wymaga, by każdy etap kończył się zacommitowanym artefaktem, od intent.md przez spec.md i plan.md po PR i incident record, z pasmami kontrolnymi w Maintain s1. Kurs zawiera konkrety nadające się do cytowania: od 20 do 50 prawdziwych zadań jako zestaw evali, limit 5 nitów w REVIEW.md, najwyżej 2 do 3 równoległych sesji oraz zasadę, że błąd popełniony dwa razy trafia do CLAUDE.md s2. Najostrzejsza neutralna lektura zestawia w tabeli, kto pisze, a kto akceptuje każdy artefakt, i nazywa dokument "vendor-claim throughout" z "no measurement anywhere" s4.

Zadanie naprawcze było prawdziwym bugiem z upstreamu: świeży klon uruchamiał npx nx test api i od razu padał 1 zestaw (auth.service.test.ts, "TypeError: Cannot read properties of undefined (reading 'prototype')"), 4 przechodziły, 14 testów zielonych, 2.2 s. Ścieżka bezpośrednia doszła do w pełni zielonych testów w 2 min 13 s, $0.70, 40 tur. Ścieżka łańcuchowa, intent, potem spec, potem plan, potem build, też doszła do zielonego w 11 min 31 s, $3.46, 169 tur. To ×5.2 czasu i ×4.9 kosztu, liczone wyłącznie po stronie maszyny s2.

Po stronie człowieka łańcuch boli najbardziej. Wytworzył 5,488 słów artefaktów do przeczytania (intent 558 + spec 2,167 + plan 2,763), około 27 min przy 200 słowach na minutę, dla poprawki, której bezpośredni koszt review to mały diff s4. Zadanie funkcjonalne (wyciszanie autorów) przez pełny łańcuch zajęło 15 min 13 s, $4.11, 158 tur i dostarczyło model Prisma Mute z migracją, endpointy mute i unmute, filtrowanie feedu, 1,422 dodanych linii w 15 plikach, 50 zielonych testów z 3 nowymi lub rozszerzonymi plikami testowymi i specyfikacją e2e. Jego artefakty ważyły 6,852 słów (intent 450 + spec 2,337 + plan 4,065), czyli około 34 min czytania s2.

Sceptyczna ocena etapu Design się obroniła. Krytyka na LinkedIn mówi, że playbook ukrywa swoje warunki wstępne: skille organizacji dla brandu, bezpieczeństwa i UX muszą już istnieć, a ktoś musi umieć poprowadzić brainstorm s7. Agent potwierdził to bez pytania. Zgłoszona w spec.md uwaga C0 brzmi dosłownie: "No org skills available. … This spec has therefore not been checked against brand, security or UX policy." Spec na ponad 2,000 słów, który powtarza zawartość codebase'u i nie może sprawdzić polityk, to etap do pominięcia, gdy pracujesz sam s7.

Krytyka infrastruktury też się obroniła. Argument jest taki, że gdy testy trafiają w nieaktualne fejki, "the agent sees the tests pass and reports the work finished", bo łańcuch artefaktów zapisuje to, co postanowiono, a nie to, co faktycznie działa s8. W naszym przebiegu pętla weryfikowała tylko testy jednostkowe i build; sam review wymienił nx e2e jako "Not run: needs a running server and a seeded DB" oraz prisma migrate status jako "Not run: needs a DB". Zielona pętla nigdy nie dotknęła żywego systemu s8.

Etap Deploy okazał się tanią wygraną. REVIEW.md zajął 117 s i kosztował $0.80: nx test (5/5 zestawów, 50 zaliczonych), nx build (ok), różnica lintu względem punktu odniesienia z planu (34 wobec 33, to +1 wprost dopuszczone przez pozycję A3 planu) i kontrola prettiera (9 plików z błędami, zapisane jako nit N1). Werdykt: 0 Important, 6 nitów, 5 wypisanych i 1 podsumowany, bo zadziałał limit. Review odmówił zatwierdzenia własnej pracy słowami "this agent does not approve", czyli rozdziałem obowiązków tak, jak opisuje go kurs s2. Bramka z hookiem zachowała się tak, jak opisuje dokumentacja: poproszony o deploy przed mergem agent odmówił z własnej oceny i nie uruchomił skryptu, więc hook się nie odpalił. Po mergu próba deployu została zablokowana przez hook PreToolUse (exit 2) w 14 s komunikatem bramki s19.

Evale były tanie do napisania i łatwo je zepsuć. Pięć przypadków powstało z historii gita w 283 s za $1.44. Oba przebiegi uruchomiły się na złej bazie, bo runner utworzył gałąź po zmergowaniu poprawki, i oba agenty to wykryły ("the bug was already fixed here") zamiast udawać zaliczenie. Jeden przebieg evali kosztuje około 60 do 70 s, więc zalecany w playbooku rozmiar od 20 do 50 przypadków oznacza mniej więcej od 20 do 55 min czasu agenta na każdy przebieg CI s2. Konfiguracja CLAUDE.md zajęła 63 s i $0.44 za jedną zacommitowaną stronę, czyli najtańszy ruch ze wszystkich; triaż logu CI tylko do odczytu wskazał właściwą przyczynę w 11 s za $0.13 s2.

Wątek społeczności dorzuca szerszą telemetrię: wśród 10,000 deweloperów zespoły intensywnie używające AI mergują o 98% więcej PR-ów, a czas review rośnie o 91%, rozmiar PR o 154% s6.

Pomiary

Protokół: łańcuch działał headless (claude -p, model claude-opus-5-5, uprawnienia ograniczone do acceptEdits plus allowlista, --setting-sources project,local) na roboczym klonie gothinkster/node-express-realworld-example-app (Express + TypeScript + Prisma + Postgres 16 w Dockerze, workspace Nx). Każdy etap był mierzony i zapisywany w exp/metrics.jsonl (17 wierszy). Razem: $11.90 + $0.14 za powtórkę hooka, 539 + 3 tury, około 41 min czasu agenta.

Zastrzeżenia: jedno repo, jeden deweloper, jeden dzień. Ruchy na skalę zespołu nie były uruchamiane, tryb headless ściska kroki wywiadu do pojedynczych promptów, a evale liczą tylko koszt pojedynczego przebiegu.

Do zrobienia w poniedziałek

• Napisz jedną stronę CLAUDE.md dla swojego głównego repo: komendy build, test i lint, dwa błędy, które agent zrobił w zeszłym tygodniu. Zacommituj ją. Budżet: 63 s czasu agenta.
• Przed następnym nietrywialnym zadaniem poproś najpierw o intent.md: cel, nie-cele, otwarte decyzje. Odpowiedz na otwarte pytania, dopiero potem pozwól agentowi planować. Pomiń spec.md, chyba że masz skille z politykami organizacji, na których można go sprawdzić.
• Uruchom etap build w plan mode z pętlą TDD i wymagaj, by plan zapisywał odchylenia (D1, D2, ...), żeby review miało się na czym oprzeć.
• Dodaj przebieg REVIEW.md prowadzony przez świeżą sesję, z limitem nitów i jawną linią "this agent does not approve". Niech uruchomi testy, build, różnicę lintu i kontrolę formattera.
• Wdróż jedną deterministyczną bramkę: hook PreToolUse, który kończy się kodem 2 przy deploy, gdy gałąź nie jest main.
• Zanim zaufasz zielonej pętli, wypisz na dole review, czego nie uruchomiła (e2e, migracje, wszystko, co wymaga żywej bazy).
• Zmierz własny podatek od bramek: zmierz czas ścieżki bezpośredniej i łańcuchowej na tym samym małym bugu, potem policz słowa, które musiałeś przeczytać.

Dla chcących więcej

• Wariant z dwiema bramkami: adwersarialna bramka review (sdlc-gate) i tylko dwa ludzkie punkty decyzyjne zamiast jednego na etap, pragmatyczny kształt dla małego zespołu s12.
• Kompletny, instalowalny łańcuch: szablony intent, spec, plan i REVIEW, walidator bramek, runner evali i wykrywanie pasm kontrolnych, jeśli wolisz nie budować rusztowania ręcznie s5.
• Planowanie zaczynające się od wywiadu: jedno pytanie naraz bije pytania paczką, a "AI agents don't ask clarifying questions. They assume." Opis konfiguracji bez pomiarów czasu s11.
• Dlaczego jeden stały pipeline bywa obchodzony: "a docs fix and a payments migration shouldn't travel the same path", a prawdziwy proces staje się niewidoczny. Zalicza playbook do jednej grupy z Kiro i GitHub Spec Kit s9.
• Luki, które sprzeda ci dostawca platformy: przyjmowanie sygnału do intentu, routing według blast radius, dashboard metryk. s13.
• Firma doradcza, która od stycznia stosuje ten sam kształt (CRAFT) w zespołach klientów i przyznaje: "we don't yet have a formal answer for what a control band looks like" s10.
• Jeden przykład intent.md (checkbox Select All), który pokazuje zadanie tego pliku: wydobyć otwarte decyzje zamiast pozwolić agentowi wybierać po cichu s14.

Źródła

• The AI-Native SDLC Playbook (launch post), claude.com. Dlaczego warto: sześcioetapowy kształt i zasada zacommitowanego artefaktu w pięć minut.
• The AI-native SDLC playbook (course, 14 lessons), Claude Academy. Dlaczego warto: jedyne miejsce, gdzie są liczby (od 20 do 50 zadań evali, limit 5 nitów, od 2 do 3 sesji), za darmo i bez logowania.
• The Committed-Artifact Chain, howardism.dev. Dlaczego warto: kto pisze, a kto akceptuje każdy artefakt, i dosadne stwierdzenie, że nic w playbooku nie jest zmierzone.
• bashebr/ai-native-sdlc, GitHub. Dlaczego warto: szablony, walidator bramek i runner evali do zainstalowania zamiast pisania od zera.
• Anthropic published an AI-native SDLC playbook, r/ClaudeAI. Dlaczego warto: wątek, który wnosi do debaty telemetrię Faros (98% więcej PR-ów, +91% czasu review).
• The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. Dlaczego warto: argument o ukrytych warunkach wstępnych, który etap spec potwierdził sam.
• The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. Dlaczego warto: problem nieaktualnych fejków, głos dostawcy, ale argument broni się sam.
• The AI-native SDLC won't be one process, worldprogramming.org. Dlaczego warto: argument o ceremonii przeciwko jednej ścieżce dla każdej zmiany.
• Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. Dlaczego warto: niezależny zespół, który dochodzi do tego samego kształtu i przyznaje się do dziury w Maintain.
• AI-Native SDLC: First Try, kyle.pericak.com. Dlaczego warto: jedyny praktyczny pierwszy przebieg zaczynający się od wywiadu, napisany zanim playbook powstał.
• TsCarpe/claude-sdlc-skills, GitHub. Dlaczego warto: wariant z dwiema bramkami i adwersarialnym krokiem review.
• Implementing the Anthropic AI-Native SDLC Playbook, Port blog. Dlaczego warto: lista tego, co playbook pomija, do czytania jako mapa luk.
• What Is intent.md in Claude Code?, dev.to. Dlaczego warto: jeden konkretny intent.md, którego strukturę możesz skopiować.
• Hooks guide, Claude Code docs. Dlaczego warto: jak hook PreToolUse z exit 2 staje się deterministyczną bramką, na której opiera się playbook.

FAQ

Czy pełny łańcuch kiedykolwiek się opłaca przy poprawce jednej linii?

Nie w tym przebiegu: ×5.2 czasu i ×4.9 kosztu za ten sam zielony wynik, plus 5,488 słów do przeczytania. Przy małych zadaniach używaj samego intent.md.

Dlaczego pomijać spec.md, gdy pracujesz solo?

Spec sam się zgłosił: bez skilli organizacji dla brandu, bezpieczeństwa czy UX nie mógł sprawdzić polityk, a ponad 2,000 słów poszło na powtarzanie zawartości codebase'u.

Czy hook zastępuje ocenę modelu?

Nie, wspiera ją. Agent sam odmówił deployu przed mergem; hook zablokował próbę po mergu w 14 s z kodem exit 2.