Il playbook SDLC AI-native, misurato: tempi per fase, tassa dei gate, tabella dei verdetti

TL;DR

• Le sei fasi del playbook finiscono ciascuna con un artefatto committato (intent.md, spec.md, plan.md, PR, incident record). Il post di lancio e il corso da 14 lezioni descrivono la forma; nessuno dei due pubblica una misurazione.
• Eseguita end to end su un vero repo Express + Prisma, la catena completa ha corretto un bug in 11 min 31 s per $3.46, mentre un prompt diretto lo ha fatto in 2 min 13 s per $0.70: ×5.2 di tempo, ×4.9 di costo, entrambi con test verdi.
• La vera tassa è la lettura: 5,488 parole di artefatti per un fix di una riga in una classe, circa 27 min a 200 parole al minuto. La catena trasforma tempo di scrittura in tempo di lettura.
• Tre fasi su sei hanno ripagato in questo contesto: Plan (intent.md), Build (plan mode + CLAUDE.md + TDD), Deploy (REVIEW.md + un hook). Design e gli eval continui no per un dev solo; Maintain non è stata eseguita.
• La fase di spec ha segnalato da sola il proprio prerequisito: non esistevano skill di organizzazione, quindi non è mai stata verificata rispetto a policy di brand, sicurezza o UX. Il playbook dà per scontato che quelle skill siano già scritte.
• Il gate deterministico funziona: un hook PreToolUse ha bloccato un deploy in 14 s con exit 2. Il modello si era già rifiutato una volta di sua iniziativa prima che l'hook scattasse.

Cosa dicono le misurazioni

Il playbook inquadra il cambiamento come "il codice non è più il collo di bottiglia" e chiede a ogni fase di chiudersi con un artefatto committato, da intent.md a spec.md e plan.md fino alla PR e all'incident record, con bande di controllo in Maintain s1. Il corso porta i dettagli citabili: da 20 a 50 task reali come suite di eval, un tetto di 5 nit in REVIEW.md, al massimo 2 o 3 sessioni parallele, e la regola che un errore fatto due volte finisce in CLAUDE.md s2. La lettura neutrale più incisiva tabula chi redige e chi accetta ogni artefatto e definisce il documento "vendor-claim throughout" con "no measurement anywhere" s4.

Il task di fix era un vero bug upstream: un clone pulito eseguiva npx nx test api e 1 suite falliva subito (auth.service.test.ts, "TypeError: Cannot read properties of undefined (reading 'prototype')"), 4 passavano, 14 test verdi, 2.2 s. Il percorso diretto ha raggiunto i test completamente verdi in 2 min 13 s, $0.70, 40 turni. Il percorso a catena, intent poi spec poi plan poi build, è arrivato anch'esso al verde in 11 min 31 s, $3.46, 169 turni. Sono ×5.2 di tempo e ×4.9 di costo solo sul lato macchina s2.

Il lato umano è dove la catena fa male. Ha prodotto 5,488 parole di artefatti da leggere (intent 558 + spec 2,167 + plan 2,763), circa 27 min a 200 parole al minuto, per un fix il cui carico di review diretto è una piccola diff s4. Il task feature (mute degli autori) attraverso la catena completa ha richiesto 15 min 13 s, $4.11, 158 turni e ha consegnato un modello Prisma Mute con migration, endpoint di mute e unmute, filtro del feed, 1,422 inserzioni su 15 file, 50 test verdi con 3 file di test nuovi o estesi e una spec e2e. I suoi artefatti pesavano 6,852 parole (intent 450 + spec 2,337 + plan 4,065), circa 34 min di lettura s2.

La lettura scettica della fase Design ha retto. La critica su LinkedIn dice che il playbook nasconde i suoi prerequisiti: le skill di organizzazione per brand, sicurezza e UX devono già esistere, e qualcuno deve saper condurre il brainstorm s7. L'agente lo ha confermato senza essere sollecitato. Il concern C0 segnalato in spec.md recita, testualmente: "No org skills available. … This spec has therefore not been checked against brand, security or UX policy." Una spec da oltre 2,000 parole che riscrive il codebase e non può verificare le policy è la fase da saltare quando si lavora da soli s7.

Ha retto anche la critica sull'infrastruttura. L'argomento è che quando i test colpiscono fake obsoleti "the agent sees the tests pass and reports the work finished", perché la catena di artefatti registra ciò che è stato deciso, non ciò che gira davvero s8. Nel nostro run, il loop ha verificato solo test unitari e build; la review stessa elencava nx e2e come "Not run: needs a running server and a seeded DB" e prisma migrate status come "Not run: needs a DB". Il loop verde non ha mai toccato un sistema vivo s8.

La fase Deploy è stata la vittoria a basso costo. REVIEW.md è girato in 117 s per $0.80: nx test (5/5 suite, 50 passati), nx build (ok), un delta di lint rispetto alla baseline del plan (34 contro 33, il +1 esplicitamente ammesso dalla voce A3 del plan) e un controllo prettier (9 file in errore, registrato come nit N1). Verdetto: 0 Important, 6 nit, 5 elencati e 1 riassunto perché si applicava il tetto. La review ha rifiutato di approvare il proprio lavoro con "this agent does not approve", la separazione dei compiti come la scrive il corso s2. Il gate con hook si è comportato come descrivono i docs: richiesto un deploy prima del merge, l'agente ha rifiutato di sua iniziativa senza eseguire lo script, quindi l'hook non è mai scattato. Dopo il merge il tentativo di deploy è stato bloccato dall'hook PreToolUse (exit 2) in 14 s con il messaggio del gate s19.

Gli eval sono stati economici da scrivere e facili da sbagliare. Cinque casi sono usciti dalla cronologia git in 283 s per $1.44. Entrambi i run sono stati eseguiti sulla base sbagliata, perché il runner ha creato il branch dopo il merge del fix, ed entrambi gli agenti se ne sono accorti ("the bug was already fixed here") invece di simulare un successo. Un run di eval costa circa 60 o 70 s, quindi la dimensione prevista dal playbook di 20 a 50 casi significa circa 20 a 55 min di tempo agente per ogni run di CI s2. Il setup di CLAUDE.md ha richiesto 63 s e $0.44 per una pagina committata, la mossa più economica di tutte; un triage di log CI in sola lettura ha individuato la causa giusta in 11 s per $0.13 s2.

Il thread della community porta la telemetria più ampia: su 10,000 sviluppatori, i team con alto uso di AI fanno merge del 98% di PR in più mentre il tempo di review sale del 91% e la dimensione delle PR del 154% s6.

Misurazioni

Protocollo: la catena è girata in headless (claude -p, modello claude-opus-5-5, permessi limitati ad acceptEdits più una allowlist, --setting-sources project,local) su un clone scratch di gothinkster/node-express-realworld-example-app (Express + TypeScript + Prisma + Postgres 16 in Docker, workspace Nx). Ogni fase è stata cronometrata e registrata in exp/metrics.jsonl (17 righe). Totale: $11.90 + $0.14 per un rerun dell'hook, 539 + 3 turni, circa 41 min di tempo agente.

Limiti: un repo, uno sviluppatore, un giorno. Le mosse a scala di team non sono state eseguite, la modalità headless comprime i passaggi di intervista in singoli prompt, e gli eval contano solo il costo per run.

Da fare lunedì

• Scrivi una pagina di CLAUDE.md per il tuo repo principale: comandi di build, test e lint, i due errori che l'agente ha fatto la settimana scorsa. Committala. Budget: 63 s di tempo agente.
• Prima del tuo prossimo task non banale, chiedi prima un intent.md: obiettivo, non obiettivi, decisioni aperte. Rispondi alle domande aperte, poi lascia pianificare l'agente. Salta spec.md a meno che tu non abbia skill di policy dell'organizzazione con cui verificarla.
• Esegui la fase di build in plan mode con un loop TDD e chiedi che il plan registri le deviazioni (D1, D2, ...) così la review ha un appoggio.
• Aggiungi un passaggio REVIEW.md eseguito da una sessione nuova, con un tetto di nit e una riga esplicita "this agent does not approve". Fagli eseguire test, build, un delta di lint e un controllo del formatter.
• Metti in piedi un gate deterministico: un hook PreToolUse che esce con 2 su deploy quando il branch non è main.
• Prima di fidarti di un loop verde, elenca in fondo alla review ciò che non ha eseguito (e2e, migration, tutto ciò che richiede un DB vivo).
• Misura la tua tassa di gate: cronometra il percorso diretto e quello a catena sullo stesso piccolo bug, poi conta le parole che hai dovuto leggere.

Per approfondire

• La variante a due gate: un gate di review avversariale (sdlc-gate) e solo due punti decisionali umani invece di uno per fase, la forma pragmatica per un piccolo team s12.
• La catena completa installabile: template per intent, spec, plan e REVIEW, un validatore di gate, un runner di eval e il rilevamento delle bande di controllo, se preferisci non costruire a mano l'impalcatura s5.
• Pianificazione con intervista iniziale: una domanda alla volta batte il batching, e "AI agents don't ask clarifying questions. They assume." Un resoconto di setup senza tempi misurati s11.
• Perché una pipeline fissa viene aggirata: "a docs fix and a payments migration shouldn't travel the same path", e il processo reale diventa invisibile. Raggruppa il playbook con Kiro e GitHub Spec Kit s9.
• Le lacune che un vendor di piattaforme ti venderà: intake da segnale a intent, routing per blast radius, una dashboard di metriche. s13.
• Una consulenza che ha applicato la stessa forma (CRAFT) presso team clienti da gennaio e ammette "we don't yet have a formal answer for what a control band looks like" s10.
• Un esempio concreto di intent.md (una checkbox Select All) che mostra il compito del file: far emergere le decisioni aperte invece di lasciare che l'agente scelga in silenzio s14.

Fonti

• The AI-Native SDLC Playbook (launch post), claude.com. Perché leggerlo: la forma in sei fasi e la regola dell'artefatto committato in cinque minuti.
• The AI-native SDLC playbook (course, 14 lessons), Claude Academy. Perché leggerlo: l'unico posto dove stanno i numeri (da 20 a 50 task di eval, tetto di 5 nit, da 2 a 3 sessioni), gratuito e senza login.
• The Committed-Artifact Chain, howardism.dev. Perché leggerlo: chi redige e chi accetta ogni artefatto, e la franca constatazione che nel playbook nulla è misurato.
• bashebr/ai-native-sdlc, GitHub. Perché leggerlo: template, validatore di gate e runner di eval da installare invece di scriverli.
• Anthropic published an AI-native SDLC playbook, r/ClaudeAI. Perché leggerlo: il thread che porta nel dibattito la telemetria di Faros (98% di PR in più, +91% di tempo di review).
• The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. Perché leggerlo: l'argomento dei prerequisiti nascosti, che la fase di spec ha confermato da sola.
• The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. Perché leggerlo: il problema dei fake obsoleti, con voce da vendor ma l'argomento regge da solo.
• The AI-native SDLC won't be one process, worldprogramming.org. Perché leggerlo: l'argomento sulla cerimonia contro un unico percorso per ogni modifica.
• Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. Perché leggerlo: un team indipendente che converge sulla stessa forma e ammette il buco di Maintain.
• AI-Native SDLC: First Try, kyle.pericak.com. Perché leggerlo: l'unico primo run pratico con intervista iniziale, scritto prima che il playbook esistesse.
• TsCarpe/claude-sdlc-skills, GitHub. Perché leggerlo: la variante a due gate con un passaggio di review avversariale.
• Implementing the Anthropic AI-Native SDLC Playbook, Port blog. Perché leggerlo: l'elenco di ciò che il playbook omette, da leggere come mappa delle lacune.
• What Is intent.md in Claude Code?, dev.to. Perché leggerlo: un intent.md concreto di cui puoi copiare la struttura.
• Hooks guide, Claude Code docs. Perché leggerlo: come un hook PreToolUse con exit 2 diventa il gate deterministico su cui si regge il playbook.

FAQ

La catena completa vale mai la pena per un fix di una riga?

Non in questo run: ×5.2 di tempo e ×4.9 di costo per lo stesso risultato verde, più 5,488 parole da leggere. Per i task piccoli usa solo intent.md.

Perché saltare spec.md quando si lavora da soli?

La spec ha segnalato da sola il problema: senza skill di organizzazione per brand, sicurezza o UX non poteva verificare le policy, e ha speso oltre 2,000 parole a riscrivere il codebase.

L'hook sostituisce il giudizio del modello?

No, lo sostiene. L'agente ha rifiutato da solo il deploy prima del merge; l'hook ha bloccato il tentativo dopo il merge in 14 s con exit 2.