> ## Content Index
> Fetch the complete content index at: https://adrianoamalfi.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# La flotta di agenti è arrivata. Il piano di controllo, ancora no.
- URL: https://adrianoamalfi.com/la-flotta-di-agenti-e-arrivata-il-piano-di-controllo-ancora-no/
- Published: 2026-10-31T18:30:44.000Z
- Updated: 2026-10-31T18:30:44.000Z
- Description: Gli agenti di coding non sono più una semplice funzione dell’IDE. Stanno diventando una forza lavoro distribuita. E il settore si sta accorgendo di aver costruito i lavoratori prima ancora di attrezzare il luogo di lavoro.
- Author: Adriano Amalfi
- Tags: Agentic AI, AI Governance, Agent Development Lifecycle

I segnali arrivati da GitHub a settembre 2026 sono difficili da ignorare: **oltre il 40% delle pull request** era partito da una prima bozza generata da un agente, contro il 17% di marzo. Nello stesso periodo, GitHub ha registrato **7,38 miliardi di commit**: più di cinque volte quelli dell’anno precedente. Lo sviluppo assistito dall’IA sta spingendo l’infrastruttura verso nuovi limiti di capacità. ([GitHub Octoverse 2026](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/?ref=adrianoamalfi.com))

Non è la storia di sviluppatori che usano un completamento automatico più furbo. È la storia di organizzazioni che si stanno ritrovando con una nuova categoria di operatori: agenti che creano branch, propongono modifiche, eseguono controlli, commentano issue, lavorano su più repository e aspettano una revisione.

Il problema non è che gli agenti stiano diventando capaci. È che molte organizzazioni non hanno ancora gli strumenti operativi per gestirli in sicurezza, su larga scala.

## Dal Copilot alla flotta

La prima generazione di strumenti di coding basati sull’IA era pensata per una singola interazione: fai una richiesta, ricevi un suggerimento, accettalo o rifiutalo.

La generazione attuale è pensata per **delegare**.

I Copilot Projects di GitHub possono coordinare agenti, file e attività ricorrenti su più repository. Copilot Automations estende questo approccio a lavori pianificati, come le revisioni del codice e la gestione delle issue. In pratica, il compito non è più soltanto «scrivi questa funzione», ma «tieni d’occhio questo backlog», «prepara questa migrazione» o «controlla che queste dipendenze siano in ordine».

A cambiare è il modo stesso di lavorare. Lo sviluppatore non si limita a esaminare il codice prodotto da un modello: deve supervisionare una flotta di processi semiautonomi, ciascuno con il proprio contesto, i propri permessi, i propri possibili errori e il proprio raggio d’impatto.

La promessa di produttività è concreta. Altrettanto concreto è il nuovo debito operativo. Per un approfondimento su come integrare questi strumenti nel ciclo di sviluppo, leggi la guida agli [agenti open source nel SDLC](https://adrianoamalfi.com/tech-scratchpad/agenti-open-source-integrazione-sdlc/).

## La revisione diventa il collo di bottiglia

Più lavoro prodotto dagli agenti non significa, di per sé, più software rilasciato. Significa più modifiche da valutare, tutte in coda davanti agli stessi sistemi di revisione umana.

La code review era già un collo di bottiglia. Con gli agenti, diventa uno dei principali punti di controllo della catena di fornitura del software.

Se il 40% delle pull request nasce da bozze generate da agenti, la domanda non è più se l’IA sappia scrivere codice. La domanda è se i team riescano a distinguere una proposta valida da una soltanto plausibile, alla stessa velocità con cui gli agenti la producono.

Il rischio è noto: si accettano più modifiche perché farlo costa poco, e il conto arriva dopo, sotto forma di incidenti, regressioni, vulnerabilità e manutenzione aggiuntiva. Se la verifica non tiene il passo, il maggiore throughput non è un vantaggio: è lavoro rimandato.

Come mostrano i dati discussi nell’articolo [Più codice non è più delivery](https://adrianoamalfi.com/), **generare più codice non basta**: il vero limite può spostarsi dalla scrittura alla revisione e alla consegna.

## Il piano di controllo che manca

Il settore ha imparato a dare strumenti agli agenti. Deve ancora imparare a fornire loro identità e permessi governati.

Un agente che può leggere un repository, chiamare servizi esterni, aprire pull request e avviare deployment non è una semplice comodità per gli sviluppatori. È un attore che opera nell’ambiente di produzione. Eppure, in molte organizzazioni, gli agenti ereditano i permessi di un account umano, le loro azioni sono difficili da attribuire e gli accessi restano attivi anche dopo la fine del compito.

Le recenti indicazioni di Atlassian sulla proliferazione degli agenti mettono in luce proprio questo problema: gli agenti possono ricevere permessi troppo ampi o collegarsi a sistemi senza controlli adeguati. ([Atlassian: gestire la proliferazione degli agenti](https://www.atlassian.com/blog/ai-at-work/tackling-ai-agent-sprawl?ref=adrianoamalfi.com)) Anche i fornitori di sicurezza stanno iniziando a intervenire. Trust3 AI, per esempio, ha aggiunto strumenti di visibilità sulla sicurezza degli agenti a Claude Code, così che i team possano osservare le attività e le chiamate agli strumenti MCP senza dover installare strumenti di monitoraggio in locale.

Ma vedere cosa fa un agente è solo il primo passo.

Un piano di controllo maturo deve prevedere almeno cinque elementi:

- **Un’identità distinta:** ogni agente deve poter essere riconosciuto a prescindere dalla persona che lo ha avviato.
- **Permessi legati al compito:** l’accesso deve essere commisurato al lavoro da svolgere, non ai privilegi amministrativi dello sviluppatore.
- **Credenziali a scadenza breve:** lasciare accessi permanenti a un operatore che può agire in autonomia è un rischio evitabile.
- **Tracciabilità delle singole azioni:** non basta sapere che «l’agente ha fatto qualcosa». Bisogna poter ricostruire quale agente ha usato quale strumento, con quali parametri e in base a quale regola.
- **Possibilità di intervento umano:** gli agenti devono poter essere fermati, non soltanto autorizzati.

I team che considerano questi requisiti parte del prodotto riusciranno a muoversi più in fretta di quelli che li trattano come un semplice adempimento normativo.

Per il quadro più ampio su identità, accessi e supervisione, vedi anche [Governare gli agenti IA: quattro piattaforme a confronto](https://adrianoamalfi.com/governo-agenti-aziendali-piattaforme/).

## Il divario tra entusiasmo e ritorno

Sotto la questione ingegneristica ce n’è un’altra, più strettamente economica.

L’entusiasmo degli investitori per l’IA agentica è ancora superiore ai risultati finanziari dimostrati. Un recente sondaggio ha rilevato che solo il 6% degli intervistati attribuisce all’IA almeno il 5% dei profitti operativi. ([Resoconto del sondaggio](https://au.finance.yahoo.com/news/agentic-ai-excitement-runs-ahead-053411169.html?ref=adrianoamalfi.com)) Questo non significa che il coding agentico sia sopravvalutato. Significa che il settore deve ancora dimostrare come trasformare l’attività degli agenti in risultati misurabili.

Le metriche utili non sono il numero di agenti attivati o le righe di codice generate. Contano piuttosto:

- la quota di modifiche che viene approvata dopo la revisione umana;
- il tasso di rilavorazione e di rollback;
- il tempo che passa dalla proposta all’integrazione;
- il numero di incidenti e regressioni legati a modifiche scritte dagli agenti;
- il costo per ogni modifica accettata e arrivata in produzione in sicurezza.

Gli agenti creano valore quando aumentano la velocità del processo senza abbassarne la qualità. In caso contrario, si limitano ad allungare la coda.

## La prossima sfida

Il prossimo vantaggio competitivo nel coding agentico non andrà per forza al modello che ottiene i risultati migliori nei benchmark. I modelli diventano intercambiabili più in fretta di quanto i flussi di lavoro diventino affidabili.

A distinguersi saranno le piattaforme capaci di rendere il lavoro degli agenti **osservabile, circoscritto e reversibile**: un posto in cui definire cosa possono fare, un modo per vedere cosa hanno fatto, un comando per fermarli quando qualcosa va storto e uno storico che aiuti le persone a imparare dai risultati.

La flotta di agenti è arrivata. Il piano di controllo, ancora no.

È in questo spazio che nascerà la prossima generazione di infrastrutture per gli sviluppatori.