The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage
Guida di ampio respiro di Anthropic a cura di Louis Claxton (team Applied AI), pubblicata il 21 agosto 2026 sul blog claude.com: una lettura dichiarata di 40 minuti, circa 64.000 caratteri, presentata come una raccolta di plays tratti dal lavoro del team con i propri clienti. (A) La diagnosi: con il codice non più il collo di bottiglia, lo spostamento avviene verso le fasi a monte e a valle della scrittura (piano, revisione/test, deploy), i controlli riga per riga smettono di reggere quando è l'agente a scrivere la maggior parte del diff, e il costo della governance aumenta perché le eccezioni continuano a passare per comitati periodici. (B) La risposta: sei fasi (Plan, Design, Build, Test, Deploy, Maintain) organizzate come un loop piuttosto che una catena, ciascuna conclusa da un artefatto committato che la fase successiva legge — intent.md, spec.md, plan.md, il diff e i suoi test, la PR e i suoi findings, il record dell'incidente. (1) La conoscenza istituzionale diventa file versionati: CLAUDE.md, skill, REVIEW.md, bands.yaml. (2) La governance si divide in due livelli, con la skill posizionata come controllo consultivo e l'hook come livello deterministico dietro di essa.
Di Louis Claxton// Fonte claude.com ↗/Lettura 2 min/.md// Traduzione verificata automaticamente
Louis Claxton, del team Applied AI di Anthropic, ha pubblicato il 21 agosto 2026 una guida operativa per un ciclo di vita di sviluppo software "AI-native". Il punto di partenza è uno squilibrio: le organizzazioni oggi scrivono codice a una velocità inimmaginabile un anno prima, ma i processi che lo circondano — gate di approvazione, revisioni, passaggi di consegna, policy — non si sono mossi. Il SDLC tradizionale era pensato per un mondo in cui scrivere codice era la fase più lunga e costosa; i suoi controlli presuppongono inoltre che ogni azione sia compiuta da un umano.
Ne derivano tre conseguenze. Il collo di bottiglia si sposta verso le fasi che continuano a funzionare a velocità umana, a monte e a valle della scrittura. I controlli smettono di essere applicabili: leggere ogni riga aveva senso quando a scriverla era stata una persona. E il costo della governance aumenta, poiché le eccezioni passano per comitati periodici.
La risposta mantiene gli obiettivi di controllo e ne cambia le modalità di esecuzione. Il processo diventa un loop, con l'IA integrata in ogni punto, organizzato in sei fasi — Plan, Design, Build, Test, Deploy, Maintain — scomposte in plays che seguono tutte la stessa griglia, fino alle metriche. Il filo conduttore è l'artefatto committato. L'intento viene catturato dal suo autore originale come intent.md; requisiti e design confluiscono in un'unica sessione che produce spec.md, vincolata dalle skill di brand, sicurezza, compliance e UX; la build inizia in plan mode e blocca plan.md prima che venga scritta qualsiasi riga di codice. La catena dei commit funge da traccia di audit.
La conoscenza istituzionale diventa file versionati: CLAUDE.md per il contesto del repository, le skill per le policy trasversali, REVIEW.md per la dottrina di revisione, bands.yaml per le soglie di produzione. La governance si divide in due livelli, con la skill come controllo consultivo e l'hook come livello deterministico che blocca o richiede approvazione. Un esempio di managed settings dettaglia, chiave per chiave, cosa garantisce ciascuna impostazione in termini di controllo, dal rifiuto di leggere segreti all'imposizione di una versione minima.
La fase Maintain chiude il loop: uno script deterministico monitora una metrica, e il superamento di una banda invoca Claude senza alcun umano nella catena di chiamata, con un livello di autonomia fissato dal tier. Ciò che l'agente rileva viene riscritto come intent.md e reimmesso nel ciclo. Claude Tag, in beta pubblica su Slack, estende lo schema agli incidenti che arrivano via chat. Non vengono presentati risultati quantificati: la guida fornisce metriche da misurare e ne indica la fonte.
Punti chiave
Tre conseguenze quando la build smette di essere il vincolo. (1) il collo di bottiglia si sposta verso le fasi che continuano a funzionare a velocità umana (piano, revisione/test, deploy); (2) i controlli diventano inapplicabili — leggere ogni riga aveva senso quando a scriverla era stato un umano; (3) il costo della governance aumenta, poiché le eccezioni passano per comitati periodici. Esempio riportato: un team di sicurezza dimensionato per un throughput umano, di fronte al quale la coda di revisione cresce oppure il codice viene rilasciato sotto-revisionato.
Il filo conduttore è l'artefatto committato. , non lo strumento: ogni fase termina scrivendo nel version control, quella successiva inizia leggendolo, e la catena dei commit è la traccia di audit. Il .md domina a monte perché il product owner e l'agente leggono lo stesso file; a partire dalla fase di build, l'artefatto è il codice e le sue tracce.
Trigger a cascata. un intent.md accettato attiva il passaggio requisiti/design, uno spec.md approvato attiva la plan mode, una PR mergiata attiva la pipeline, una banda superata in produzione scrive il successivo intent.md. I team iniziano sollecitando manualmente ogni fase; lo stato target è il loop in cui ogni artefatto accettato arma il gate successivo.
Skill vs. hook — la distinzione regge l'intero edificio di controllo. la skill rende probabile la conformità a una policy senza costringere una sessione a rispettarla; l'hook è deterministico e blocca l'azione. Una policy che deve valere sempre richiede un hook o un passaggio di revisione dietro la skill. Corollario: un hook che richiede approvazione umana appartiene al deployment, non alla build, dove rimetterebbe una persona sul percorso critico di ogni sessione parallela.
Sistemi legacy. per ciascun artefatto, indicare un unico sistema come fonte di verità (il repo, oppure Jira/ServiceNow con i file .md come copie di lavoro), con tutto il resto che conserva solo un link. Il semplice concatenamento — l'artefatto porta l'ID del record, il record porta lo SHA del commit — è proposto come soglia minima di partenza.
Test. il ciclo di feedback (test, build, screenshot diff) gira per tutta la durata del task; il subagent verificatore è un passaggio finale con contesto nuovo, così il verdetto non è condizionato dalle ipotesi che hanno prodotto il codice. Per una correzione, scrivere prima il test fallimentare, committarlo, poi bloccare l'agente dal modificarlo tramite un hook. Le evals sono la controparte AI-native dei gate di QA: da 20 a 50 task reali rieseguiti a ogni modifica di CLAUDE.md, di una skill o di un hook, con ogni incidente che diventa un'eval permanente.
Maintain, a chiusura del loop.il rilevamento resta deterministico (media e deviazione standard su finestra scorrevole, regole Western Electric, uno script versionato e testato, nessun modello coinvolto); Claude viene invocato solo al superamento di una banda, e il tier fissa cosa può fare — 1σ registra, 2σ diagnostica in sola lettura, 3σ propone (una PR o un runbook pre-approvato). Il rollback è indicato come il percorso che deve essere il più esercitato della pipeline.
⚠️ Ciò che il pezzo non quantifica: nessun risultato quantificato, né in termini di risparmio di tempo né di tasso di adozione. I numeri della guida sono parametri di implementazione (20-50 evals, due o tre sessioni parallele per iniziare); i risultati restano metriche da misurare in proprio, con la relativa fonte indicata ogni volta (git log, metadati delle PR, export OpenTelemetry, DORA, strumento di tracciamento degli incidenti).
Da collegare. [[sfeir-sdlc-ia-cycle-11-phases-2026-06-16]] (una scomposizione concorrente, in undici fasi) e [[sfeir-code-review-anneau-contraintes-2026-07-30]] (l'anello di vincoli attorno all'agente, dove hook e revisione sono qui due anelli distinti).
Dati chiave
performance di delivery, indicatore ritardato del play CI/CD