Test verdi e codice che sembra funzionare: quando l'AI ti inganna

Nove bug che sembravano tutti un sistema funzionante

Uno sviluppatore ha raccontato di aver costruito con l'aiuto dell'AI un sistema che, a prima vista, funzionava. In realtà non funzionava affatto. In una sola sessione ha scovato 31 problemi, nove dei quali fondamentali: ognuno faceva sembrare corretto il sistema mentre non lo era. Il caso più clamoroso era un controllo statistico invertito, che verificava p < 0.95 al posto di p < 0.05: quasi tutto "passava", e il rumore veniva promosso come miglioramento. Altri classici: un test A/B che confrontava un prompt con se stesso, uno scoring che accettava qualsiasi risposta non vuota, un test di integrazione che saltava le parti difficili e un mock lasciato nel codice al posto della chiamata reale. Il racconto completo è nell'articolo "9 Bugs That All Looked Like a Working System".

La frase che riassume tutto è brutale: i bug più pericolosi non sono quelli che fanno crashare l'applicazione, ma quelli che producono un output che sembra corretto. Il sistema qualcosa lo produce sempre. La domanda è se quel qualcosa è reale.

Cosa significa se il tuo codice l'ha scritto Copilot

Se hai costruito il tuo prodotto con Copilot che ti suggeriva funzioni intere mentre scrivevi, il rischio non è teorico. Copilot completa il codice a partire dal contesto locale: propone una condizione, un controllo, una gestione degli errori che "sembrano" giusti perché stilisticamente coerenti con quello che stavi scrivendo. Ma la coerenza stilistica non è correttezza.

Un esempio concreto: un controllo di soglia. Copilot ti suggerisce una if con un confronto plausibile, tu la accetti perché a colpo d'occhio funziona, la suite di test diventa verde e vai avanti. Nessuno si è fermato a chiedersi se la soglia fosse invertita. Nel racconto della fonte bastavano due righe per trasformare un sistema che impara in uno che deriva silenziosamente. Nel tuo caso possono bastare due righe per trasformare un controllo di autorizzazione in una porta aperta.

Il punto non è che hai usato l'AI. Il punto è che hai accettato codice che ragiona in modo locale, senza che nessuno abbia dato un verdetto sull'insieme. Un test verde ti dice che il codice risponde alla domanda che ti sei ricordato di porre quando lo hai scritto. Non ti dice se hai posto la domanda giusta.

Perché ora ti serve un audit

Hai spedito. Il prodotto è online, gli utenti lo usano, la CI è verde. Eppure non hai un verdetto indipendente su cosa c'è davvero dentro il repository. Questa è la zona grigia più pericolosa: tutto sembra a posto, quindi nessuno guarda.

Un audit on-demand come VibeInspect serve esattamente qui. Carichi lo ZIP del repository, degli specialisti AI lo analizzano e ricevi un PDF con un verdetto. Non è un pentest, non corregge il codice al posto tuo, non promette sicurezza assoluta. Fa una cosa sola e la fa bene: ti dice in che stato è il codice che hai generato, con evidenze verificabili.

Nel caso della fonte, il controllo di redazione dei log aveva 28 test verdi ma non era mai stato eseguito nell'ambiente che doveva proteggere. "Un controllo che non gira mai nell'ambiente che deve proteggere non è un controllo: è un'intenzione con dei test." Un audit indipendente ragiona proprio così: non si accontenta della suite verde, cerca la distanza tra ciò che il codice dichiara e ciò che il codice fa davvero. Con il piano Diagnostic ottieni file, riga ed evidenze sui punti concreti, così sai esattamente dove intervenire prima che quel controllo invertito diventi un incidente.

Cosa un linter non vede

Un linter è utile, ma vive nel mondo della forma. Ti segnala una variabile inutilizzata, un import mancante, uno stile incoerente. Non ha idea del significato del tuo codice.

Un linter non ti dirà mai che una condizione è logicamente invertita, perché sintatticamente è perfetta. Non ti dirà che un test A/B confronta due volte la stessa cosa, perché il codice compila. Non ti dirà che un mock lasciato per errore sta rispondendo al posto del servizio reale, perché è codice valido. Non ti dirà che una manciata di test copre le proprietà sbagliate e lascia scoperto il caso che conta.

Lo dice bene la fonte: una suite verde può convivere con un output completamente sbagliato, perché ogni singola proprietà verificata era soddisfatta. Un URL duplicato resta un URL valido. Un dato non filtrato che finisce nei log resta una stringa. Questi problemi vivono nella semantica, non nella sintassi, ed è esattamente lo strato che il linter non tocca. Serve qualcosa che legga il codice e si chieda se sta facendo la cosa giusta, non solo se è scritto bene.

Cosa fare questa settimana

Non riscrivere tutto, non farti prendere dall'ansia. Fai tre cose concrete.

Prima: prendi i controlli critici del tuo prodotto, quelli che decidono chi può fare cosa e quali dati finiscono dove, e verifica manualmente che girino davvero nell'ambiente di produzione, non solo nei test. Apri i log reali e guarda cosa contengono.

Seconda: rileggi i suggerimenti di Copilot che hai accettato senza pensarci sui confronti, sulle soglie e sulle autorizzazioni. Cerca le condizioni invertite. Sono le più insidiose perché sembrano perfette.

Terza: prima di continuare a spedire funzioni sopra un codice di cui non hai un verdetto, fatti dare quel verdetto. Carica lo ZIP del repository su VibeInspect e scegli il piano Diagnostic: file, riga ed evidenze sui punti dove la logica dice una cosa e fa un'altra. Il codice sorgente viene cancellato a fine analisi.

Un test verde ti fa dormire tranquillo. Un verdetto ti fa capire se dovresti.