Issue 10047 · agentic-sdlc
La verifica è il vero collo di bottiglia del delivery agentico
Quando l'automazione accelera l'esecuzione, il rischio si sposta sulla correttezza: serve una strategia di evidenze, test e gate umani proporzionata.
Obiettivo
Progettare una strategia di verifica basata su test deterministici, evidenze, review ed escalation umana che distingua l'esecuzione di un'attività dalla correttezza del risultato.
practice
Cosa fare in pratica
Nel delivery agentico non devi chiederti solo se l'agente ha completato un'attività, ma se il risultato è corretto, verificabile e accettabile per il rischio in gioco. La distinzione è importante: uno strumento può aver eseguito correttamente un comando, i controlli previsti possono essere passati e la pull request può essere aperta, ma nessuno di questi elementi prova da solo che il risultato sia corretto o che il cambiamento sia autorizzato. Il punto di partenza è definire prima della generazione quali evidenze servono. Per i cambiamenti tecnici, la sequenza più robusta è: controlli di schema o contratto, test mirati, verifica d'integrazione, controlli di sicurezza e policy, e infine prova di comportamento osservabile dove ha senso. Automatizza i giudizi deterministici: se una validazione può essere espressa come regola, test o controllo, non lasciarla alla review umana. La review umana deve invece concentrarsi su intenti ambigui, trade-off, responsabilità e autorizzazioni ad alto impatto. Il gate umano deve produrre una decisione responsabile, non compensare test mancanti. Per renderlo efficace, non presentare un flusso di azioni dell'agente: prepara un pacchetto decisionale sintetico con cosa è cambiato, quali controlli sono passati, cosa resta incerto e qual è la conseguenza dell'approvazione. Così la review resta una decisione, non un audit disordinato. • Distingui esecuzione completata, controlli superati, risultato corretto e cambiamento autorizzato. • Definisci le evidenze prima dell'esecuzione. • Usa test deterministici per giudizi ripetibili. • Riserva il gate umano a intenti, ambiguità, responsabilità e rischio. • Presenta alla review un pacchetto decisionale, non il log completo dell'agente.
trade-offs
I trade-off da rendere espliciti
Più velocità di generazione non significa automaticamente più velocità di delivery. Se aumenti l'automazione senza rafforzare la verifica, ottieni più output, ma anche più rework, più eccezioni e più rischio operativo. La verifica molto rigorosa riduce i falsi positivi e aumenta la fiducia, ma ha un costo: più test, più pipeline, più tempo di feedback e più strumenti da mantenere. Una verifica troppo leggera è l'opposto: sembra efficiente nel breve periodo, ma sposta il costo su incidenti, review interminabili e perdita di credibilità del team. Il trade-off corretto dipende dal tipo di cambiamento. Le attività reversibili e a basso impatto possono passare con controlli automatizzati e una review rapida. Le modifiche che toccano dati, sicurezza, compliance o comportamento visibile al cliente richiedono evidenze più forti e spesso un gate umano esplicito. In altre parole: automatizza la certezza, non l'assunzione di correttezza. • Più automazione senza verifica crea più rework, non più valore. • Verifica forte aumenta fiducia ma ha costo di tempo e manutenzione. • Il livello di gate deve seguire il rischio, non l'entusiasmo per l'AI.
enterprise-example
Esempio in un contesto enterprise
Immagina una banca che usa agenti per preparare modifiche a regole di scoring e messaggistica applicativa. L'agente genera il codice, aggiorna la configurazione e apre la pull request in pochi minuti. A prima vista il flusso sembra efficiente, ma il collo di bottiglia non è la produzione dell'artefatto: è la verifica che il nuovo comportamento rispetti soglie di rischio, tracciabilità ai fini di audit e compatibilità con i sistemi a valle. Qui un approccio maturo separa tre livelli. Il primo è meccanico: test di contratto, validazione dello schema, controlli statici e regressione focalizzata. Il secondo è di comportamento: simulazioni con dati rappresentativi e verifica che gli output rispettino le regole attese. Il terzo è decisionale: un architect o un responsabile di dominio autorizza il cambiamento solo dopo aver visto le evidenze minime. Il suo giudizio non sostituisce i controlli mancanti, ma valuta intento, rischio e responsabilità residua. Se questo non avviene, il team finisce per trattare ogni PR come un caso speciale, con review lunghe e poco affidabili. Se invece il framework di verifica è chiaro, l'agente accelera davvero il delivery perché riduce il tempo di produzione e non aumenta l'incertezza della decisione finale. • Una banca può generare rapidamente modifiche, ma verificare correttamente è il vero vincolo. • Separare verifica meccanica, comportamentale e decisionale riduce rework. • Senza evidenze minime, la review diventa lenta e poco credibile.
references
Per approfondire
Fonti autorevoli per approfondire l'impatto dell'AI sulla verifica e il valore dei controlli automatizzati nel delivery software. • Balancing AI tensions — DORA — https://dora.dev/insights/balancing-ai-tensions/ • Software Engineering at Google — Titus Winters, Tom Manshreck, Hyrum Wright — https://abseil.io/resources/swe-book
Da ricordare
In un flusso agentico la velocità utile non la fa l'esecuzione, ma la verifica: automatizza le prove deterministiche e usa il giudizio umano solo dove servono intenti, responsabilità e trade-off.
Per la prossima riunione
Quale parte della verifica dei cambiamenti agentici richiede davvero giudizio umano e quale dovrebbe diventare un controllo deterministico?
Una domanda per te