L'IA agentiva sta trasformando radicalmente il modo in cui il software viene sviluppato e distribuito. Assistenti progettano pull request, agenti avviare migrazioni e bot di revisione dichiarano un cambiamento sicuro prima ancora che un essere umano finisca il suo caffè. Spesso, l'industria presenta questa evoluzione come un modo per ridurre la necessità di personale specializzato nel controllo qualità. Tuttavia, questa visione è errata. Quando le macchine scrivono una parte più ampia della base di codice, la risorsa scarsa non è la generazione, ma la verifica indipendente.

La sviluppo 2025 di Stack Overflow ha rivelato che l'84% dei rispondenti utilizza strumenti di intelligenza artificiale nello sviluppo o ne pianifica l'uso, e il 51% degli sviluppatori professionisti li utilizza quotidianamente. L'atteggiamento positivo verso l'IA è sceso al 60%, e più sviluppatori esprimono sfiducia nell'accuratezza dell'IA (46%) rispetto a quelli che le fidano (33%). La frustrazione più comune, segnalata dal 66% dei rispondenti, è rappresentata da soluzioni che sono quasi, ma non del tutto, corrette.

La DORA-Studie 2025 di Google Cloud ha riportato che il 90% degli esperti di sviluppo software utilizza l'IA e oltre l'80% ha indicato che l'IA ha migliorato la loro produttività. Tuttavia, solo il 24% ha riferito di avere un alto o molto alto livello di fiducia. Se l'IA è utile senza che ci si possa fidare di essa, questo espande il lavoro dei tester piuttosto che ridurlo.

Velocità non è prova

Lavoro come ingegnere della qualità del software, con un focus su test agentivi e gate di integrazione continua per codice generato dall'IA. Internamente, abbiamo introdotto un revisore di PR e un generatore di casi di test. Entrambi creano solo bozze. Nessuno dei due strumenti valuta il proprio lavoro. Questa regola è importante perché gli agenti parlano con grande sicurezza. Sicurezza non è uguale a correttezza.

Abbiamo imparato questa lezione a nostre spese. In un progetto pilota con un revisore di PR basato su IA, una modifica ha superato l'integrazione continua in meno di 4 minuti. Due giorni dopo, un dashboard a valle ha mostrato temperature impossibili. Su un percorso di codice che la suite di test non aveva mai eseguito, la conversione tra Celsius e Fahrenheit era invertita. La pipeline era verde. Il prodotto era sbagliato. Una pipeline di integrazione continua verde che non ha mai posto la domanda difficile è solo teatro.

Questo incidente fa parte di un modello più ampio. Il rapporto sullo stato della generazione di codice da parte di IA rispetto a quella umana di CodeRabbit ha analizzato 470 pull request open source su GitHub (320 con codice scritto sia da IA che da esseri umani, 150 scritti esclusivamente da esseri umani). Nelle modifiche scritte dall'IA, si sono verificati complessivamente circa 1,7 volte più problemi; i problemi di logica e correttezza erano il 75% più frequenti e le vulnerabilità di sicurezza sono state riscontrate fino a 2,74 volte più spesso.

Il rapporto 2026 sulla sicurezza del codice generativo di Veracode ha esaminato i modelli in base a compiti di sicurezza e ha rilevato una media del 56% di successo nei test di sicurezza. Rispetto al 55% del rapporto precedente, questo è stato un cambiamento minimo. Allo stesso tempo, ogni compito di generazione di codice dell'IA ha introdotto una vulnerabilità di sicurezza nota nel 44% dei casi. La sintassi è quasi risolta. Il comportamento sicuro e corretto non lo è. I tester sono coloro che si rifiutano di confondere i due.

Dipendenze allucinate sono un problema di test

Nella generazione di codice, vengono anche inventate dipendenze. Lo studio Abbiamo un pacchetto per voi! del settore USENIX Security 2025 ha esaminato pacchetti allucinati in 16 modelli linguistici di grandi dimensioni per la generazione di codice, utilizzando 576.000 esempi. I modelli commerciali hanno allucinato pacchetti nel 5,2% dei casi in media; nei modelli open source, la media era del 21,7%, con 205.474 nomi diversi allucinati. Pacchetti fantasma permanentemente disponibili offrono un facile bersaglio per il slop-squatting: gli aggressori registrano il nome inventato e aspettano che uno sviluppatore o un agente installi il pacchetto.

I controlli sull'origine delle dipendenze appartengono alla stessa categoria dei test di funzionalità. Se un agente inventa un pacchetto NuGet o npm, il merge deve fallire prima che qualcuno discuta se i test unitari siano sufficientemente approfonditi. Verificare l'origine non è una misura igienica opzionale. È un gate di qualità per le modifiche scritte dall'IA.

Gates che scalano con il numero di agenti

Quando abbiamo aggiornato l'intera azienda da .NET 8 a .NET 10 con l'automazione basata su IA in circa due settimane, ero responsabile dei gate di qualità. La velocità era reale. Così reale era anche la necessità di controlli che non credano semplicemente al riassunto dell'agente. Per il codice modificato, utilizzo i seguenti gate:

    • Obiettivi di punteggio di mutazione compresi tra il 60% e il 70% per la logica modificata, in modo che la suite di test debba riconoscere mutanti reali, piuttosto che coprire semplicemente le righe di codice
    • Test basati su proprietà per la logica ad alto rischio, dove gli esempi da soli non specificano in modo sufficiente il comportamento
    • Controlli dell'origine delle dipendenze per respingere il slop-squatting e i pacchetti allucinati
    • Segnali di duplicati e modifiche frequenti che scoprono il va e vieni di copy-and-paste degli agenti
    • Verifica indipendente delle affermazioni dell'agente come "migrazione completata", poiché un'affermazione rimane un'ipotesi fino a quando non ci sono prove

Il punteggio di mutazione non è una metrica di vanità. Mostra se i tuoi test rilevano un errore intenzionalmente inserito. La copertura dei test può aumentare mentre la suite di test continua a ignorare il percorso del codice Celsius. I test basati su proprietà costringono il modello del sistema a superare l'intero intervallo di valori e non solo su un singolo percorso ideale. Il controllo dell'origine chiude la dispensa dei pacchetti. Modifiche frequenti e duplicati scoprono l'abitudine degli agenti di riscrivere la stessa idea in tre modi diversi. Insieme, rappresentano un atteggiamento: supponete che l'agente abbia torto finché la suite di test non prova il contrario. In questo modo, mantengo la calibrazione durante le revisioni del codice.

Nessuno di questi sostituisce i test delle API, i test di autenticazione, i test di fumo o l'automatizzazione dell'interfaccia utente. FlaUI e PowerShell continuano a trovare errori che le API trascurano. Anche l'imballaggio con NuGet, MSI e MSM deve essere validato attraverso test di installazione e test del percorso di installazione non supervisionato. I flussi di lavoro agentivi aumentano il volume. Non rendono queste discipline obsolete.

Più tester, compiti diversi

La preoccupazione è che gli agenti scrivano test e rendano gli esseri umani superflui. Gli agenti possono progettare casi di test. Tuttavia, non dovrebbero certificare le proprie bozze. I rispondenti di Stack Overflow che intendono utilizzare l'IA per i test in futuro vedono il sospetto umano come ancora centrale: se avessero chiesto aiuto a un'altra persona, il motivo più comune era che non si fidavano delle risposte dell'IA. Questo istinto è una forza della professione.

È importante assumere e promuovere persone che sono arrivate qui attraverso percorsi non tradizionali. Dopo una carriera nel settore delle operazioni HR e dei dati, sono passato alla qualità del software, ho conseguito un Master of Science in Information Systems presso l'UMBC a maggio 2024 e lavoro ora per rendere praticabili i gate di prova per l'IA agentiva. L'IA agentiva non aspetterà persone con un singolo percorso educativo e professionale specifico. Ha bisogno di più persone che possano progettare prove, non di meno persone che semplicemente approvino build verdi.

La domanda del prodotto è semplice. Se gli agenti vengono consegnati più velocemente di quanto la verifica possa tenere il passo, non si tratta di un guadagno di produttività. È un incidente posticipato. Investite in tester che considerino ogni affermazione di un agente con scetticismo, integrino mutazione e provenienza nella CI e mantengano un giudizio indipendente dove è necessario.