# claxton-anthropic-ai-native-sdlc-playbook-2026-08-21

## Veille

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. La separazione dei compiti è posta come invariante — l'agente che scrive il codice non può approvarlo — e il pezzo si chiude con *"The loop keeps running. Human judgement stays above it."* Il corpus contiene già [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sul versante sicurezza dello stesso ciclo, e [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sulla stessa scomposizione in sei fasi vista da un concorrente.

## Titre Article

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

## Date

2026-08-21

## URL

https://claude.com/blog/the-ai-native-sdlc-playbook

## Keywords

AI-native SDLC, software development lifecycle, plays, intent.md, spec.md, plan.md, CLAUDE.md, REVIEW.md, bands.yaml, committed artifact, audit trail, plan mode, auto mode, hooks, skills, subagents, parallel sessions, git worktrees, feedback loop, continuous evals, agentic PR review, separation of duties, managed settings, sandbox, MCP, claude-code-action, Agent SDK, control bands, Western Electric rules, OpenTelemetry, DORA, Claude Tag, leading indicators, lagging indicators, governance as code

## Authors

Louis Claxton (Anthropic, équipe Applied AI), sur le blog claude.com ; contributions créditées à Jim Blackhurst, Will Steuk et Jamal Arif.

## Ton

Profilo: guida aziendale di ampio respiro con finalità operativa, voce al "noi" del team Applied AI di un fornitore che descrive l'uso dei propri prodotti, registro prescrittivo e procedurale, livello tecnico elevato, rivolta a platform lead, tech lead e team compliance/sicurezza di grandi organizzazioni, comprese quelle regolamentate. La struttura è quella di un **manuale** più che di un saggio: ogni *play* segue la stessa griglia — cosa cambia, prerequisiti, infrastruttura, passi di esecuzione, considerazioni di governance, un indicatore anticipatore e un indicatore ritardato — e quasi ognuno è accompagnato da un artefatto mostrato tal quale (`intent.md`, `plan.md`, `CLAUDE.md`, `SKILL.md`, `settings.json`, `bands.yaml`, un workflow GitHub Actions). Il vocabolario è mutuato dal controllo interno — *control objectives*, *separation of duties*, *approval gates*, *audit trail*, *blast radius* — e serve a tradurre le pratiche agentiche nelle categorie di un revisore. La retorica procede per opposizione binaria sistematica, con ogni play che si apre su una coppia *Traditional* / *AI-native*. Il testo rivendica il proprio ruolo commerciale senza dissimularlo — i prodotti citati (Claude Code, Claude Design in beta, Claude Tag in beta pubblica, Code Review in *research preview*, Cowork) sono i propri, e la sezione conclusiva rimanda a quindici pagine di documentazione. Resta tuttavia cauto sui propri limiti — della skill si dice che non forza nulla, e i managed settings sono offerti come punto di partenza da adattare, non come raccomandazione da copiare alla lettera.

## Pense-betes

- **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).

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Anthropic —publie→ The AI-Native SDLC playbook (DOCUMENT, 0.97)
- Louis Claxton —a_créé→ The AI-Native SDLC playbook (DOCUMENT, 0.95)
- The AI-Native SDLC playbook —affirme_que→ le goulot se déplace du build vers les étapes restées à vitesse humaine (AFFIRMATION, 0.94)
- SDLC AI-native —est_variante_de→ SDLC (METHODOLOGIE, 0.92)
- SDLC AI-native —utilise→ artefact committé (CONCEPT, 0.93)
- artefact committé —permet→ piste d'audit (CONCEPT, 0.9)
- intent.md —fait_partie_de→ SDLC AI-native (METHODOLOGIE, 0.92)
- spec.md —est_basé_sur→ intent.md (DOCUMENT, 0.91)
- plan.md —est_basé_sur→ spec.md (DOCUMENT, 0.9)
- Plan mode —permet→ plan accepté avant toute écriture de code (CONCEPT, 0.93)
- CLAUDE.md —s_applique_à→ contexte du dépôt lu à chaque session (CONCEPT, 0.92)
- Claude Skills —s_applique_à→ politique appliquée pendant l'écriture du code (CONCEPT, 0.9)
- hooks —améliore→ Claude Skills (TECHNOLOGIE, 0.88)
- Louis Claxton —affirme_que→ une skill est un contrôle consultatif, rien n'oblige une session à la suivre (AFFIRMATION, 0.92)
- REVIEW.md —s_applique_à→ passes de revue bugs, sécurité et conformité au spec et au plan (CONCEPT, 0.89)
- séparation des tâches —s_applique_à→ l'agent qui écrit le code ne peut pas l'approuver (AFFIRMATION, 0.93)
- evals continues —s_applique_à→ configuration d'agent versionnée, testée comme du code (CONCEPT, 0.9)
- Louis Claxton —recommande→ collecter 20 à 50 tâches réelles pour constituer la suite d'evals (AFFIRMATION, 0.88)
- Louis Claxton —recommande→ démarrer à deux ou trois sessions parallèles par ingénieur (AFFIRMATION, 0.87)
- git worktrees —permet→ sessions Claude Code parallèles isolées (CONCEPT, 0.9)
- bands.yaml —permet→ paliers d'autonomie 1σ, 2σ, 3σ (CONCEPT, 0.9)
- détection de bande de contrôle —affirme_que→ la détection reste entièrement déterministe, sans modèle impliqué (AFFIRMATION, 0.92)
- MCP —permet→ déploiement et rollback exposés comme outils cadrés par environnement (CONCEPT, 0.89)
- managed settings —réduit→ surface d'action de l'agent en environnement régulé (CONCEPT, 0.89)
- Claude Tag —s_applique_à→ réponse à incident depuis un canal Slack (CONCEPT, 0.88)
- DORA —mesure→ performance de livraison, indicateur retardé du play CI/CD (MESURE, 0.85)

---
Canonical: https://www.thekb.eu/it/fiches/claxton-anthropic-ai-native-sdlc-playbook-2026-08-21/