Eventi25/6/2026

Come si organizza un team quando metà dei suoi membri sono agenti AI?

Articolo a cura di

Alberto Marsanasco

Chief Innovation Officer

Lo scorso sabato abbiamo organizzato il primo hackathon interno della storia di adesso.it. Amerigo Leo, Software Architect, e Alberto Meleleo, leader di uno dei centri di competenza dello sviluppo software, hanno organizzato l’agenda, definito le sfide e i criteri di valutazione. Nella giuria erano presenti, oltre a loro, anche referenti del leadership team aziendale, che hanno sponsorizzato l’iniziativa senza entrare nelle decisioni organizzative, proteggendone l’autenticità.

Una traccia era orientata al “make AI”, costruire applicazioni con AI a bordo come funzionalità del sistema. L’altra era orientata allo “use AI”, utilizzare l’AI per sviluppare nuove soluzioni rapidamente e con maggiore qualità. Questa seconda traccia era applicata a un caso reale: la realizzazione di soluzioni digitali per uno dei punti di riferimento del terzo settore a Milano, la Fondazione Centro Francescano Maria della Passione, più comunemente nota come la mensa dei poveri di Via Ponzio.

Oltre alla qualità tecnica dei workflow agentici, uno dei criteri di valutazione era l’efficacia delle modalità di collaborazione trovate all’interno dei team. I team erano composti da tre a cinque persone, con profili eterogenei: alcuni più specializzati sullo sviluppo software, altri sull’analisi o sulla gestione progettuale. Come ci si organizza all’interno di team agentici è infatti oggi una delle sfide più grandi, ci sono diversi studi ma non esiste ancora letteratura di riferimento solida al riguardo.

Abbiamo fatto diverse scoperte a proposito:

Un pattern emergente forte è stato il supporto degli agenti AI non solo per lo sviluppo, ma anche per la pianificazione stessa del lavoro. Quasi tutti i team hanno aperto con una fase di esplorazione/allineamento collettivo prima di parallelizzare task di lavoro di implementazione, che potevano essere generati e assegnati ai diversi ruoli del team, anche grazie al supporto dell’AI stessa. La differenza che ha avvantaggiato alcuni team è stata la percentuale e la tipologia di attività fatte insieme rispetto a quelle parallelizzate.
Per la gestione e la condivisione della conoscenza, sia quella data in partenza che quella costruita in corso d’opera, sono stati utilizzati diversi approcci: LLM wiki condivise nel repository comune, che tutti possono interrogare e aggiornare, mantenendo allineamento durante il lavoro parallelo. Oppure tramite la creazione di skill di memory condivise per garantire continuità e consistenza delle informazioni durante il corso del tempo.

La gestione del costo dei token è entrata nel design del workflow, non solo come vincolo tecnico. Alcuni team hanno differenziato i modelli per i diversi task (modelli avanzati per le fasi di analisi e definizione dei piani di azione, modelli più semplici per implementazione meccanica e code review), introducendo plugin specifici per le attività di assessment del codice.
Alcuni dei team hanno lavorato da remoto, e questo ci ha permesso di trarre considerazioni sulle differenze tra team remoti e team in presenza. I team in presenza hanno potuto coordinare meglio le attività, sia quelle da fare insieme, in particolare quelle di esplorazione e design, sia quelle da parallelizzare, organizzando momenti di sync ogni mezzora. Nonostante questo, uno dei team vincitori della giornata è stato un team remoto, a suggerire che la presenza non sia una delle variabili con maggiore impatto sui risultati.

Oltre alle scoperte di metodo, uno dei risultati più belli è stata l’energia che l’evento ha sprigionato, insieme alla voglia di sperimentare ancora. Queste occasioni ci permettono di diventare quello vogliamo essere: un’azienda di persone appassionate, con competenze sempre allo stato dell’arte, che sanno fare software engineering di alta qualità, che vogliono lavorare insieme per moltiplicare l’impatto del proprio lavoro e raggiungere obiettivi sempre nuovi.