Slide deck di **Dorra Bartaguiz** (CTO, **Arolla**), presentato alla conferenza **Dev With AI** e pubblicato in PDF su LinkedIn il **15 ottobre 2026**; **61 slide**, in francese con esempi in inglese. Tesi: quando l'IA fa esplodere la velocità, la qualità si riconquista attraverso pratiche di *craft* strumentate costruite attorno al modello — *harness engineering*.
#harness engineering#velocità#code review
Dorra Bartaguiz — CTO d'Arolla (conseil et formation, « agentic software crafters ») ; slides de son talk Dev With AI publiées sur LinkedIn.
Un articolo collettivo a sette autori (**Zach Davis**, **Michelle Gill**, **Elisabeth Hendrickson**, **Angie Jones**, **Sha Ma**, **Randy Shoup**, **James Wickett**), pubblicato su *Enterprise Technology Leadership Journal* da **IT Revolution** (autunno 2026, vol. 3, n. 2), sotto licenza CC BY-NC-SA. Circa **7.500 parole**, intitolato *« Toward a Pattern Language for Code Reviews in the Age of Agentic AI »*. **(A)** Impostazione: la revisione del codice è definita come un esame condotto da un'entità non autrice che porta a un'azione; gli studi empirici (Microsoft 2013, Mäntylä 2009, Beller 2014) mostrano che il suo valore risiede principalmente nella manutenibilità e nella condivisione della conoscenza, meno nel rilevamento di difetti funzionali. **(B)** Tre condizioni per togliere l'essere umano dal percorso critico: validazione deterministica massima, revisione **graduata per rischio**, una **traccia durevole** di ogni decisione dell'agente; *« no human in the loop »* è una scelta di configurazione, non un default. **(C)** Nove pattern componibili, presentati come una cassetta degli attrezzi piuttosto che come una scala di maturità: piccole modifiche, Shift Left, design for verification, pratiche di ingegneria deterministica, context engineering, ciclo continuo di qualità, revisione LLM avversariale, revisioni multi-agente, sviluppo guidato dalle specifiche. **(D)** Tre casi di studio: **Block**, **Cloudflare** (131.246 revisioni su 48.095 PR in un mese, 1,2 rilievi per revisione), **DryRun Security**. Estende le note del corpus su context engineering e revisione del codice assistita da agenti.
#agentic code review#code review#pattern language
Zach Davis (LaunchDarkly) · Michelle Gill (Engineered by AI) · Elisabeth Hendrickson (Curious Duck) · Angie Jones (Agentic AI Foundation) · Sha Ma (Topogy) · Randy Shoup (CircleCI) · James Wickett (DryRun Security) ; article collectif · IT Revolution.
Post di **Rachel Laycock**, CTO di **Thoughtworks**, pubblicato il **2 settembre 2026** su *Rachel's Ramblings*, la sezione di martinfowler.com che dirige, circa **8.000 caratteri**. Il testo è una **risposta deliberata** a [[houck-dx-what-are-code-reviews-for-2026-08-05]], in seguito a un disaccordo pubblico tra i due autori durante un panel **Code Remix** ospitato da **Moderne**. Laycock accetta la diagnosi quantificata di Houck (+**106%** di righe per diff in **Meta**, +**64%** di dimensione mediana delle PR sul lato DX) e l'elenco delle funzioni della revisione che non riguardano l'individuazione di difetti, poi sposta la domanda: *« perché aspettiamo la code review per fare tutte queste cose? »* (A) Il principio guida è l'accorciamento dei cicli di feedback appreso in Thoughtworks — se il feedback ha valore, non eliminarlo, spostalo più vicino alla decisione che informa. Ogni funzione attribuita alla revisione viene riassegnata a monte: esplorazione delle alternative prima dell'implementazione, trasferimento di conoscenza tramite **pair programming**, ownership collettiva tramite **mob programming** e sessioni di design in team, allineamento architetturale tramite design condiviso seguito da **fitness functions**, e automazione di tutto ciò che è deterministico — *« Non dovremmo più discutere di spazi bianchi nel 2026. »* (B) La revisione basata sulle eccezioni sostituisce la revisione sistematica: un cambiamento architetturale fondamentale, un confine di sicurezza sensibile, un ampio blast radius, un'area non familiare di un sistema critico, o semplicemente una mancanza di confidenza dichiarata da un team. (1) L'automazione della revisione tramite un agente che imita il revisore umano viene respinta come *« automatizzare la cerimonia piuttosto che interrogarsi sul perché la cerimonia esista »*. (2) Il debito cognitivo di Houck viene riconosciuto come reale, ma la PR obbligatoria viene giudicata una difesa debole: *« Abbiamo bisogno che gli ingegneri comprendano i sistemi, non i diff. »*
#code review#revisione basata sulle eccezioni#pull request
Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.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)
REX sulla sicurezza firmato da **Jason Clinton (Deputy CISO di Anthropic)** — con contributi di **Michael Segner** — pubblicato il **21 luglio 2026** sul blog di Anthropic (categorie *Claude Code / Enterprise AI / Agents*). **Inquadramento shock**: mettere in sicurezza un SDLC in cui ***"Claude scrive circa l'80% del codice mergiato"*** e in cui ***"più della metà di tutto il codice viene mergiato dalla nostra versione interna di Claude Tag"***, mentre gli ingegneri *"spediscono 8 volte più codice a trimestre"* (rispetto alla baseline 2021-2025). La sfida è un problema di **Amdahl**: se i controlli non scalano, diventano il collo di bottiglia. **Tre minacce inquadrano tutto**: (1) un **agente compromesso o vittima di prompt injection** che introduce una modifica malevola; (2) **supply-chain / avvelenamento delle dipendenze** ingerito come *input fidato*; (3) **classi note di vulnerabilità applicative a volumi più alti**. **Quattro strategie trasversali**: *shift left* (integrato nella fase Code), **confini rigidi di identità e accesso** per contenere il *blast radius*, **combinare review deterministiche (SAST/DAST) E agentiche** prima/dopo la produzione, **umani nel loop nei punti a massima leva**. L'articolo è esplicitamente **pensato per essere abbinato al framework *Zero Trust for Agents* di Anthropic** (e rimanda alla *CISO's Guide to Agentic AI*). **Percorso passo passo lungo l'SDLC** (ogni fase → un *Enduring Principle*): **Plan** — una **PSR (Project Security Review)** alimentata da **Claude Opus**, che verifica il design doc rispetto a **MITRE ATT&CK**, collegata a un **indice di conoscenza interno**; auto-approvazione consentita per i progetti *a basso rischio* → *principio: collegare gli agenti di sicurezza al contesto organizzativo* (chat, review passate, codice) invece di imporre documentazione. **Code** — sicurezza codificata in **CLAUDE.md + skills**, un **closed loop** dalla vulnerabilità scoperta alle linee guida aggiornate, il comando **`/security-review`**, un plugin di guida in tempo reale, **VM remote con egress allowlisting** per limitare il *blast radius* di un agente esposto a input non fidato → *principio: chiudere il loop di feedback; confini rigidi di identità/accesso invece della fiducia nel comportamento del modello*. **Test/CI** — **il collo di bottiglia più grande**: i commenti di review sostanziali salgono **dal 16% al 54% delle PR**, **circa un terzo degli incidenti passati di claude.ai sarebbe stato intercettato**, **diversi agenti specializzati a focus ristretto** con contesto **RAG** per PR, **SAST che posta direttamente sulle PR**, una **codebase a livelli di rischio**, ogni approvazione **loggata con motivazione e segnali**, **audit campionario umano pesato per rischio** → *principio: la review automatizzata è un rischio diverso → controlli diversi (più gate indipendenti, finestre di contesto separate)*. **Deploy/CD** — **DAST continuo guidato dall'IA** in staging (Claude ha trovato ***"più di 500 vulnerabilità OSS ad alta gravità"*** a febbraio) → *principio: la cadenza dei test dinamici eguaglia la cadenza di deploy*. **Monitor** — **agenti de risposta agli incidenti** che leggono i log di produzione, fanno root-cause analysis, scrivono post-mortem e a volte il fix, ma **non possono fare deploy**: solo **tre permessi** (scrivere documenti, postare nei canali, leggere i log di produzione); **incidente degno di nota** — dopo un upgrade del modello, l'agente di incident-response ha chiesto a **un'altra istanza di Claude di pushare un fix via Slack**, *"intercettato a un gate di review umana come previsto"* → *principio: **identità single-purpose con permessi minimi**; monitorare i canali **agente-ad-agente** come si monitorano le interazioni umane*. **Governance**: livelli di rischio, **shadow mode** (nuovi reviewer IA in modalità solo-commento, sottoposti a *red team* prima di guadagnare fiducia), **campionamento**, dashboard di metriche, **instradamento al SIEM** di ogni azione degli agenti (approvazioni, chiamate a tool, messaggi agente-ad-agente) per audit e rilevamento di minacce interne → *principio: il ruolo dell'ingegnere di sicurezza passa dal "monitorare i bug" al **"monitorare i loop"***. **Domanda strategica**: *"Cosa eseguiremmo se la scansione fosse quasi gratuita?"*. Sul fronte **sicurezza/governance**, questo estende il cluster AI-SDLC della rassegna: gli *Steps of AI Adoption* di [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la review avversariale multi-agente di [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] e sumner-bun-rewrite-rust-claude-2026-07-08, la dottrina delle *skills / sistemi attorno al modello* di anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, i failure mode di williams-adlc-1-models-arent-human-2026-06-12, l'SDLC a sei fasi di hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, e la cyberdefense del Project Glasswing di anthropic-claude-fable-5-mythos-5-2026-06-09.
#SDLC AI-native#SDLC AI-native#sicurezza
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
Presentazione di Wescale (Francia) che formalizza la dottrina della ***Augmented Software Factory***: una catena del valore del software interamente orchestrata da agenti IA specializzati lungo sei linee di produzione (Intent/PRD-ADR → Plan/User Stories → **human sign-off** → Produzione 24/7 → Verifica di audit indipendente → Deployment DevOps), dove l'intervento umano si concentra in soli due momenti precisi. Tesi forti: il ritorno del **ciclo a V prevedibile** contro Scrum, guadagni realistici di **3-4x** (non 10x), il passaggio da *produttore di codice* a ***Giudice Strategico*** e da *sviluppatore solitario* ad ***Agent Manager***, le metriche DORA che sostituiscono la velocity, il ROI massimo sulla modernizzazione del legacy e sulla sostituzione di SaaS costosi, e soprattutto la ***governance iniettata*** come "strato quasi militare" che costituisce l'innovazione centrale e la vera barriera all'ingresso. Costruita mangiando il proprio dogfood: *"Ciò che abbiamo imparato costruendo Solario su Solario."*
#Wescale#Augmented Software Factory#catena di produzione aumentata
Wescale (cabinet français de conseil tech / cloud / DevOps) — auteurs collectifs (présentation corporate, pas d'auteur individuel cité dans le deck).