AIDiveIl playbook che nessuno ha misurato
Anthropic ha pubblicato un playbook SDLC AI-native per Claude Code: sei fasi, ciascuna delle quali termina con un file in commit, offerto come corso gratuito. La tesi centrale è che il codice non è più il collo di bottiglia, e che a gestire ciò che lo è sia la catena di artefatti in commit. Il documento stesso non contiene alcuna misurazione: nessun tempo, nessun costo, nessun benchmark. Abbiamo eseguito il primo test cronometrato su un repository reale: sedici sessioni Claude Code cronometrate, ogni gate con il suo prezzo, e un verdetto che spacca la catena a metà. Strada facendo, una correzione da due minuti fatta passare per l'intera catena ha messo un prezzo alla cerimonia, e il nostro stesso deploy è stato fermato due volte, una delle quali da quattro righe di shell.
Il playbook e il banco di prova
Il banco di prova: sedici sessioni Claude Code cronometrate, circa 12 $ di calcolo, un repository reale. Il playbook prevede sei fasi: plan, design, build, test, deploy, maintain. Ogni fase termina con un file in commit, e la fase successiva lo legge: intent, spec, plan, la pull request, il registro dell'incidente. I commit sono la traccia di audit. Anthropic lo insegna come corso gratuito di 14 lezioni, circa un'ora, scritto per aziende con gate di review; noi abbiamo testato ciò che sopravvive al contatto con un singolo sviluppatore.
Il repository è l'app demo RealWorld (Express, TypeScript, Prisma, Postgres): un progetto vero con test veri, e una suite rotta su un clone pulito (quattro suite che passano, 14 test verdi, due secondi di esecuzione). Quel bug diventerà il gruppo di controllo più avanti. La regola di punteggio: un gate ripaga quando il suo output cambia ciò che va in produzione, a un costo inferiore a quello che richiede.
Il biglietto d'ingresso è un file di memoria nella radice del repo: comandi, convenzioni, architettura, gli errori che il modello continua a ripetere, il tutto in meno di una pagina. Il nostro è stato scritto e committato in 63 secondi per 0,44 $. Una precisazione onesta sul metodo: le esecuzioni headless comprimono le interviste del playbook in singoli prompt.
Plan: intent.md in ventinove secondi
Il primo gate cattura l'idea prima che qualcuno la progetti. La richiesta di feature: i lettori vogliono silenziare gli autori che inondano il loro feed. Il playbook chiama il risultato una proto-spec, scritta con il modello e di cui sei proprietario, e ne ammette tre origini: un'idea, un ticket aperto o un alert di incidente. Il template ha cinque sezioni i cui titoli fanno il lavoro di pensiero: problema, esito proposto, utenti e sistemi coinvolti, vincoli, domande aperte. Il ciclo di lavoro è fatto di cinque mosse: descrivere, fare brainstorming, generare dal template, correggere, committare.
| intent.md | tempo | costo |
|---|---|---|
| Feature mute-authors | 29 s | $0.18 |
| Suite di test rotta | 39 s | — |
Il valore sta in fondo, nelle domande aperte: che ne è dei preferiti di un autore silenziato? Le sue pagine restano raggiungibili? Sono decisioni che un agente di coding prenderebbe altrimenti in silenzio, ora scritte e datate. Il file è committato, quindi autore e timestamp sopravvivono alla chat, e il product owner corregge la bozza prima di accettarla. L'obiettivo di Anthropic per questa fase è un'elicitazione in ore, non in settimane; da soli, bastano meno di un minuto.
Design: la spec segnala il proprio prerequisito
Il secondo gate trasforma l'intent in una spec con un solo prompt del corso: leggi l'intent, produci una spec di requisiti e design, applica le skill disponibili, cioè le skill che dovrebbero portare le policy di brand, sicurezza e UX. Due minuti dopo avevamo circa 2.300 parole di spec competente: endpoint, modello dati, comportamento del feed, casi limite. Ha persino registrato ciò che non poteva soddisfare, esattamente come chiede il prompt.
Il colpo di scena sta nelle sue preoccupazioni segnalate, scritte dal modello stesso: "C0. No org skills available. This spec has not been checked against any policy." L'intera premessa della fase presupponeva file che nella maggior parte dei setup non esistono: i video esplicativi saltano questo prerequisito, l'agente l'ha messo per iscritto. La seconda segnalazione era più mite: i default delle domande aperte richiedono l'approvazione del prodotto prima del build.
La lezione è rigorosa sull'abbinamento (spec e intent vengono committati insieme, e un umano approva il passaggio al build), e c'è un conto di lettura: circa 12 minuti di tempo del product owner per ogni spec. Il playbook tiene persino traccia del rework: i commit della spec datati dopo l'inizio del build contano contro di te. In un team che ha codificato le proprie policy, questo gate è il punto in cui vengono eseguite. Da soli, si paga una promessa che il setup non può ancora mantenere.
Build: plan mode, TDD e cosa controlla davvero il ciclo
Il terzo gate è Plan Mode, e l'asticella è brutale e utile: un ingegnere che non ha mai visto la conversazione deve poter implementare partendo dal solo plan. Plan Mode fa rispettare da sé la metà della lettura: il modello non può modificare file finché il plan non è accettato. Il nostro è uscito di circa 4.000 parole in quattro minuti, con i file che cambiano, l'ordine del lavoro, i rischi e la prova, e tre deviazioni etichettate dalla spec che ritorneranno più avanti nella review.
Il build procede a ciclo: scrivi il test che fallisce, fallo passare, un solo obiettivo, tutto verde o il task non è finito. Il ciclo è protetto (un agente che corregge il codice non deve indebolire il controllo su quel codice) e affiancato da un verificatore: un secondo controllo in un contesto nuovo, non influenzato dalla sessione che ha scritto il codice.
| Risultato del build | valore |
|---|---|
| Tempo agente | ~9 min, 91 turni |
| Costo | ~$2 |
| Modifica | 15 file, tabella Mutes, due endpoint, entrambi i feed filtrati |
| Test | 5 suite, 50 test, tutti verdi in una riesecuzione indipendente |
| Merge al primo passaggio | sì |
L'asterisco: il verde dimostra ciò che il ciclo contiene, niente di più. L'end-to-end non è mai stato eseguito: richiede un server attivo e un database popolato, e un ciclo puntato su fake obsoleti sarebbe verde allo stesso modo. Su scala di team si aggiungono sessioni parallele nei worktree (due o tre è il tetto dichiarato); non l'abbiamo testato.
Deploy: la review e il gate che ha detto no
Il gate di deploy ha due livelli, ed entrambi ci hanno detto no. Il primo livello legge il diff secondo una policy scritta nella radice del repo: tre passaggi (bug, sicurezza, conformità rispetto a spec e plan), "Important" riservato a comportamenti rotti, dati esposti o policy violate, al massimo cinque nit con il resto riassunto in un conteggio: la policy limita il proprio rumore. Due minuti di review, 0,80 $, e ha eseguito i controlli veri: test, build, lint rispetto alla baseline registrata nel plan, formattazione su nove file. Verdetto: zero problemi Important, sei nit, uno oltre il limite riassunto. Si è chiusa con una frase che non avevamo richiesto: questo agente non approva, l'approvazione resta a un code owner umano dietro la branch protection.
Il secondo livello è il gate vero e proprio. Abbiamo chiesto il deploy; il modello ha rifiutato da solo, perché la feature non era sul branch di rilascio. Quello è giudizio, non enforcement. Così abbiamo fatto il merge e chiesto di nuovo: quattro righe di shell hanno risposto in 14 secondi, bloccato, autorizzazione al rilascio richiesta. L'exit code 2 ferma la chiamata allo strumento e il motivo torna al modello. Lato pipeline abbiamo applicato lo stesso trattamento: una build rotta analizzata in modalità headless in 11 secondi per 0,13 $: ha letto il log, indicato la causa esatta e proposto il diff senza toccare alcun file. Il deterministico batte il cortese; un hook vale quanto il suo pattern, e il nostro intercettava un solo script.
La tassa dei gate
Stesso bug, stessa partenza rotta, due strade: l'esperimento di controllo. Prima strada: correggere e basta. Seconda strada: l'intera catena, da intent a build.
| correzione diretta | catena completa | moltiplicatore | |
|---|---|---|---|
| Tempo reale | 2:13 | 11:31 | ×5.2 |
| Costo | $0.70 | $3.46 | ×4.9 |
| Turni | 40 | 169 | — |
| Esito | suite verde | suite verde | identico |
Il conto della macchina è la metà piccola. La catena ha scritto circa 5.500 parole di artefatti per una correzione di una riga: circa 27 minuti di lettura umana per un diff che si scorre in un minuto. La catena converte tempo di scrittura in tempo di lettura: questa è la tassa dei gate.
Il playbook aggiunge un costo ricorrente: le eval continue. Da venti a cinquanta task reali, rieseguiti a ogni cambio di configurazione: ogni caso è un task passato reale, con il prompt originale, eseguito dal commit precedente alla modifica, con criteri di accettazione verificabili. Scrivere cinque casi dalla cronologia ha richiesto cinque minuti; eseguirli bene non è altrettanto facile: il nostro primo harness ha puntato due casi sul commit sbagliato, ed entrambi gli agenti se ne sono accorti invece di simulare un successo. A circa un minuto per caso, una suite completa costa fino a un'ora di tempo agente per esecuzione, e ogni incidente in produzione dovrebbe entrare nella suite come eval di regressione permanente. In un team regolamentato quella lettura è il deliverable; da soli, è overhead.
Verdetto: tre su sei ripagano
Tre gate su sei ripagano se stessi:
| Fase | verdetto | evidenza |
|---|---|---|
| Plan | tienilo | 40 s comprano le domande che nessuno aveva fatto |
| Build | tienilo | plan mode + il ciclo di test hanno consegnato 50 test verdi |
| Deploy | tienilo | review da 0,80 $ con controlli veri, blocco deterministico in 14 s |
| Design | salta da solo | ti fattura policy che non hai codificato |
| Test (eval continue) | può aspettare | fino a un'ora per esecuzione, facile da puntare male |
| Maintain | non provato | servono settimane di telemetria di produzione |
Maintain è elegante sulla carta (script deterministici sorvegliano le bande di controllo e uno sforamento scrive un nuovo file intent), ma dimostrarlo richiede telemetria di produzione che non abbiamo. Il documento di Anthropic, come ha detto un analista, non contiene alcuna misurazione da nessuna parte; questi sono i primi numeri, con i limiti evidenti: un repo, uno sviluppatore, un giorno.
I dati esterni dicono che la pressione è reale. Faros ha monitorato oltre 10.000 sviluppatori in più di 1.200 team: i team ad alta adozione fanno il merge del 98% in più di pull request, il tempo di review sale del 91% e la pull request media più che raddoppia di dimensione. L'ultimo report DORA va nella stessa direzione: throughput in aumento con l'AI, stabilità in calo. La review sta diventando il collo di bottiglia, e il playbook mira esattamente lì. Alcune varianti della community riducono già la catena a due decisioni umane: una offre template e un registro dei gate, l'altra tiene gli umani solo su design e test. Adotta i tre gate che ripagano e cresci verso il resto quando lo farà il tuo team. La frase finale di Anthropic è il giusto epitaffio: il ciclo continua a girare, il giudizio umano resta sopra di esso.
