La IA agéntica sta cambiando radicalmente il modo in cui sviluppiamo e consegniamo il software. Gli assistenti scrivono richieste di modifica, gli agenti avviare migrazioni e i bot di revisione garantiscono che un cambiamento sia sicuro prima che una persona finisca il suo caffè. L'industria tende a presentare questa evoluzione come un modo per ridurre il numero di professionisti della qualità. Questo approccio è errato. Man mano che le macchine scrivono una parte sempre più grande del codice, la competenza rara non è generare codice, ma verificarlo in modo indipendente.

L'indagine per sviluppatori di Stack Overflow del 2025 ha rivelato che l'84% delle persone intervistate usa o prevede di usare strumenti di IA durante lo sviluppo e che il 51% degli sviluppatori professionisti li usa quotidianamente. L'opinione positiva è scesa al 60%, e sono più i sviluppatori che diffidano attivamente della precisione dell'IA (46%) di quelli che si fidano di essa (33%). La principale frustrazione, segnalata dal 66%, erano le soluzioni che quasi azzeccavano, ma non del tutto.

La ricerca di DORA ha riferito nel 2025 che l'adozione dell'IA tra i professionisti dello sviluppo software aveva raggiunto il 90%; più dell'80% affermava che l'IA aveva migliorato la loro produttività, ma solo il 24% diceva di fidarsi molto o moltissimo di essa. L'utilità senza fiducia è proprio ciò che amplia il lavoro di chi fa le prove, non lo riduce.

La velocità non è una prova

Lavoro come ingegnere della qualità del software, specializzato in test agéntici e controlli di CI per codice generato da IA. Nella nostra azienda, abbiamo lanciato un revisore di PR e un generatore di casi di prova. Entrambi sono strumenti per elaborare bozze. Nessuno valuta il proprio lavoro. Questa regola è importante perché gli agenti si esprimono con sicurezza. La sicurezza nell'esprimersi non equivale ad avere ragione.

Lo abbiamo imparato a nostre spese. Durante una prova pilota di un revisore di PR creato con IA, un cambiamento ha superato la CI in meno di 4 minuti. Due giorni dopo, un pannello successivo ha mostrato temperature impossibili. In un percorso di codice che la batteria di prove non eseguiva mai, era stata invertita la conversione da Celsius a Fahrenheit. La canalizzazione appariva verde. Il prodotto era sbagliato. Una CI verde che non pone mai la domanda difficile è puro teatro.

Questo incidente fa parte di una tendenza più ampia. Il rapporto sullo stato della generazione di codice con IA rispetto alla generazione umana di CodeRabbit ha analizzato 470 richieste di modifica di codice aperto su GitHub (320 con coautore IA e 150 solo di autori umani). I cambiamenti scritti con IA hanno generato circa 1,7 volte più problemi in totale; i problemi di logica e correzione erano più comuni del 75%, e i risultati di sicurezza fino a 2,74 volte più frequenti.

Il rapporto sulla sicurezza del codice generato con IA di Veracode del 2026 ha testato modelli in diverse attività di sicurezza e ha trovato una media di approvazione della sicurezza del 56%, appena sopra il 55% del rapporto precedente, mentre circa il 44% delle attività di generazione di codice con IA ha introdotto una vulnerabilità nota. La sintassi è praticamente risolta. Il comportamento sicuro e corretto, no. Chi fa le prove sono quelli che si rifiutano di confondere queste due cose.

Le dipendenze inventate sono un problema di prove

La generazione inventa anche pacchetti. Lo studio di USENIX Security del 2025, "Abbiamo un pacchetto per voi!", ha valutato le allucinazioni dei pacchetti in 16 modelli di linguaggio grandi (LLM) che generano codice e in 576.000 campioni. In media, i modelli commerciali hanno allucinato pacchetti almeno il 5,2% delle volte; i modelli open source hanno registrato una media del 21,7%, con 205.474 nomi inventati unici. I pacchetti fantasma che rimangono disponibili creano un obiettivo perfetto per gli attacchi di appropriazione dei nomi dei pacchetti inventati: gli attaccanti registrano il nome inventato e aspettano che uno sviluppatore o un agente lo installi.

I controlli dell'origine delle dipendenze devono essere al livello delle prove funzionali. Se un agente inventa un pacchetto di NuGet o npm, l'integrazione del cambiamento deve fallire prima che qualcuno discuta se i test unitari siano stati esaustivi. Verificare l'origine non è una pratica di igiene opzionale. È un controllo di qualità per i cambiamenti scritti con IA.

Controlli che scalano con gli agenti

Quando abbiamo eseguito un aggiornamento da .NET 8 a .NET 10 in tutta l'organizzazione in circa due settimane tramite automazione assistita da IA, mi sono occupato dei controlli di qualità. La velocità era reale. Lo era anche la necessità di avere controlli che non accettino il riassunto dell'agente. Questi sono i controlli che applico al codice modificato:

    • Punteggi di mutazione tra il 60% e il 70% nella logica modificata, in modo che la batteria di prove debba rilevare mutazioni reali e non si limiti a coprire le righe
    • Test basati su proprietà per la logica ad alto rischio, dove gli esempi da soli non specificano il comportamento con sufficiente precisione
    • Controlli dell'origine delle dipendenze per rilevare attacchi di appropriazione di nomi di pacchetti inventati e pacchetti allucinati
    • Indicatori di duplicazione e cambiamenti eccessivi che rilevano il caos del copiare e incollare degli agenti
    • Verifica indipendente delle affermazioni degli agenti, come "migrazione completata", perché un'affermazione non è altro che un'ipotesi fino a quando non vengono presentate prove

Il punteggio di mutazione non è una metrica per vantarsi. Indica se i test rilevano un errore introdotto deliberatamente. La copertura può aumentare e, comunque, la batteria di test può tralasciare il percorso di Celsius. I controlli basati su proprietà obbligano il modello del sistema a mantenersi valido in diversi intervalli, non solo in un percorso ideale. Verificare l'origine chiude la porta ai pacchetti inventati. I cambiamenti eccessivi e la duplicazione permettono di rilevare la tendenza degli agenti a riscrivere la stessa idea in tre modi diversi. Insieme, tutto ciò definisce una posizione: dare per scontato che l'agente sbagli fino a quando la batteria di test dimostri il contrario. Mantengo questo criterio di calibrazione durante le revisioni.

Niente di tutto ciò sostituisce i test delle API, i test di autenticazione, i test di fumo o l'automazione dell'interfaccia utente. FlaUI e PowerShell continuano a rilevare ciò che sfugge alle API. I pacchetti distribuiti tramite NuGet, MSI e MSM continuano a richiedere validazioni di installazione e di installazione silenziosa. I flussi di lavoro agéntici amplificano il volume. Non eliminano queste discipline.

Più professionisti delle prove, un lavoro diverso

La paura è che gli agenti scrivano i test e che gli esseri umani diventino superflui. Gli agenti possono redigere casi di prova. Non dovrebbero certificare le loro bozze. Tra coloro che hanno risposto a Stack Overflow e prevedono di utilizzare l'IA per eseguire test in futuro, la diffidenza umana rimane centrale: quando chiederebbero aiuto a un'altra persona, la principale ragione era che non si fidavano delle risposte dell'IA. Questo istinto è il maggiore asset della professione.

È importante assumere e offrire opportunità a persone che hanno seguito percorsi non tradizionali. Sono passato al settore qualità dopo aver lavorato in operazioni di risorse umane e analisi dei dati, ho terminato una laurea magistrale in Sistemi Informativi presso l'UMBC a maggio 2024 e ora dedico le mie giornate a rendere pratici i controlli degli agenti. L'IA agéntica non aspetterà che tutti abbiano un percorso accademico o professionale identico. Ha bisogno di più persone in grado di progettare test che forniscano prove, non di meno persone che approvino senza mettere in discussione le compilazioni contrassegnate in verde.

La domanda sul prodotto è semplice. Se gli agenti lanciano prodotti più velocemente di quanto tu possa testarli, allora hai bisogno di più persone che testino, non di meno. La qualità non è un obiettivo, è un processo. E quel processo richiede persone che siano disposte a fare domande difficili e a cercare risposte ancora più difficili.