L’IA agentica ha bisogno di più tester, non di meno

L’IA agentica sta riscrivendo il modo in cui viene distribuito il software. Gli assistenti preparano richieste di modifica, gli agenti avviano migrazioni e i bot di revisione dichiarano sicura una modifica prima ancora che una persona finisca il caffè. Spesso il settore presenta questo scenario come una strada per ridurre il personale addetto alla qualità. È una visione capovolta. Quando le macchine scrivono una porzione sempre maggiore del codice, la competenza più rara non è generare codice, ma verificarlo in modo indipendente.

Il sondaggio 2025 di Stack Overflow per gli sviluppatori ha rilevato che l’84% degli intervistati usa o prevede di usare strumenti di IA nello sviluppo e che il 51% degli sviluppatori professionisti li usa ogni giorno. Il giudizio positivo è sceso al 60% e sono più gli sviluppatori che diffidano attivamente dell’accuratezza dell’IA (46%) di quelli che si fidano (33%). La principale fonte di frustrazione, citata dal 66%, erano le soluzioni quasi giuste, ma non del tutto. La ricerca DORA del 2025 di Google Cloud ha rilevato un’adozione dell’IA pari al 90% tra i professionisti dello sviluppo software; oltre l’80% ha dichiarato che l’IA aveva migliorato la produttività, ma solo il 24% ha riferito di fidarsi molto o moltissimo. È proprio l’utilità senza fiducia a far crescere il lavoro dei tester, non a ridurlo.

La velocità non è una prova

Lavoro come ingegnere della qualità del software e mi occupo di test agentici e controlli CI per il codice scritto dall’IA. All’interno dell’azienda abbiamo introdotto un revisore delle PR e un generatore di casi di test. Entrambi sono strumenti per preparare bozze. Nessuno dei due valuta il proprio lavoro. Questa regola è importante perché gli agenti si esprimono con sicurezza. La sicurezza non equivale alla correttezza.

Lo abbiamo imparato a caro prezzo. Durante una sperimentazione di un revisore delle PR realizzato con l’IA, una modifica ha superato la CI in meno di 4 minuti. Due giorni dopo, una dashboard a valle ha mostrato temperature impossibili. In un percorso del codice che la suite non aveva mai verificato, era avvenuto un cambiamento nella conversione da Celsius a Fahrenheit. La pipeline era verde. Il prodotto era sbagliato. Una CI verde che non pone mai la domanda difficile è solo una messinscena.

Questo incidente si inserisce in una tendenza più ampia. Il Rapporto sullo stato della generazione di codice con IA rispetto a quella umana di CodeRabbit ha analizzato 470 richieste di modifica di progetti open source su GitHub (320 realizzate con il contributo dell’IA, 150 esclusivamente da persone). Le modifiche scritte dall’IA hanno prodotto circa 1,7 volte più problemi nel complesso; gli errori di logica e correttezza erano più frequenti del 75% e le vulnerabilità rilevate in ambito di sicurezza erano fino a 2,74 volte più numerose. Il Rapporto 2026 sulla sicurezza del codice generato con IA di Veracode ha testato diversi modelli in attività di sicurezza e ha rilevato un tasso medio di superamento delle verifiche di sicurezza del 56%, appena superiore al 55% del rapporto precedente; nel frattempo, circa il 44% delle attività di generazione di codice con IA introduceva una vulnerabilità nota. La sintassi è ormai quasi un problema risolto. Il comportamento sicuro e corretto, invece, no. I tester sono le persone che si rifiutano di confondere le due cose.

Le dipendenze allucinatorie sono un problema di test

La generazione inventa anche pacchetti. La ricerca USENIX Security 2025, Abbiamo un pacchetto per te!, ha valutato le allucinazioni relative ai pacchetti su 16 LLM in grado di generare codice e 576.000 campioni. In media, i modelli commerciali hanno inventato pacchetti almeno nel 5,2% dei casi; quelli open source hanno registrato una media del 21,7%, con 205.474 nomi inventati distinti. La persistenza di pacchetti fantasma crea un bersaglio ideale per l’occupazione fraudolenta di nomi di pacchetti: gli aggressori registrano il nome inventato e aspettano che uno sviluppatore o un agente lo installi.

I controlli sulla provenienza delle dipendenze dovrebbero essere allo stesso livello dei test funzionali. Se un agente inventa un pacchetto NuGet o npm, l’unione del codice dovrebbe essere bloccata prima ancora che qualcuno discuta dell’accuratezza dei test unitari. Verificare la provenienza non è una precauzione facoltativa. È un controllo di qualità per le modifiche scritte dall’IA.

Controlli che si adattano alla crescita degli agenti

Quando abbiamo eseguito in circa due settimane un aggiornamento a livello aziendale da .NET 8 a .NET 10 con automazione assistita dall’IA, mi sono occupato dei controlli di qualità. La velocità era reale, così come la necessità di verifiche che non si fidassero del riepilogo dell’agente. Sulle modifiche al codice applico questi controlli:

• Obiettivi di copertura delle mutazioni compresi tra il 60% e il 70% per la logica modificata, in modo che la suite debba eliminare mutanti reali anziché limitarsi a coprire le righe
• Test basati sulle proprietà per la logica ad alto rischio, quando i soli esempi non specificano il comportamento in modo sufficiente
• Controlli sulla provenienza delle dipendenze per contrastare l’occupazione fraudolenta di nomi di pacchetti e i pacchetti allucinatori
• Indicatori di duplicazione e di modifiche ripetute che segnalano il lavoro ripetitivo di copia e incolla degli agenti
• Verifica indipendente delle affermazioni degli agenti, come «migrazione completata», perché un’affermazione resta un’ipotesi finché non viene supportata da prove

La copertura delle mutazioni non è un indicatore di facciata. Verifica se i test rilevano un errore introdotto deliberatamente. La copertura può aumentare anche se la suite continua a non rilevare il percorso da Celsius a Fahrenheit. I controlli basati sulle proprietà obbligano il modello del sistema a reggere in un intervallo di valori, non solo in un caso favorevole. La verifica della provenienza chiude la dispensa dei pacchetti. I controlli sulle modifiche ripetute e sulla duplicazione individuano l’abitudine degli agenti di riscrivere la stessa idea in tre modi. Insieme definiscono un approccio: presumere che l’agente abbia torto finché la suite non dimostra il contrario. Tengo presente questa regola durante la revisione.

Niente di tutto questo sostituisce i test delle API, i test di autenticazione, i test preliminari o l’automazione dell’interfaccia utente. FlaUI e PowerShell continuano a rilevare problemi che sfuggono alle API. La creazione di pacchetti tramite NuGet, MSI e MSM richiede ancora la convalida dell’installazione e delle procedure di installazione silenziosa. I flussi di lavoro agentici amplificano i volumi, ma non rendono obsolete queste discipline.

Più tester, con un lavoro diverso

Il timore è che gli agenti scrivano i test e che gli esseri umani diventino superflui. Gli agenti possono preparare i casi di test, ma non dovrebbero certificare le proprie bozze. Tra gli intervistati di Stack Overflow che prevedono di usare l’IA per i test in futuro, la diffidenza umana resta un aspetto centrale: quando avrebbero chiesto aiuto a un’altra persona, il motivo principale era la mancanza di fiducia nelle risposte dell’IA. Questo istinto è il punto di forza della professione.

È importante assumere e mettere nelle condizioni di lavorare al meglio le persone che hanno seguito percorsi non convenzionali. Sono passato al settore della qualità dopo una carriera nell’operatività delle risorse umane e nell’analisi dei dati, ho conseguito un Master of Science in Sistemi informativi presso UMBC nel maggio 2024 e oggi mi occupo ogni giorno di rendere pratici i controlli di qualità per l’IA agentica. L’IA agentica non aspetterà che tutti abbiano seguito lo stesso percorso. Ha bisogno di più persone capaci di progettare prove, non di meno persone che approvino senza verifiche le build contrassegnate come superate.

La questione del prodotto è semplice. Se gli agenti vengono rilasciati più rapidamente di quanto le tue verifiche riescano a valutare, non hai ottenuto un aumento della produttività. Hai solo rimandato un incidente. Investi in tester che considerino sospetta ogni affermazione degli agenti, integrino nella CI i test di mutazione e il tracciamento della provenienza e mantengano un giudizio indipendente proprio nei casi in cui il modello è più fluido e meno affidabile. L’IA agentica ha bisogno di più tester, non di meno.