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.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Decodifica di SFEIR (voce aziendale) del resoconto di Jason Clinton (Deputy CISO, Anthropic) pubblicato cinque giorni prima — già documentato in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **Il valore aggiunto non risiede nei fatti ma nella tesi che li rilegge**: se i controlli di Anthropic reggono, è perché **esiste un ciclo con fasi nominate a cui agganciarli** — "lo SDLC è il fondamento, non una formalità." La dimostrazione procede rileggendo la mappatura (**PSR in fase Plan, CLAUDE.md + egress allowlist in fase Code, agenti di revisione in fase Test, DAST continuo in fase Deploy, triage + instradamento SIEM in fase Monitor**), poi attraverso un'**anafora in quattro parti**: (1) *senza uno SDLC, i guadagni di produttività non si materializzano* — Clinton cita la **legge di Amdahl**: moltiplicare per 8 il volume di codice non moltiplica nulla se la revisione resta sequenziale e umana, e Anthropic ha guadagnato non distribuendo agenti ma **individuando la fase di blocco (Test) e ricostruendola** — "non si ottimizza un collo di bottiglia che non si è mappato" (in eco all'**effetto specchio** del DORA 2025); (2) *senza uno SDLC, la sicurezza non ha un punto di ancoraggio* — un **gate è per definizione un controllo posto tra due fasi**, e le tre minacce di Clinton vengono affrontate in momenti distinti; (3) *senza uno SDLC, nessuna politica di **FinOps dei token** può essere formulata* — la scansione agentica viene fatturata a consumo e cresce con il throughput di codice, quindi **il tiering basato sul rischio È la politica di FinOps** (decide dove pagare tre passaggi agentici e dove basta un SAST), altrimenti "la spesa in token non viene pilotata, viene scoperta a fine mese"; (4) *senza uno SDLC, non c'è nulla da misurare* — gli indicatori (16% → 54% delle PR commentate, un terzo degli incidenti passati intercettati) esistono solo perché ci sono fasi in cui si può collocare un contatore; in loro assenza, si producono solo **cifre di utilizzo** (licenze, token) che non dicono nulla sulla qualità o sul rischio. Due punti di forza oltre la tesi: la lettura dell'**incident agent-à-agent** ("un perimetro di sicurezza che si fonda su un'istruzione in un prompt non è un perimetro"; **l'accesso di un agente ad altri agenti fa parte della sua superficie di attacco**) e un **avvertimento metodologico esplicito** — le cifre di Anthropic su Anthropic, non verificate, pubblicate dal fornitore del modello descritto, nel contesto di una codebase giovane senza mainframe: **ciò che si traspone è il metodo, non le cifre**.
#SDLC#SDLC nativo per l'IA#ciclo di sviluppo
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
Studio di dati Atlassian (Inside Atlassian) che misura il rendimento effettivo di un **SDLC AI-native** basato su **Rovo Dev**. Su 3.400 repository di 2.500 clienti (un quasi-esperimento con propensity-score matching), i repository che adottano lo strumento uniscono il **19% di PR in più al mese**; fino al **37-51%** sui repository a bassa/media attività e al **59-87%** quando **da 3 a 5 membri** del team adottano lo strumento. Sul fronte dell'efficienza, gli sviluppatori risparmiano **2-3 h/settimana** (circa il 10% delle 24 ore dedicate a coding e review), ossia 20-30 ore/settimana reinvestite per un team di 10 persone. La tesi: risolvere il "paradosso della produttività" di Solow (1987) passando da **metriche di utilizzo** (token) a **metriche di impatto** (throughput, tempo risparmiato, tasso di fallimento, soddisfazione). Raccomandazione: iniziare con un **team** (non un individuo) e misurare 2-3 mesi dopo.