Agenti AI: servono piani di rollback

Gli agenti di AI coding non sono più soltanto una demo da mostrare in retrospettiva. Aprono pull request, aggiornano test, rifattorizzano moduli, modificano configurazioni e propongono cambiamenti a una velocità che spesso supera la capacità del team di discutere bene l’intento. Questa velocità è utile, ma rende visibile una fragilità organizzativa: molte aziende trattano la code review come se fosse controllo del rilascio.

Non basta. La tesi è questa: gli agenti di AI coding hanno bisogno di un contratto leggero di release control con nota di rollback, owner, percorso di review, superficie impattata e condizione di stop, perché la sola review crea safety theater quando nessuno ha definito come annullare il cambiamento, chi risponde dell’esito, qual è il blast radius e quando l’agente deve fermarsi.

Non è un argomento contro gli agenti. È un argomento contro l’illusione che una diff pulita equivalga a un cambiamento sicuro. Le best practice di OpenAI per Codex insistono su istruzioni riusabili di repository, test, linting, review e permessi controllati tramite strumenti come AGENTS.md, approval mode e sandboxing. Sono basi importanti, ma il lavoro che arriva in produzione richiede anche un percorso esplicito di rilascio, non solo un prompt migliore o una patch più elegante. La base operativa è descritta nelle best practice ufficiali di OpenAI Codex.

La code review non è controllo del rilascio

La code review risponde a domande essenziali: l’implementazione rispetta la richiesta, la diff è leggibile, ci sono bug evidenti, i test coprono il comportamento previsto, le convenzioni del team sono rispettate? Con codice generato da agenti queste domande pesano ancora di più, perché l’agente può produrre codice plausibile mentre ignora un vincolo di prodotto, una dipendenza operativa o un caso limite di migrazione.

Ma la review, da sola, raramente risponde alle domande di rilascio. Quale superficie di produzione cambia se questa pull request viene fusa? Quale journey cliente può rompersi? Quale dashboard va osservata dopo il deploy? Chi può fare rollback? Quale segnale concreto impone di fermare il rollout? Se queste domande mancano, il team si affida all’attenzione umana nel momento peggiore, quando la diff esiste già e l’inerzia spinge verso il merge.

È lo stesso schema che si vede in molte discussioni sui workflow AI: la fiducia cresce perché l’artefatto sembra completo, non perché il sistema operativo attorno all’artefatto sia completo. Ne ho parlato in AI confidence theater: servono workflow che reggono. Nel caso dell’AI coding, l’artefatto è un branch, una pull request o una patch. Il controllo mancante è il contratto che chiarisce cosa succede dopo il lavoro dell’agente.

Il rischio non è solo tecnico. I product leader possono farsi ingannare dalla velocità. Gli engineering leader possono farsi rassicurare da test verdi. I security leader possono pensare che una review umana basti. Il progetto OWASP Gen AI Security inquadra i sistemi GenAI e agentici come una superficie di sicurezza applicativa più ampia, con rischi legati a workflow agentici, esposizione dei dati e governance, non solo al comportamento del modello. Questo è rilevante perché un agente di coding non genera soltanto testo. Sta entrando nella software supply chain. Il riferimento è il lavoro dell’OWASP Gen AI Security Project.

Cosa deve contenere un piano di rollback per agenti?

Un piano di rollback per un task affidato a un agente deve essere abbastanza piccolo da essere scritto prima che il lavoro inizi. Se diventa un registro rischi, nessuno lo userà. La versione utile è un contratto di release control collegato al task o alla pull request.

Si parte dall’obiettivo del task. Basta una frase: cambiare il copy del banner prezzi, aggiungere una regola di validazione, rifattorizzare il job di export, aggiornare il timeout di un’integrazione. Poi servono i criteri di accettazione. Questo si collega direttamente al principio discusso in AI coding: prima i criteri di accettazione: se l’agente non sa cosa significa done, la review diventa gusto personale e il debugging diventa archeologia.

Poi va definita la superficie impattata. Indicare i file può essere utile, ma non basta. Bisogna nominare area prodotto, flusso utente, endpoint API, job schedulato, tabella dati, confine di permesso o workflow admin che può essere toccato. Qui molti task agentici diventano rischiosi. Una piccola diff in un helper condiviso, in un wrapper analytics, in un middleware di autenticazione o in un calcolo di billing può avere un blast radius molto più ampio di una modifica lunga dentro un componente isolato.

A quel punto serve la nota di rollback. Non deve essere un playbook di incident response. Deve rispondere a una domanda semplice: si torna indietro revertendo la pull request, disabilitando una feature flag, ripristinando una configurazione, annullando una migrazione o eseguendo uno script compensativo? Se la risposta non è chiara, il task non è pronto per un’esecuzione autonoma o semi-autonoma.

Serve poi un owner. Non l’agente. Non un reviewer generico. Una persona o un team deve essere responsabile dell’esito del rilascio. L’owner non deve eseguire ogni passaggio, ma deve sapere di essere responsabile della decisione: spedire, fermare o annullare.

Il percorso di review deve seguire il rischio. Alcune modifiche richiedono solo review tecnica ordinaria. Altre richiedono review prodotto perché cambiano il comportamento. Altre richiedono review security perché toccano permessi, segreti, chiamate esterne o dati utente. Altre ancora richiedono review dati perché modificano eventi, metriche o logica di attribution. Le linee guida NCSC sullo sviluppo sicuro di sistemi AI insistono sulla gestione della sicurezza lungo il ciclo di vita, inclusa la gestione del debito tecnico e dei rischi futuri. È un promemoria utile: la review deve seguire la natura del rischio, non la comodità della coda pull request. Il riferimento è la guida NCSC su secure AI system development.

Infine serve la condizione di stop. È un trigger scritto in linguaggio semplice che dice all’agente o al team quando fermarsi. Esempi: fermati se il task richiede modifiche di schema non previste nel brief; fermati se i test costringono a cambiare comportamenti non correlati; fermati se la superficie include autenticazione; fermati se l’agente non riesce a eseguire il comando di validazione; fermati se due tentativi producono architetture diverse. Non è burocrazia. È il modo per impedire che l’ambiguità diventi rischio di produzione.

Dove deve intervenire il product leader

Un product leader non deve leggere ogni riga di codice generata dall’AI. Deve però assicurarsi che l’organizzazione abbia una definizione sensata di delivery controllato.

Il primo punto di intervento è l’ingresso del task. Prima che un lavoro arrivi all’agente, devono esistere i campi che rendono possibile il controllo: obiettivo, criteri di accettazione, superficie impattata, nota di rollback, owner, percorso di review e condizione di stop. Può vivere in Linear, Jira, GitHub issue, template di pull request o in un form interno per task agentici. Il formato conta meno dell’abitudine.

Il secondo punto è il livello di autonomia. Una modifica di copy dietro feature flag può avere un percorso diverso da una modifica all’integrazione pagamenti. Una rifattorizzazione in un modulo interno ben coperto da test può avere un percorso diverso da una migrazione su dati cliente. Il punto non è escludere gli agenti dal lavoro serio. Il punto è smettere di trattare ogni task come se avesse lo stesso rischio di rilascio. Qui torna utile AI coding governabile con model routing: la governance migliora quando il lavoro viene instradato per contesto, rischio e controllo richiesto, non per entusiasmo verso un modello.

Il terzo punto è il linguaggio. Sostituire richieste vaghe di review con domande operative. Non chiedere solo: qualcuno ha guardato la diff? Chiedere: cosa possiamo rollbackare, chi decide, quale superficie cliente può rompersi e quale segnale ferma il rollout? Queste domande spostano la conversazione dall’approvazione al controllo.

Il contratto deve restare abbastanza piccolo da essere usato

Il contratto di release control deve stare in un template breve:

Obiettivo del task: cosa deve cambiare? Criteri di accettazione: come sappiamo che funziona? Superficie impattata: quali aree prodotto, sistema, dati o clienti possono essere toccate? Nota di rollback: come annulliamo o disabilitiamo il cambiamento? Owner: chi risponde dell’esito del rilascio? Percorso di review: chi deve vedere il cambiamento prima del merge o del rilascio? Condizione di stop: quando agente o team devono fermarsi?

È volutamente modesto. Non sostituisce giudizio tecnico, test, CI, security review, feature flag, observability o incident response. Offre però un punto di aggancio a tutti questi controlli. Senza un contratto, ogni controllo arriva tardi.

Gli agenti di AI coding possono accelerare il delivery. Possono anche accelerare lavoro poco chiaro. La differenza non dipende solo dalla qualità del modello. Dipende dal fatto che il team circondi l’agente con un contratto pratico su intento, review, rilascio e reversibilità.

Se il tuo team sta introducendo agenti di coding in produzione, fai audit di una modifica recente assistita da AI. Riesci a identificare owner, superficie impattata, percorso di rollback, review path e condizione di stop senza intervistare tre persone? Se la risposta è no, il problema non è solo la qualità dell’agente. Manca un controllo nel sistema di delivery.