Chiedere a Claude Code di rivedere le modifiche non basta: il tuo repo va verificato

Un buon prompt trova i bug, ma non ti dà un verdetto sul repository

In una guida pubblicata su dev.to, "The Prompting Gap Is the Only Gap Left", l'autore raccoglie decine di prompt per Claude Code e mostra un pattern preciso: puoi chiedere all'assistente di rivedere le modifiche non ancora committate e segnalare tutto ciò che sembra rischioso prima di fare commit.

È un consiglio sensato. Un modello che legge il tuo diff prima del commit intercetta parecchie sviste. Ma c'è una differenza enorme tra "l'AI ha guardato le mie ultime righe" e "qualcuno ha dato un verdetto sullo stato dell'intero repository che ho messo in produzione".

Il prompt lavora sul frammento che gli metti davanti. Non conosce ciò che è già finito nella cronologia dei commit, non sa cosa gira in produzione da settimane, non ha una visione d'insieme delle dipendenze e dei permessi. Chiedere una review sulle modifiche in corso è una buona abitudine. Non è un audit.

Cosa significa se il tuo codice l'ha scritto Cursor

Se hai costruito il tuo prodotto con Cursor, probabilmente hai lavorato per iterazioni rapide: chiedi una funzione, la accetti, passi alla successiva. In questo ritmo un problema si infila senza fare rumore più spesso di quanto pensi: i segreti esposti.

Una chiave API, un token del database, la stringa di connessione a un servizio esterno. Cursor, per farti andare veloce, tende a scrivere valori direttamente nel codice o in file che poi finiscono committati. Capita che una chiave venga hardcodata in un file di configurazione, che un .env non sia nel .gitignore, che un token di test resti in un componente frontend visibile nel bundle servito al browser.

Il punto è che il prompt di review "prima del commit" non ti protegge da un segreto che hai già committato tre settimane fa. Quel valore è ormai nella cronologia di Git, e resta lì anche se lo cancelli in un commit successivo. Se il repo è pubblico, o se lo diventa, chiunque lo può recuperare. Questo è il tipo di problema che un singolo prompt su un diff non vede, perché guarda solo il presente.

Perché ora ti serve un audit

Un audit è diverso da una review episodica per una ragione semplice: cambia la domanda. La review chiede "queste righe vanno bene?". L'audit chiede "in che stato è tutto il codice che ho pubblicato?".

Quando lanci un prodotto costruito con l'AI, la seconda domanda è quella che conta. Non ti serve sapere se l'ultima funzione è pulita: ti serve sapere se da qualche parte, in mezzo a centinaia di file generati in fretta, c'è una chiave esposta, un endpoint senza controllo, una configurazione che espone dati.

VibeInspect nasce esattamente per questo. Carichi lo ZIP del tuo repository, degli specialisti AI lo analizzano e ricevi un PDF con un verdetto. Nessun server da configurare, e il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice al posto tuo e non promette sicurezza assoluta: ti dà una fotografia onesta di dove sei.

Per un problema tecnico specifico come i segreti esposti, quello che vuoi non è solo uno score generale. Vuoi sapere quale file e quale riga contengono la chiave, con l'evidenza in mano. Il piano Diagnostic di VibeInspect ti dà file, riga ed evidenze, così sai dove intervenire senza cercare a tentoni in tutto il progetto.

Cosa un linter non vede

È facile pensare che il linter copra già questi casi. Non è così.

Un linter controlla lo stile e la coerenza del codice: variabili non usate, import mancanti, formattazione, pattern sintattici che possono generare errori. Fa un ottimo lavoro su quel piano. Ma un linter non sa distinguere una stringa qualsiasi da una chiave API valida. Per lui "sk-live-a8f..." è solo testo dentro una variabile. Non capisce che quel testo è un segreto reale che non dovrebbe stare nel repository.

Allo stesso modo, un linter non guarda la cronologia di Git. Non ti dice che un token è stato committato e poi rimosso, lasciando comunque traccia recuperabile. Non valuta se un file di configurazione con credenziali è escluso dal versionamento. Non ragiona sul contesto: se una chiave finisce in un file che viene incluso nel bundle frontend, il linter non alza la mano, perché sintatticamente è tutto corretto.

Qui sta il limite di fondo. Il codice generato con Cursor può passare il linter senza un errore e contenere lo stesso un segreto pronto a essere abusato. La qualità sintattica e la sicurezza non sono la stessa cosa, e nessuno strumento che guarda solo la forma può darti un verdetto sulla sostanza.

Cosa fare questa settimana

Non serve una revisione dell'intera architettura. Servono pochi passi concreti, subito.

1. Apri il tuo repository e cerca stringhe sospette: api_key, secret, token, password, stringhe di connessione. Guarda anche i file di configurazione e i componenti frontend.
2. Verifica che .env e ogni file con credenziali siano nel .gitignore. Se non lo erano, controlla se sono già stati committati.
3. Se trovi un segreto nella cronologia, considera quella chiave compromessa: ruotala subito sul servizio che la emette, non limitarti a cancellarla dal codice.
4. Fai una verifica d'insieme. Carica lo ZIP del repo su VibeInspect e ottieni un verdetto che ti dica, con file e riga, dove hai segreti esposti o altri problemi concreti.

Usare Cursor non è il problema. Il problema è pubblicare senza sapere in che stato è davvero il codice. Un prompt che rivede il tuo diff è un buon gesto quotidiano; un audit ti dà la certezza prima che sia troppo tardi.

Se vuoi capire esattamente dove sono i tuoi segreti esposti, con file, riga ed evidenze, parti dal piano Diagnostic di VibeInspect.