Il rapporto esiste. La stanza no.

Di recente, un agente basato sull’intelligenza artificiale ha inserito sei voci sulla nostra bacheca retrò.

Il primo recitava: “Verifichi prima di agire — gli errori di esecuzione degli agenti rappresentano il 38% degli attriti (il doppio rispetto alla causa successiva); il costo ricorrente consiste nell’affermare una causa, nell’effettuare un push o nel reindirizzare prima di verificare il codice in produzione, i dati o lo stato del ramo.” A sostegno di ciò vi erano le prove del modello: errori relativi allo stato dei rami in Git durante il lavoro con agenti concorrenti in otto sessioni e due repository; controlli parziali pre-push che hanno interrotto la CI in quattro sessioni, due volte in un unico repository nello stesso giorno; una lacuna nel mocking dei test che una sessione aveva segnalato il giorno prima, con la nota che la documentazione relativa alla correzione non è mai stata redatta.

Ci sono due aspetti di quella bacheca che meritano particolare attenzione. Innanzitutto, nessuna singola sessione di lavoro avrebbe classificato nessuno di questi elementi come il problema principale: ogni singolo caso era una scrollata di spalle, qualche minuto perso, un fastidio che qualcuno aveva aggirato. La classifica esiste solo in forma aggregata, considerando tutte le sessioni e tutte le persone. In secondo luogo, e questo è ancora più scomodo: le voci più preoccupanti non riguardavano affatto l’agente o il codice. Riguardavano noi — correzioni che avevamo concordato di apportare ma che non avevamo adottato, lo stesso stallo che si ripeteva senza che «fosse stata implementata alcuna correzione definitiva nel frattempo».

Un report automatizzato può fornirvi tutte queste informazioni. Ciò che non può fare, però, è riunire i responsabili del processo, della documentazione, del budget destinato agli strumenti e delle priorità affinché si siedano attorno a un tavolo e decidano come agire al riguardo. Il report esiste. La riunione, invece, no. Il presente documento riguarda proprio questa riunione.

Tutti hanno contribuito alla realizzazione del circuito

Entro la metà del 2026, «individuare ciò che non ha funzionato nel lavoro assistito dall’IA e fornire un feedback in merito» sarà una pratica consolidata. Esiste sotto almeno sei denominazioni diverse, tutte valide. Il Feedback Flywheel di Rahul Garg trasforma gli attriti emersi durante le sessioni in documenti di riferimento e linee guida. Il Compound Engineering di Every fa sì che ogni unità di lavoro istruisca quella successiva. Thoughtworks dota gli agenti di sensori; Addy Osmani definisce questa disciplina Loop Engineering. I fornitori di piattaforme chiudono il ciclo su scala di flotta: la memoria “dreaming” di OpenAI, la curatela del contesto di Anthropic e l’archiviazione automatica dei ticket di Factory Signals. L’open source di GitHub gh-aw, un framework per flussi di lavoro agentici scritto in Markdown in linguaggio naturale, si avvicina maggiormente al nostro argomento: i suoi flussi di lavoro basati sulle intuizioni delle sessioni generano già report automatizzati di analisi delle sessioni. Un esempio pubblico, l’analisi automatizzata di 50 sessioni in un solo giorno, segnala un tasso di salto del 24% e un tasso di successo dell’esecutore del 33% come «segnali di fallimento».

Se utilizzate uno qualsiasi di questi elementi, continuate a utilizzarli. Il presente documento non propone di sostituirne alcuno. Tuttavia, ordinate i cicli in base al livello a cui vengono eseguiti e osservate lo schema:

Il manuale operativo di un professionista. La configurazione di una sessione. La memoria di una piattaforma. Uno stack di osservabilità. Il parco macchine di un fornitore.

Quasi ogni ciclo sul campo è un ciclo individuale: una persona e il proprio agente, oppure un fornitore e la propria flotta. Il “flywheel” di Garg è l’unico modello che punta agli artefatti condivisi dal team, e il suo elenco di cadenza include una voce che quasi nessuno ha mai messo in pratica: «Durante la retrospettiva: un punto all’ordine del giorno della retrospettiva di sprint in corso: cosa ha funzionato con l’IA in questo sprint?» Indica il contesto e passa oltre. Il dogfooding di GitHub, nel frattempo, produce esattamente il rapporto sulle frizioni che una cerimonia di team vorrebbe come input, e lo posiziona come osservabilità ingegneristica, punto e basta.

L’esempio che più si avvicina a un’eccezione proviene da Scrum.org, la cui serie dedicata ai team ibridi include Come condurre la retrospettiva di sprint quando metà del proprio team è composto da agenti di intelligenza artificiale. Vale la pena leggerlo, poiché affronta con serietà la questione della sede e offre una risposta diversa dalla nostra: la loro retrospettiva si trasforma in una sessione di debug basata sui dati relativi alle metriche degli agenti (frequenza di riscrittura dei prompt, tassi di deviazione, consumo di token). Si tratta di una prospettiva utile, e un team potrebbe adottare entrambe le soluzioni. Tuttavia, essa esamina gli agenti; il ciclo di cui tratta il presente articolo esamina invece la collaborazione: le cause piuttosto che i sintomi, con le correzioni indirizzate al livello a cui appartengono (il brief, la documentazione, il processo, il materiale), mentre gli agenti contribuiscono con la propria descrizione del lavoro anziché apparire come un semplice dashboard.

Il divario non riguarda la tecnologia. Ogni componente (acquisizione, aggregazione, reportistica) è già disponibile oggi. Il divario riguarda la pratica: quasi nessuno ha spiegato cosa fa il team, nel suo insieme, quando arriva il report.

A cosa serve effettivamente una stanza?

L’istinto in questo caso è quello di automatizzare ulteriormente: un raggruppamento più efficace, correzioni applicate automaticamente, una dashboard. Per un’ampia categoria di risultati ciò è corretto, e le pipeline sopra descritte lo fanno bene. Tuttavia, elenchi le decisioni che il rapporto effettivamente solleva e ne osservi la struttura:

• Mantenere o eliminare. Quale attrito ricorrente costituisce uno spreco e quale invece un controllo deliberato? Il punto di controllo che rallenta l’agente potrebbe essere il “guinzaglio” che qualcuno ha scelto (una sintesi dell’intervento di Armin Ronacher all’AIE Europe: «l’attrito è ciò che è necessario… per guidare»); Il Radar di Thoughtworks mette ora in guardia dal debito cognitivo derivante dall’eliminazione eccessiva. L’eliminazione di un punto di controllo modifica il rischio per tutti. Si tratta, per definizione, di una decisione di squadra.
• Dove viene risolto il problema. Un modello ricorrente di attrito viene risolto a un certo livello: una nota personale, un suggerimento o una competenza, la configurazione dell’ambiente, la documentazione, il materiale di lavoro stesso, il processo o a monte con un fornitore. Tali elementi hanno dei responsabili, e i responsabili sono persone diverse.
• Priorità nell’ambito dell’aggregazione. Cinque minuti trascurati a testa per ogni sessione passano inosservati a livello individuale, ma rappresentano un costo significativo per il team nel suo complesso. Intervenire in merito (riscrivere il modello condiviso, modificare il processo di acquisizione, segnalare il problema al fornitore) richiede un livello decisionale che nessun singolo individuo possiede.
• Il controllo di adozione. La correzione apportata nel ciclo precedente è stata effettivamente adottata e l’attrito è cessato? La frase più significativa del nostro consiglio di amministrazione è stata proprio questa: segnalata ieri, mai implementata. Un ciclo senza questo controllo è come un volano che gira a vuoto.

Nessuna di queste operazioni è un calcolo. Si tratta in tutti i casi di negoziazioni tra persone che detengono il controllo su diversi aspetti del funzionamento del team. I professionisti che operano in autonomia integrano legittimamente queste decisioni in base al proprio intuito; le pipeline di Fleet generano legittimamente il sottoinsieme leggibile dalla macchina alla velocità della macchina. Le versioni su scala di team richiedono la presenza di persone in una stessa stanza, dotate di un vocabolario condiviso e dell’autorità necessaria per riorientare l’attenzione. Quella non è una pipeline. È una cerimonia.

Perché il rituale tradizionale — o una cerimonia di natura equivalente

Per completezza di informazione, prima di addentrarci nell’argomentazione: noi vendiamo software retrospettivo. È proprio per questo motivo che la presente sezione si basa sulle caratteristiche del prodotto piuttosto che sul marchio: vi invitiamo a valutare la nostra conclusione tenendo conto di questo aspetto e a verificare voi stessi tali caratteristiche.

Le caratteristiche che il gruppo decisionale deve possedere: un contesto ricorrente (un attrito minore e cronico non dà mai luogo a una riunione episodica), privo di attribuzione di colpa per norma, inter-responsabile (devono essere presenti i responsabili dei processi, della documentazione, degli strumenti e delle priorità) e basata su dati concreti. Per la maggior parte dei team, la retrospettiva di sprint è il contesto in cui queste quattro caratteristiche sono già presenti: non occorre difendere una nuova riunione nella «guerra dei calendari», e vige una convenzione di assenza di colpe che è più importante di quanto sembri, poiché la modalità di fallimento più allettante in questo contesto è il post mortem incentrato sulla colpa dell’agente, e la scuola di ingegneria dell’harness rifiuta esplicitamente tale impostazione predefinita: l’ingegnere attribuisce la colpa al modello e la archivia sotto la voce «attendere la prossima versione»; si corregga invece l’harness (Osmani, Agent Harness Engineering).

Tuttavia, la formulazione più corretta di tale affermazione consiste nel valutare i concorrenti piuttosto che proclamare un vincitore:

• La pianificazione dello sprint detiene la massima autorità nella riunione, ma il suo ordine del giorno è orientato al futuro e costantemente fitto di impegni; lo spazio dedicato alla valutazione retrospettiva in una sessione di pianificazione è inevitabilmente insufficiente. La pianificazione è il momento in cui le azioni concordate vengono programmate, non quello in cui si analizzano i modelli.
• Il post mortem “innocente” si basa su norme assolutamente corrette, ma su un criterio di attivazione errato: viene convocato in occasione di un grave fallimento episodico, mai per il modello “cinque minuti per otto persone a ogni sprint”, che è proprio il modello che solo l’aggregazione è in grado di individuare.
• Asincrono — un report e uno strumento di monitoraggio rappresenta la soluzione più economica e, per la maggior parte delle voci di routine, è sufficiente. Ciò che non è in grado di fare riguarda il processo decisionale: la scelta tra “mantenere o eliminare” è oggetto di negoziazione, le controversie di livello superano i confini di responsabilità e la ridefinizione delle priorità richiede che i responsabili partecipino alla stessa conversazione.
• L’alternativa “null” — limitarsi a parlare di IA in modo retrospettivo, senza registrazioni né etichette — è gratuita, si adatta alla situazione attuale e, per un piccolo team con un utilizzo limitato degli agenti, potrebbe davvero essere sufficiente. Iniziate da lì. Ciò che non è in grado di garantire è la comparabilità tra le sessioni, l’individuazione delle tendenze o la verifica dell’adozione: si tratta infatti di una conversazione che riparte da zero ogni volta. La procedura descritta di seguito è quella da adottare quando tale conversazione continua a ripetersi.

Quindi, per dirla senza giri di parole: il “retro” — ovvero la vostra attuale cerimonia di forma equivalente. La revisione mensile della campagna da parte del team media e la revisione di triage da parte del team di supporto sono la stessa procedura con nomi diversi, e nulla in questa pratica presuppone l’uso del codice: il registro delle difficoltà di un account pubblicitario intricato o di una libreria di modelli incoerente si presenta esattamente come il registro delle difficoltà di un repository legacy.

L’agente presente nella stanza — partecipante, mai facilitatore

Se le prove provengono dagli agenti, l’agente dovrebbe occuparsi del caso? No, e non principalmente per il motivo che si potrebbe immaginare.

Il motivo per cui ciò si verifica: i modelli odierni sono inaffidabili proprio in questo tipo di valutazione: i verdetti dei modelli di linguaggio di grandi dimensioni (LLM) variano a fronte di input identici ~13,6% delle volte, e in uno studio condotto in ambiente di produzione della durata di otto settimane ~70% dei guasti silenziosi degli agenti è stato individuato per primo da una persona, non dai test o dal monitoraggio. Questo è vero oggi; i modelli migliorano.

Il motivo per cui ciò non viene meno: la facilitazione e la decisione assegnano l’attenzione di un team e modificano gli artefatti di cui il team è responsabile e per i quali risponde. Tale autorità non si trasferisce al modello più competente presente nella sala, così come non si trasferisce all’ingegnere più competente presente nella sala. Si tratta di un dato organizzativo, non di un divario di competenze.

Pertanto, l’agente partecipa proprio come farebbe il collaboratore meglio informato. Fornisce prove: i propri registri di sessione, etichettati e con indicazione dei costi. Risponde alle domande: alla domanda «Cosa ha effettivamente provato prima di ricorrere alla soluzione alternativa?» offre una risposta supportata dalla trascrizione. Elabora bozze, ma non decide mai: le soluzioni proposte vengono presentate con livelli di priorità suggeriti; il gruppo le modifica, ridefinisce le priorità o le scarta. Inoltre, ripristina le azioni approvate (la modifica al documento, la modifica alla configurazione), eseguendole dopo la cerimonia nel corso della normale revisione. La pratica di ricerca ha un nome per questa divisione: nel framework ACE l’agente è il Riflettore e un Curatore consolida ciò che entra nel playbook. Apportiamo un unico adattamento deliberato: in ACE il curatore è una componente deterministica; qui i curatori sono il team.

Un’asimmetria riguarda il carico di lavoro. Tutto ciò che l’agente introduce all’interno della stanza dovrebbe essere privo di restrizioni: un agente che necessita di autorizzazione per segnalare un attrito tende a sottostimare il problema. Tutto ciò che esce dalla stanza verso ciò su cui gli agenti fanno affidamento in seguito (memoria, file di contesto, configurazione) viene sottoposto a una revisione ordinaria, poiché quel percorso di scrittura costituisce una superficie riconosciuta di avvelenamento e deriva (OWASP Agentic Top 10, ASI06). La procedura si colloca esattamente su tale confine: prove in entrata non soggette a restrizioni, scritture in uscita soggette a restrizioni.

I quindici minuti

Ciò che proponiamo effettivamente a un team di provare, in questo sprint, con ogni ciclo che viene già eseguito senza modifiche:

1. Per ogni sessione, l’agente redige una breve nota retrospettiva sul proprio lavoro: cosa è andato bene, ogni punto di attrito con l’indicazione della causa principale e il relativo costo, una proposta di soluzione sotto forma di ticket e il livello a cui è destinata. La nota viene inserita insieme al lavoro, senza restrizioni.
2. Prima della riunione retrospettiva, i contributi raccolti dall’ultima volta vengono sintetizzati in un documento di una pagina: temi ricorrenti e loro prevalenza, quale gruppo di cause alla radice prevale, se le soluzioni proposte in precedenza sono state adottate, le tre azioni principali raccomandate. Il documento alimenta la discussione, ma non la sostituisce.
3. Nella sessione retrospettiva (un punto all’ordine del giorno, non una nuova riunione): quindici minuti dedicati a «cosa ha funzionato con l’IA in questo ciclo e cosa ha continuato a creare problemi?». Gli umani effettuano una selezione: mantenere o eliminare, confermare o riorientare le priorità, assegnare i responsabili alle prime tre.
4. Nel ciclo successivo, il controllo di adozione previsto dal brief verifica se l’attrito sia effettivamente diminuito. È proprio quel controllo a trasformare il rapporto in un ciclo vizioso — ed è anche il punto in cui il nostro consiglio di amministrazione ci ha colti in fallo.

Modalità di fallimento, denominate in modo tale da consentirvi di prevenirle: retro theatre (la cerimonia che si svolge per il pubblico: breve lettura, cenni di assenso, nessuna decisione presa; la regola dei “top-3-with-owners” esiste proprio per questo); colpa dell’agente (considerare «l’agente ha commesso un errore» come la spiegazione anziché come il residuo; la maggior parte dei fallimenti è riconducibile all’harness e agli input, non al ragionamento del modello); espansione della lista dei desideri (venti azioni, nessun responsabile); e il ciclo che non si chiude mai (il vuoto nel seguito: le correzioni vengono apportate, ma nessuno verifica l’andamento). Abbiamo redatto un’intera guida pratica su come falliscono le cerimonie; ogni modalità in essa descritta si applica anche in questo caso.

Ciò che non stiamo affermando

Non sostituisce alcun ciclo di lavoro dei fornitori: i loro risultati costituiscono gli input di questa cerimonia. Non si tratta di una nuova riunione. Non è una cerimonia gestita dall’intelligenza artificiale; da parte di un’azienda il cui prodotto sono le retrospettive, questa linea di demarcazione è voluta. Non è necessaria per chi opera in proprio, i cui cicli si chiudono bene in base all’intuito. E l’obiettivo non è l’assenza totale di attrito: un certo grado di attrito funge da superficie di controllo, e il punto all’ordine del giorno esiste per scegliere, non per eliminare a prima vista.

Cosa potrebbe farci cambiare idea?

Si tratta di un documento di discussione, pertanto ecco la parte falsificabile. Se i cicli dei fornitori generano un vero e proprio processo di valutazione trasversale tra strumenti e persone, e non si limitano a semplici registrazioni in memoria a livello di flotta, il ruolo si riduce a una funzione di audit. Se i team che utilizzano la versione asincrona basata esclusivamente sul brief mostrano lo stesso andamento di riduzione dell’attrito dei team che seguono il punto all’ordine del giorno, quei quindici minuti saranno pura messinscena e lo diremo chiaramente. Inoltre, la nostra affermazione relativa al vocabolario etichettato si basa su un esperimento di affidabilità inter-valutatore che stiamo attualmente conducendo su voci reali, piuttosto che su un’affermazione anticipata. Preferiamo pubblicare i dati piuttosto che il livello di confidenza.

Se il vostro team mette in pratica una qualsiasi versione di questa iniziativa (il punto all’ordine del giorno, il briefing asincrono o una cerimonia a cui non abbiamo pensato), vorremmo sapere come è andata: ai-discussion@teamretro.com.

---

Capitolo successivo: Come condurre una retrospettiva collaborativa sull’IA — la guida per il facilitatore sui quindici minuti: il modello, il formato di inserimento dei dati e le schede con le domande guida. Parte della Guida alle retrospettive sugli agenti IA.