Il revisore AI che ti approva il codice cambia idea a ogni run

Lo stesso codice, due verdetti diversi: il revisore AI non è deterministico

Un esperimento pubblicato su dev.to ha misurato una cosa che molti sospettano ma pochi verificano: mandare due volte la stessa pull request a un revisore AI produce due liste di problemi diverse. Come sintetizza l'autore in "Your AI Reviewer Disagrees With Itself. Measure the Drift.", la sovrapposizione tra due passaggi sullo stesso diff oscilla tra il 60% e il 90%. Tradotto: una fetta consistente delle segnalazioni esiste in una sola delle due esecuzioni.

La causa è tecnica e non aggirabile con qualche trucco. Gli endpoint dei modelli sono campionatori, non tabelle di lookup. Anche impostando la temperatura a zero, il server condiviso applica batching, load balancing e sampling lato provider. Il verdetto che ricevi non è una fotografia stabile del tuo codice: è un'estrazione, e la prossima estrazione può essere diversa.

Questo ha una conseguenza diretta per chiunque abbia costruito un prodotto affidandosi a suggerimenti e revisioni generati da un modello. Se il giudizio automatico sul tuo codice è instabile, la sicurezza che percepisci quando "passa il review" è in parte illusoria.

Cosa significa se il tuo codice l'ha scritto Cursor

Quando lavori dentro Cursor, il flusso è confortevole: descrivi cosa vuoi, il modello genera, tu leggi il diff, l'assistente ti rassicura che va bene, tu accetti. Il problema è che quella rassicurazione ha lo stesso difetto misurato nell'esperimento. Chiedi due volte allo stesso modello se una funzione è sicura e potresti ricevere due risposte diverse, entrambe convincenti.

Prendi un caso concreto e ricorrente: la gestione delle autorizzazioni. Cursor ti scrive un endpoint che carica una risorsa a partire da un ID passato nella richiesta. In un passaggio il modello nota che manca un controllo su chi possiede quella risorsa e ti segnala un potenziale IDOR. In un altro passaggio, con lo stesso codice, non dice niente e ti fa i complimenti per la struttura pulita.

Tu accetti la versione in cui non ha detto niente. Il codice va in produzione. L'IDOR resta lì: un utente autenticato che cambia l'ID nella richiesta accede ai dati di un altro utente. Non è un bug esotico, è una delle falle più comuni nelle app costruite in fretta. E il tuo revisore AI, quel giorno, aveva pescato il campionamento sbagliato.

Il punto non è che hai usato Cursor. Cursor accelera un lavoro reale. Il punto è che ti sei fidato di un verdetto singolo e variabile come se fosse un giudizio stabile. Nessuno ti ha dato una fotografia ripetibile dello stato del tuo repository.

Perché ora ti serve un audit

Un audit serve proprio a colmare quel vuoto: darti un verdetto sullo stato del codice, indipendente dal singolo suggerimento che hai accettato mentre scrivevi. Quando integri un modello nel tuo flusso di sviluppo, quel modello è parte del tuo team, ma è un membro del team che oggi ti dice una cosa e domani un'altra. Non puoi fondare l'affidabilità di un prodotto su un giudizio che si contraddice.

VibeInspect nasce per questo scenario. Carichi lo ZIP del tuo repository, degli specialisti AI analizzano il codice e ricevi un PDF con un verdetto. Non gira nessun server tuo: il sorgente viene cancellato al termine dell'analisi. Non è un pentest e non promette sicurezza assoluta, ma ti restituisce qualcosa che il review inline dentro l'editor non ti dà: una valutazione strutturata, pensata per essere letta e usata come base di decisione.

La differenza pratica sta nel tipo di domanda a cui rispondi. Dentro Cursor la domanda è "questo diff va bene?", e la risposta arriva un pezzo alla volta, con la variabilità che abbiamo visto. Con un audit la domanda diventa "qual è lo stato complessivo del mio repository su temi come autorizzazioni, segreti esposti, gestione degli accessi?". È una domanda diversa, che richiede uno sguardo d'insieme e non un parere estemporaneo su una singola modifica.

Se stai affrontando un problema tecnico specifico come un possibile IDOR sugli endpoint, il livello Diagnostic ti indica file, riga ed evidenze, così sai esattamente dove guardare. Non corregge il codice al posto tuo e non c'è revisione umana a questo livello, ma ti mette davanti le prove concrete invece di un'opinione che cambia a ogni esecuzione.

Cosa un linter non vede

A questo punto potresti pensare che basti un buon linter nella pipeline. Non basta, e vale la pena capire perché. Un linter ragiona sulla forma: stile, variabili non usate, import mancanti, pattern sintattici vietati. Applica regole sul modo in cui il codice è scritto, non sul significato di ciò che fa a runtime.

Un linter non capisce che quell'ID nella richiesta appartiene a una risorsa che dovrebbe essere filtrata per proprietario. Non sa che manca il controllo su chi può accedere a quel dato. L'endpoint con l'IDOR passa il linter senza una sola segnalazione, perché sintatticamente è perfetto: indentazione corretta, nessuna variabile morta, tutto in ordine. La falla vive nella logica di autorizzazione, non nella forma.

Qui torna utile ricordare la distinzione emersa dall'esperimento sulla fonte: stabilità non è qualità. Un revisore stabile può sbagliarsi con sicurezza, e un revisore instabile può azzeccare un problema solo a volte. Un audit come VibeInspect punta a darti entrambe le cose che ti mancano: uno sguardo semantico su cosa fa il codice e un verdetto che puoi rileggere, non un parere che si dissolve al passaggio successivo.

Cosa fare questa settimana

Parti da un'azione piccola e concreta. Apri il tuo repository e cerca gli endpoint che caricano una risorsa a partire da un ID passato dal client. Per ognuno, verifica a mano se esiste un controllo che leghi quella risorsa all'utente autenticato. Se non lo trovi, hai probabilmente un IDOR e non un problema di stile.

Poi smetti di affidarti al giudizio singolo dell'assistente dentro Cursor come se fosse definitivo. Quel verdetto è utile mentre scrivi, ma non è una fotografia affidabile dello stato complessivo del codice che hai già pubblicato. Ti serve una valutazione ripetibile e leggibile.

Carica lo ZIP del tuo repository su VibeInspect e chiedi un audit Diagnostic: ottieni file, riga ed evidenze sui punti in cui la logica di autorizzazione lascia scoperti i tuoi dati. È il modo più rapido per trasformare un sospetto in una lista di problemi verificati su cui lavorare davvero.