Post di ingegneria di **Anthropic** pubblicato il **14 settembre 2026** su claude.com/blog (~1.400 parole, cinque sezioni), scritto da **Sachin Malhotra**. Racconta la scalata del servizio di **test impact analysis** — la selezione dei test da eseguire per ogni modifica — sotto la pressione della programmazione agentica. I numeri di partenza e la loro concatenazione: gli ingegneri rilasciano in media **8×** più codice a trimestre rispetto al periodo 2021-2025, **Claude ne scrive l'80%** e pesa inoltre in modo significativo nella revisione e nell'approvazione delle PR; il numero di test è stato moltiplicato per **10** con un organico quasi costante; da cui **25× i job CI in sei mesi**. **(A)** L'architettura v0 si basa su due componenti che devono restare sincronizzati — un *listener* che registra i risultati di ogni esecuzione, un *selector* che decide quali test eseguire per ogni PR — ma come **processo unico**, una cronologia per singolo test che presuppone un solo writer. **(B)** La modalità di guasto è il listener che resta indietro rispetto alla coda delle PR: *« 20 minuti di ritardo del listener possono tradursi in decine di migliaia di aggiornamenti di test non applicati »*, con tre conseguenze indicate — investigazioni sprecate, *flaky reds* che bloccano i merge, un test corretto o aggiunto che non viene eseguito. **(C)** Tre correzioni la cui durata di vita collassa — **70 giorni, 29 giorni, meno di un giorno**: una macchina più grande, lo sharding per package, i riavvii giornalieri. Poi la revisione completa: un magasin de données en mémoire **in-memory**, worker *listener* **stateless** quindi scalabili orizzontalmente, un log aggregato ogni pochi secondi. **Tre settimane per un ingegnere; un trimestre, un anno prima.** Estende l'80% di [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] all'infrastruttura.
#integrazione continua#CI#test impact analysis
Sachin Malhotra (ingénieur, Anthropic) · sur le blog claude.com.
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)