Solo qualche anno fa, ipotizzare che un software venisse scritto e poi verificato dall’AI sarebbe sembrato un’ipotesi fantascientifica. Oggi è una prassi sempre più diffusa e in molte aziende persino consolidata. A confermare la portata di questa trasformazione, Gartner stima che entro il 2028 il 75% degli ingegneri del software nelle grandi aziende utilizzerà regolarmente assistenti AI per la programmazione, rispetto a meno del 10% registrato all’inizio del 2023. L’intelligenza artificiale genera il codice, scrive i casi di test, produce la documentazione, analizza il codice prodotto e segnala anomalie suggerendo le relative correzioni. Il tutto in tempi brevissimi, con vantaggi concreti e misurabili, ma anche con un controllo e un’affidabilità fragili.
I limiti dell’AI testing
I sistemi AI riconoscono schemi nel codice, ma non ragionano sul contesto in cui quel software dovrà funzionare. Non sanno pertanto nulla del business che deve supportare, degli utenti che lo useranno, dei casi limite che potrebbero farlo fallire. Lo strumento che genera il codice e quello che lo verifica lavorano entrambi per correlazioni statistiche: identificano ciò che assomiglia a qualcosa di già visto, non ciò che è corretto rispetto a una realtà che non hanno mai osservato. Quando i due strumenti condividono gli stessi dati di addestramento, condividono anche gli stessi punti ciechi: l’errore che il primo potrebbe non vedere è lo stesso che non vedrà il secondo. I sistemi AI riconoscono bene gli errori già visti, di contro faticano con quelli nuovi, per esempio specifici di un contesto di business che nessun dataset ha contemplato o quelli che nascono dall’interazione tra componenti sviluppati in momenti diversi da team diversi.
Quando il testing è generato dallo stesso strumento che ha prodotto il codice, l’AI verifica che il codice faccia ciò che il modello si aspetta debba fare, non ciò che l’azienda o l’utente finale ha bisogno che faccia. Il risultato è che il codice funziona, i test vengono superati e l’applicazione viene rilasciata, ma in produzione emergono i problemi. Non errori tecnici come crash o blocchi del sistema, piuttosto comportamenti sbagliati: come un gestionale che registra le consegne senza aggiornare gli stock di magazzino, o un report che aggrega i dati nel modo indicato dal modello ma non in quello in cui gli utenti li leggono e usano. In altre parole, il software fa quello per cui è stato scritto, peccato che quello per cui è stato scritto non è corretto.
Questo non vuol dire che affidarsi a un sistema AI per valutare l’output di un altro sistema AI sia sbagliato, in certe condizioni è persino consigliabile, però diventa controproducente quando è l’unica modalità di verifica adottata, quando non c’è nessun punto nel processo in cui un essere umano con competenza di dominio verifica cosa è stato prodotto ed evita che gli errori arrivino in produzione.
Il ruolo del QA nel ciclo di sviluppo automatizzato
Questo scenario conferma la centralità del Quality Assurance come presidio della qualità lungo tutto il ciclo di sviluppo, dalla definizione dei requisiti fino al rilascio. Un ruolo che con l’introduzione dell’AI nel software development non si riduce, anzi si rafforza. Quando il codice viene generato e verificato in automatico, il QA è l’unica funzione che porta nel ciclo quella forma di giudizio che l’AI non può esercitare: la capacità di stabilire se un software è adeguato rispetto al contesto reale in cui opera, agli utenti che lo usano, alle situazioni che nessun dato di addestramento ha mai visto. Se l’AI verifica “solo” che il codice giri, i QA specialist hanno invece il compito, anzi la responsabilità, di rispondere alla domanda “Questo software fa ciò che deve fare e per chi deve farlo?”, e quindi di certificare che la soluzione sia veramente adeguata prima del rilascio.
Il Quality Assurance introduce inoltre nel ciclo un elemento che l’automazione tende a trascurare: la tracciabilità. Sapere quale strumento ha generato quale parte del codice, con quali istruzioni, in quale momento. Senza questa informazione, quando qualcosa va storto in produzione diventa molto difficile capire dove intervenire, e garantire che la correzione risolva davvero il problema e non solo i suoi effetti visibili.
La responsabilità che l’AI non può assumere
Quando un software in produzione si comporta in modo sbagliato, dire che “L’errore è stato generato dall’AI” non risponde alla domanda centrale: perché l’anomalia non è stata individuata prima del rilascio? Nei contesti in cui l’intero processo è delegato agli strumenti automatici, questa domanda spesso non ha risposta semplicemente perché nessuna funzione aziendale ha il compito formale di valutare se il software generato e testato dall’intelligenza artificiale è adeguato prima che vada in produzione.
È in questo scenario che il QA diventa decisivo, non come funzione di controllo aggiuntiva, ma come la funzione aziendale a cui spetta formalmente la responsabilità di certificare che il software sia idoneo prima del rilascio, quella che invece, negli scenari di automazione spinta, manca.
L’integrazione di un livello di supervisione umana (Human-in-the-Loop) non è una semplice cautela, ma un requisito imprescindibile di IT governance. L’Intelligenza Artificiale, per sua natura, tende a generare una pericolosa illusione di controllo, fornendo output che appaiono intrinsecamente verificati. Tuttavia, dal punto di vista dell’affidabilità sistemica, un modello basato sull’auto-convalida è intrinsecamente fragile perché potenzialmente in attesa di un’anomalia critica di cui l’algoritmo non possiede le metriche per identificarla e prevenirla.
Le ripercussioni di un’automazione priva di controllo sono già un problema tangibile. Un’analisi condotta da GitClear su oltre 150 milioni di righe di codice ha rivelato che la crescente dipendenza dagli assistenti AI sta generando un pericoloso “debito tecnico indotto dall’AI”. Il report ha evidenziato un aumento allarmante del “code churn”, ovvero la percentuale di codice che deve essere modificato, corretto o eliminato entro due settimane dalla stesura, dimostrando che l’iper-produttività iniziale della macchina spesso collassa senza una validazione umana adeguata.
E le conseguenze di un software inadeguato non si fermano al codice, si trasferiscono sull’esperienza degli utenti, sui processi aziendali, sulle decisioni che quella tecnologia avrebbe dovuto supportare e migliorare. Il Quality Assurance nell’era dell’AI software development è la condizione perché quelle conseguenze restino un rischio gestito, non un problema che emerge in produzione portando a problemi operativi e a importanti costi aggiuntivi.
