Il codice generato dall'AI può sembrare giusto ed essere sbagliato

Un test verde non prova che il tuo codice sia corretto

C'è una categoria di bug che non fa mai comparire una traccia di errore. Il programma gira, i test passano, il linter non protesta. Eppure il risultato è sbagliato. Ne parla in modo lucido un'analisi pubblicata su dev.to, "Four Things I Don't Let the Agent Decide", dove l'autore descrive il fallimento tipico di un progetto costruito con l'aiuto di un agente AI: "correct-looking output from wrong code", cioè output che sembra corretto prodotto da codice che non lo è.

L'esempio è netto. Un report che stampa un reddito medio di 18.400 quando il valore reale è 18.004 viene generato senza intoppi. Passa i test, perché i test verificano soltanto che sia uscito un numero, e un numero è uscito. Un grafico disegnato al contrario resta comunque un grafico. Un valore mancante trasformato in zero non è un crash: è una risposta sbagliata detta con sicurezza.

Questo è il punto che dovrebbe far riflettere chiunque abbia messo in produzione un progetto scritto in gran parte da un'AI. Il problema non è la sintassi. Il problema è che nessuno ha dato un verdetto sulla correttezza reale di quel codice.

Cosa significa se il tuo codice l'ha scritto Cursor

Quando generi funzioni, query e trasformazioni con Cursor, ottieni codice che compila e che, quasi sempre, gira. È esattamente questo a renderti tranquillo troppo presto. L'agente ti restituisce una funzione plausibile, tu la accetti, i test che l'agente stesso ha scritto passano, e il modulo entra nel repository.

Ma una funzione che calcola un aggregato con un GROUP BY sbagliato, o che confonde una divisione, o che gestisce un valore nullo come se fosse zero, non lancia eccezioni. Restituisce un risultato. Sbagliato, ma formalmente valido. Se quel risultato finisce in una fattura, in un cruscotto o in una risposta all'utente, l'errore viaggia indisturbato fino a chi legge.

Il rischio concreto qui riguarda la logica di business e i dati derivati. Un valore calcolato male non ha "colore rosso" da nessuna parte nella tua pipeline. Nessun controllo automatico ti dice che quel numero è diverso da quello che ti aspettavi, perché nessuno ha scritto quell'aspettativa da qualche parte. L'agente decide, tu ti fidi, e la verifica non esiste.

Non è una colpa dell'AI. È una lacuna di processo: manca il momento in cui qualcuno, o qualcosa, ri-deriva il verdetto dalle evidenze invece di accettare la parola dell'agente.

Perché ora ti serve un audit

L'idea centrale della fonte è semplice e vale anche per te: delega il lavoro, ma tieni per te il verdetto. L'agente scrive il codice, esegue i suoi controlli, si fa un'opinione e la riporta. Nessuna di queste cose è la decisione. La decisione la prende qualcosa che ricontrolla partendo dalle prove.

Sul tuo repository questo si traduce in una domanda che oggi probabilmente non ha risposta: in che stato reale è il codice che hai spedito? Non "gira?", ma "fa la cosa giusta, e come lo dimostri?".

Un audit serve proprio a colmare questo vuoto. VibeInspect è un'analisi on-demand: carichi lo ZIP del repository, specialisti AI lo esaminano e ricevi un PDF con un verdetto. Niente server da configurare, e il codice sorgente viene cancellato al termine dell'analisi.

Cosa ti dà, concretamente, un verdetto esterno che i tuoi test non ti danno:

• un punto di vista che non è quello dell'agente che ha scritto il codice, quindi non eredita i suoi punti ciechi;
• l'individuazione dei punti dove la logica può produrre risultati plausibili ma errati, come gestioni di valori mancanti, conversioni implicite e aggregazioni;
• la separazione tra "il codice esiste" e "il codice fa ciò che serve".

È importante essere onesti su cosa non è. VibeInspect non è un pentest, non corregge il codice al posto tuo e non promette sicurezza assoluta. Ti dà un verdetto sullo stato del repository, con le evidenze per capirlo. Il piano Diagnostic arriva fino a file, riga ed evidenze, senza però riscrivere nulla e senza revisione umana. La correzione resta compito tuo: l'audit ti dice dove guardare e perché.

Cosa un linter non vede

Un linter è bravissimo a segnalare variabili non usate, import mancanti, stile incoerente e possibili errori sintattici. È un ottimo strumento e va tenuto. Ma vive sulla superficie del codice, non sul suo significato.

Un linter non sa che il tuo campo median_income dovrebbe valere 18.004 e non 18.400. Non sa che un valore sconosciuto non dovrebbe diventare zero. Non sa che un grafico è disegnato al contrario, perché per lui è codice valido che produce un'immagine valida. Non conosce le regole del tuo dominio, quindi non può accorgersi quando le violi.

La fonte lo dice con precisione: alcuni errori falliscono "in verde", cioè non fanno diventare rosso nessun controllo automatico. Sono proprio questi i più pericolosi, perché tutti gli strumenti automatici che hai in pipeline continuano a dirti che va tutto bene. Il linter certifica la forma. Il verdetto che ti manca riguarda la sostanza.

È la differenza tra "questo codice è scritto in modo pulito" e "questo codice fa la cosa giusta". Il primo lo copre il linter. Il secondo no, e nemmeno una suite di test che verifica soltanto che un output esista.

Cosa fare questa settimana

Non serve riscrivere tutto. Serve chiudere il buco del verdetto, partendo dai punti dove un errore silenzioso farebbe più danni.

1. Elenca le funzioni del tuo repository che calcolano numeri o trasformano dati: aggregazioni, conversioni, gestione di valori mancanti. Sono i candidati più probabili a un errore "in verde".
2. Per due o tre di queste, verifica a mano un risultato reale contro un valore che conosci con certezza. Se non hai un valore di riferimento, questo di per sé è già un segnale.
3. Controlla come il codice gestisce i valori mancanti: diventano zero, stringa vuota, null? Ogni valore mancante trasformato in un default silenzioso è un potenziale errore che nessun test intercetta.
4. Ordina un audit del repository per avere un verdetto esterno prima che a trovarlo sia un utente. Dato che qui affrontiamo un problema tecnico specifico, la logica che produce risultati plausibili ma sbagliati, il piano indicato è Diagnostic, che ti dà file, riga ed evidenze.

L'AI ti ha fatto risparmiare tempo nello scrivere il codice. Investine una parte per sapere in che stato è davvero. Richiedi il tuo audit su VibeInspect e trasforma un "sembra funzionare" in un verdetto che puoi mostrare.