--- title: "Agenti AI nel team: valutare qualità, costi e responsabilità" source: "https://www.matteovincenti.com/blog/agenti-ai-team-qualita-costi-responsabilita" language: it author: "Matteo Vincenti" published: 2026-10-20 updated: 2026-10-23 category: "AI" tags: ["Agenti AI", "Team management", "Qualità software"] --- # Agenti AI nel team: valutare qualità, costi e responsabilità Come valutare gli agenti AI in azienda: qualità, costo del lavoro completo, responsabilità e condizioni per adottare, limitare o fermare un pilota. ![Una mano controlla un componente verde con un calibro, separando i pezzi non adatti](https://cdn.sanity.io/images/xrqkwry7/production/685b94fcdf5f785865ce72daed59365baa1c4f8a-1728x910.png?w=1400&fit=max&auto=format) Categoria: AI · Tag: Agenti AI, Team management, Qualità software Un agente che prepara una modifica in otto minuti può lasciare al team più lavoro di uno che ne impiega quindici. Qualcuno deve ancora leggere il codice, controllare il comportamento, correggere gli errori e decidere se integrare la modifica. Per valutare gli agenti AI in un team partirei da questo costo: quanto serve per ottenere una modifica che siamo disposti ad accettare? E quanto lavoro di verifica possiamo sostenere mentre gli agenti continuano a produrre? Qui considero agenti di sviluppo capaci di leggere un progetto, modificare file e usare strumenti come test e terminale. Il workflow comprende anche le istruzioni, i controlli automatici e il lavoro delle persone. È questo insieme che dobbiamo confrontare con il processo attuale. ## Prima di cronometrare, decidiamo cosa accettare Prendiamo un compito circoscritto: aggiungere un filtro per stato a un’API che restituisce gli ordini. L’API esiste già e viene chiamata da un’interfaccia. Vogliamo introdurre la ricerca degli ordini pagati, mantenendo il comportamento delle richieste senza filtro. Nel contratto di questo esempio gli stati ammessi sono `paid`, `pending` e `cancelled`; uno stato diverso produce un errore HTTP 400. Gli ordini sono restituiti per ID decrescente e la paginazione si applica agli ordini selezionati dal filtro. Basta un piccolo insieme di dati per rendere visibile un errore: l’ordine 42 è pagato, il 41 è in attesa, il 40 è pagato e il 39 è annullato. _Prima di cronometrare, decidiamo cosa accettare_ | Requisito | Richiesta o controllo | Risultato atteso | | --- | --- | --- | | Conservare il comportamento esistente | Nessun filtro, prima pagina di due elementi | Ordini 42 e 41 | | Filtrare prima di paginare | Stato `paid`, prima pagina di due elementi | Ordini 42 e 40 | | Gestire input non ammessi | Stato `unknown` | HTTP 400, senza ignorare il filtro | | Mantenere compatibile il chiamante | Aprire la lista dall’interfaccia esistente e usare il nuovo filtro | La lista iniziale funziona e quella filtrata mostra i risultati attesi | Se l’implementazione prende prima i due ordini più recenti e poi li filtra, restituisce soltanto il 42. Il filtro sembra funzionare, ma la pagina è incompleta: il 40 è stato escluso troppo presto. Per controllarlo serve una prova che attraversi filtro e paginazione insieme. Aggiungere un test sul solo riconoscimento di `paid` lascerebbe il problema intatto. Chiederei quindi una PR — la proposta di modifica da revisionare — accompagnata dai controlli eseguiti sulla revisione consegnata e dalla verifica del chiamante. Chi accetta il lavoro deve poter ricostruire il risultato della tabella. Un riepilogo dell’agente che dice «tutto funziona» lascia ancora quel lavoro al revisore. La distinzione ha un precedente concreto. In una valutazione METR del 2025, quattro delle quindici PR campionate superavano i test di riferimento, ma nessuna delle quindici era integrabile così com’era secondo la revisione manuale. Erano problemi in due repository maturi, affrontati con un agente basato su Claude 3.7: un risultato circoscritto, utile per capire perché il test superato non esaurisce l’accettazione. [METR, valutazione delle modifiche fino all’integrazione](https://metr.org/blog/2025-08-12-research-update-towards-reconciling-slowdown-with-time-horizons/). ## Gli otto minuti che diventano trentaquattro Confrontiamo ora due workflow. I dati del caso sono costruiti per mostrare come decidere; entrambi i workflow arrivano allo stesso risultato accettabile. _Gli otto minuti che diventano trentaquattro_ | Workflow | Preparazione della prima consegna | Verifica e correzioni successive | Durata fino all’accettazione | | --- | --- | --- | --- | | A | 8 minuti | 26 minuti | 34 minuti | | B | 15 minuti | 10 minuti | 25 minuti | Le fasi sono consecutive: qui sommiamo durate trascorse. B impiega più tempo a presentare la prima versione e arriva prima all’accettazione. Per scegliere come lavorare, però, mi manca ancora un dato: quanti di quei minuti hanno impegnato una persona? Dieci minuti di verifiche automatiche durante i quali il revisore segue altro lavoro hanno un costo diverso da dieci minuti passati a correggere una query. Se due persone intervengono per dieci minuti ciascuna nello stesso intervallo, abbiamo venti minuti di lavoro umano e dieci minuti trascorsi. Confondere le due misure rende poco leggibile il vantaggio del parallelismo. Nel conto entra anche l’attesa prima della review: una PR pronta può restare ferma perché nessuno ha tempo di leggerla. Se quella coda cresce, aumentare gli agenti sposta il collo di bottiglia verso chi deve accettarne il lavoro. ## Che cosa ci dicono davvero gli studi sulla produttività Nello studio randomizzato METR del luglio 2025, sedici sviluppatori esperti lavorarono su 246 attività dei propri progetti open source. Con gli strumenti AI dell’inizio del 2025 impiegarono il 19% di tempo in più, pur percependo un risparmio. È un buon motivo per misurare il lavoro completo anziché affidarsi alla sensazione di velocità. [METR, studio sugli sviluppatori esperti](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). Usare oggi quel 19% come previsione per qualunque team sarebbe altrettanto sbrigativo. Nell’aggiornamento del febbraio 2026, METR spiega perché i nuovi dati sono difficili da interpretare: cambia chi accetta di partecipare, quali attività vengono incluse e come si conta il tempo quando gli agenti lavorano in parallelo. Un sondaggio successivo registra invece benefici percepiti, distinguendo l’aumento di velocità dal valore del lavoro prodotto; sono autovalutazioni, non una nuova stima causale dello stesso esperimento. [Aggiornamento METR](https://metr.org/blog/2026-02-24-uplift-update/), [sondaggio METR sul valore dell’AI](https://metr.org/blog/2026-05-11-ai-usage-survey/). La domanda utile per il nostro pilota diventa: su quali attività, con quali controlli e con quanto intervento umano otteniamo un vantaggio? Il confronto ha senso dentro una famiglia riconoscibile, come le modifiche compatibili alle API esistenti. Una media che comprende anche ritocchi di testo e migrazioni nasconde differenze troppo grandi fra i lavori. ## Usare un agente anche per verificare Affidare agli agenti soltanto la scrittura del codice restringe parecchio il confronto. Possono aiutare a cercare regressioni, preparare test o controllare una modifica prima che arrivi a una persona. Salvatore Sanfilippo, antirez, descrive un uso orientato alla QA: partire dai commit successivi all’ultima release e cercare problemi di integrazione e regressioni. Mi interessa la scelta del materiale da esaminare: le modifiche introdotte nella release danno alla verifica un perimetro concreto. [antirez, agenti e software testing](https://antirez.com/news/168). Per il filtro degli ordini affiderei a un agente una domanda precisa: «La paginazione viene applicata all’insieme filtrato? Mostra il percorso della richiesta e un caso che distingua le due implementazioni». Il secondo agente riceverebbe il contratto e la revisione da controllare, senza partire dalla rassicurazione del primo. Il suo rapporto va comunque valutato. Se individua il difetto del 40 escluso dalla pagina, ci aiuta; se produce cinque allarmi infondati, qualcuno deve esaminarli. Uber affronta questo problema in uReview con passaggi di filtraggio e rimozione dei duplicati, feedback degli sviluppatori e valutazioni su difetti noti. Contare i commenti giudicati utili risponde a una domanda diversa dal contare i difetti sfuggiti. [Uber Engineering, uReview](https://www.uber.com/us/en/blog/ureview/). Prima di aggiungere quel passaggio al workflow farei una prova con una modifica che contiene il difetto di paginazione e una corretta. Chi prepara i casi conserva una scheda con l’esito atteso di ciascuno e la correzione di riferimento del caso difettoso; l’agente di review riceve il contratto e il codice candidato, senza quella scheda. Per ciascun caso confronto poi la decisione di persone che fanno review con e senza il rapporto dell’agente. Ogni persona vede una sola condizione, senza conoscere prima la risposta di riferimento. Chi ha preparato i casi può così controllare difetti trovati, allarmi infondati e tempo umano per decidere. Questa prima prova serve a scegliere se approfondire il controllo. ## Più agenti richiedono un problema da dividere Per il filtro la mia prima scelta è un agente operativo con i controlli già disponibili. Un secondo incarico ha senso se copre un rischio preciso, come l’interazione tra query e paginazione. Aprire più sessioni che riscrivono lo stesso endpoint lascia al coordinatore il compito di scegliere e ricomporre le soluzioni. La guida Anthropic distingue i workflow, nei quali il codice stabilisce i passaggi, dagli agenti che scelgono dinamicamente come procedere, e raccomanda di partire dalla soluzione più semplice adatta al compito. Prima di delegare un controllo stabile a un altro modello, valuterei se basti aggiungerlo alla suite di test. [Anthropic, Building effective agents](https://www.anthropic.com/research/building-effective-agents). Il coordinamento rientra nel costo: preparare il contesto per ciascun agente, leggere rapporti duplicati, risolvere disaccordi e verificare la modifica ricomposta sono attività del workflow. Anche una buona divisione richiede qualcuno che accetti il risultato complessivo. ## Chi può modificare, approvare e rilasciare Una promessa nel prompt non limita tecnicamente le operazioni possibili. Se l’agente deve proporre codice, gli darei gli accessi necessari a quel compito. Review, merge e rilascio devono avere responsabili riconoscibili e permessi coerenti. Una persona può ricoprire più ruoli; deve essere chiaro quale decisione sta prendendo. Su GitHub, per esempio, le protezioni dei branch possono richiedere review e controlli prima del merge; bisogna considerare anche le possibilità di bypass. Nei workflow Actions i permessi del token si possono restringere per workflow o singolo job. Sono vincoli da configurare, mentre il prompt esprime le istruzioni per lavorare entro quei vincoli. [Protezioni dei branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches), [permessi di GITHUB\_TOKEN](https://docs.github.com/en/actions/tutorials/authenticate-with-github_token). Per il nostro filtro, chi revisiona controlla il contratto e i chiamanti; chi autorizza il rilascio valuta anche l’ambiente in cui la modifica entrerà. Un agente di review può fornire un parere senza avere credenziali di produzione. ## Una scheda compilata, una decisione Il pilota parte dal processo attuale come baseline. Prima di avviarlo vanno concordati la famiglia di attività, i requisiti indispensabili, i limiti di consumo e tempo umano, il beneficio cercato e la data della decisione. Anche l’assegnazione di attività comparabili ai workflow precede i risultati: rifare lo stesso problema dopo aver letto la soluzione favorisce il secondo tentativo. Per i filtri compatibili dell’esempio, fissiamo questo obiettivo: ridurre la durata fino all’accettazione restando entro 15 minuti di lavoro umano e 1,20 euro di strumenti per modifica accettata. I quattro requisiti della tabella iniziale sono obbligatori. Una pagina sbagliata non diventa accettabile perché costa meno. Le soglie di tempo e spesa servono a decidere l’adozione, dopo aver contato il lavoro completo. Riprendiamo A, il processo attuale, e B, il candidato, completando i dati dei 34 e 25 minuti. La scheda segue una modifica per workflow fino all’accettazione; comprende tutte le consegne, le correzioni e il coordinamento necessari. Il setup iniziale del pilota va registrato a parte. _Una scheda compilata, una decisione_ | Voce | A — processo attuale | B — candidato | | --- | --- | --- | | Requisiti finali sul filtro e sul chiamante | Tutti soddisfatti | Tutti soddisfatti | | Modifiche accettate | 1 | 1 | | Durata fino all’accettazione | 34 minuti | 25 minuti | | Attesa prima della review, già inclusa nella durata | 0 minuti | 0 minuti | | Preparazione: lavoro umano | 4 minuti | 6 minuti | | Coordinamento: lavoro umano | 2 minuti | 4 minuti | | Review: lavoro umano | 5 minuti | 6 minuti | | Correzioni: lavoro umano | 3 minuti | 2 minuti | | Lavoro umano totale | 14 minuti | 18 minuti | | Spesa strumenti, incluse tutte le consegne | 0,40 euro | 1,10 euro | | Esito rispetto ai limiti concordati | Entro entrambi i budget | Supera di 3 minuti il budget umano | Mantengo A per questa famiglia. B arriva nove minuti prima, ma richiede quattro minuti umani in più; il limite era quindici. La prossima prova deve concentrarsi sulla preparazione e sul coordinamento di B: sono quei due passaggi ad assorbire il lavoro aggiuntivo. Un punteggio medio fra velocità e costo nasconderebbe la ragione della decisione. La scelta cambia se cambia il problema. Con una scadenza obbligatoria di 30 minuti, un budget umano di 20 e lo stesso limite di 1,20 euro, B rientra nei vincoli e A arriva troppo tardi. In quel caso sceglierei B per quella consegna. Per estenderlo alla famiglia servono più attività comparabili, compresi i casi meno favorevoli. La scheda si può tenere nel sistema con cui il team segue già il lavoro. In una prova reale, ai numeri vanno collegati il requisito, le revisioni iniziale e finale, le versioni di modello e strumenti, le istruzioni, i controlli eseguiti e i responsabili di accettazione e rilascio. Così un’altra persona può capire a quale lavoro appartiene il confronto. Da questi dati ricavo due indicatori separati: minuti umani per modifica accettata e spesa degli strumenti per modifica accettata. Per entrambi conto tutti i tentativi della famiglia nel periodo scelto, compresi quelli respinti o interrotti, e divido per il numero di modifiche accettate. Per un costo totale in euro, prima converto il lavoro umano con una tariffa oraria dichiarata, applicando lo stesso criterio ai due workflow; poi sommo la spesa degli strumenti. Il setup resta separato e, se ripartito, richiede una regola esplicita. Con zero accettazioni i rapporti non sono calcolabili: restano visibili i costi sostenuti e gli esiti. Fissare prima la famiglia e l’unità di lavoro evita di migliorare la media spezzando artificialmente le modifiche. Se il candidato funziona sulle modifiche compatibili ma richiede troppo controllo quando cambia un contratto pubblico, ne limiterei l’uso alle prime. Per il pilota vanno fissati anche limiti di esecuzione che interrompono un tentativo. Un’azione fuori perimetro o il raggiungimento di uno di quei limiti ferma il lavoro; una prova essenziale ancora aperta sospende l’accettazione. Anche questi esiti restano nella scheda. Alcuni casi devono restare fuori dalla messa a punto delle istruzioni: servono a vedere cosa succede su problemi non già usati per correggerle. Per la contabilità dettagliata di token, cache e tentativi rimando agli [esperimenti sul consumo di Claude e Codex](https://www.matteovincenti.com/blog/ridurre-token-claude-codex-esperimenti). Se la produzione cresce mentre la review si accumula, investirei prima nel liberare quella capacità.