Più agenti nello stesso progetto
Immaginiamo di affidare a quattro assistenti di intelligenza artificiale altrettante attività dello stesso progetto.
Uno prepara una modifica al programma, un altro esegue le prove, il terzo aggiorna la documentazione e il quarto esamina le possibili conseguenze della modifica.
Dopo qualche ora arrivano quattro risultati, ciascuno plausibile.
Bisogna capire se le prove riguardano la versione effettivamente consegnata, se la documentazione descrive il comportamento finale e se chi ha esaminato i rischi conosce le decisioni prese durante lo sviluppo.
L’esempio nasce dal lavoro sul software, ma il problema si presenta anche in altri contesti similari.
Possiamo chiedere a più sistemi di analizzare documenti, confrontare procedure, preparare bozze o classificare richieste. E poi decidere che cosa usare. Ma dobbiamo capire se poi quei risultati si riferiscono allo stesso problema.
Se questa ricostruzione arriva soltanto alla fine, il tempo guadagnato nell’esecuzione può essere speso a risolvere incoerenze che abbiamo creato distribuendo male il lavoro.
La prima scelta riguarda il modo in cui formuliamo gli incarichi. L’espressione «Esamina il processo» è vaga, non specificando cosa osservare o quale risultato ottenere.
Al contrario, «Individua le richieste che richiedono un’approvazione esterna, indica il punto in cui si interrompono e cita il documento da cui ricavi ogni regola» definisce chiaramente un’attività verificabile.
Chi riceve il risultato può confrontare ogni regola con la fonte citata, individuare le richieste trascurate e capire dove è necessaria una decisione umana.
Anche una descrizione accurata di un singolo compito può non bastare. Due incarichi diversi possono basarsi sulla stessa definizione. Ad esempio, se un gruppo intende per «richiesta conclusa» una pratica chiusa nel sistema, mentre un altro include anche la conferma inviata all’utente, i loro risultati non saranno comparabili.
Questo disaccordo non è necessariamente dovuto a un errore degli assistenti. Qualcuno deve stabilire il significato operativo di quel termine e comunicare la decisione a entrambi i gruppi.
La condivisione del contesto richiede quindi una regola precisa. Una decisione che cambia il lavoro di altri incarichi deve essere registrata e raggiungere chi la deve applicare. Una nota comune può contenere la definizione adottata, la data, il motivo della scelta e le attività coinvolte.
Serve anche a differenziare l’istruzione attuale da una formulazione obsoleta. Senza questa guida, ogni assistente può generare una risposta internamente coerente ma in disaccordo con le altre.
Il lavoro parallelo richiede anche confini materiali. Nello sviluppo software, ad esempio, si possono assegnare copie separate del lavoro, in modo che due attività non modifichino contemporaneamente gli stessi file.
Un principio simile si applica agli archivi documentali: la fonte originale rimane identificabile, mentre proposte e revisioni vengono archiviate in percorsi separati. Questo isolamento evita sovrascritture e consente di risalire all’origine di una modifica.
Bisogna stabilire dopo come ricomporre le diverse parti e quale versione debba prevalere quando due risultati divergono.
Assegnare ruoli diversi ha valore solo se comporta un cambiamento sostanziale nel tipo di controllo. Chi prepara una soluzione può verificarne la conformità alle istruzioni ricevute. Un secondo esame, condotto con criteri indipendenti, può individuare ciò che quelle istruzioni hanno trascurato, come eccezioni, destinatari dimenticati o costi trasferiti ad altre fasi.
Se il revisore riceve solo il resoconto ottimistico dell’esecutore, la separazione dei ruoli rimane puramente formale.
Gli servono il risultato, le fonti pertinenti e la domanda a cui la prima attività doveva rispondere. Anche due assistenti separati possono commettere lo stesso errore se usano una fonte errata o condividono un presupposto sbagliato: la differenza dei ruoli non garantisce l’indipendenza delle prove.
Occorre chiarire anche il senso del termine «finito». Un assistente può aver completato il proprio incarico, ma il progetto potrebbe essere ancora in attesa di un’approvazione, di test su dati reali o del contributo di un’altra persona.
Un pannello che mostra numerose attività completate fornisce informazioni sullo stato degli incarichi, ma offre meno indicazioni sulla possibilità di utilizzare il risultato finale.
Forse conviene distinguere ciò che è stato prodotto, ciò che è stato verificato e ciò che è stato autorizzato. Ogni passaggio richiede un soggetto riconoscibile e una prova proporzionata alle conseguenze della decisione.
Qui compare un limite meno visibile del numero di assistenti disponibili: la capacità di revisione di chi coordina. Se quattro attività consegnano nello stesso momento, il responsabile può leggere con attenzione soltanto una parte del materiale.
Può chiedere ai sistemi un controllo preliminare, ma deve sapere quale controllo sia stato eseguito e su quali elementi. Altrimenti il secondo risultato aggiunge una nuova sintesi da approvare, senza ridurre l’incertezza sul primo.
La capacità di revisione si può progettare già quando si assegnano i compiti. Un risultato breve, accompagnato dai documenti esaminati e dalle decisioni richieste, è più controllabile di un testo esteso che mescola fatti, interpretazioni e proposte.
Le prove automatiche aiutano quando esiste un comportamento atteso che può essere confrontato con l’esito. Una lettura umana resta necessaria dove occorre valutare significato, conseguenze o conflitti fra obiettivi. Il tipo di verifica dipende da ciò che il risultato potrà provocare.
Il parallelismo conviene quando gli incarichi possono procedere su basi già concordate. Se la seconda attività dipende da una scelta ancora aperta nella prima, avviarle insieme può moltiplicare le revisioni. Se invece due indagini riguardano aspetti indipendenti e convergono su criteri condivisi, l’esecuzione simultanea può ridurre il tempo complessivo. Prima di avviare un altro agente occorre quindi valutare la dipendenza fra gli incarichi e il lavoro che servirà per ricomporli.
Da qui deriva anche una cautela nell’uso della parola «squadra». La metafora aiuta a pensare alla distribuzione dei compiti, alla circolazione delle informazioni e ai controlli. Gli assistenti, però, non assumono la responsabilità organizzativa di una decisione né possono spiegare da soli perché un rischio sia accettabile per le persone coinvolte.
Chi imposta il lavoro decide quali dati mettere a disposizione, quali azioni consentire, quando fermare l’esecuzione e chi deve approvare il risultato. Attribuire a un agente il ruolo di «revisore» non assegna automaticamente queste responsabilità.
Torniamo alle quattro consegne iniziali. Per decidere se la modifica può essere usata, occorre collegare il programma alla versione provata, la documentazione al comportamento osservato e i rischi alle scelte effettivamente compiute. Se uno di questi collegamenti manca, l’attività è terminata soltanto per chi l’ha eseguita. Il lavoro è pronto per il passaggio successivo quando una persona può ricostruire le prove, comprendere gli effetti della scelta e assumersene la responsabilità.
Riferimento
Jerry PM, «How To Run Claude Like a Tech Lead, Not a Senior Engineer», CodeToDeploy, Medium, 1 settembre 2026. L’articolo ha fornito lo spunto per questa riflessione.