L'AI non va giudicata da quanto genera, ma dal codice che ti lascia in produzione

L'AI non va giudicata da quanto genera, ma dal risultato che lascia

Un punto interessante emerge da un articolo pubblicato su dev.to, R.A.H.S.I. Assured Outcomes: il valore di un sistema AI non si misura da quanto contenuto riesce a produrre, ma dalla capacità di generare risultati che un'organizzazione possa valutare, tracciare, governare e difendere nel tempo.

È un concetto che nasce nel mondo enterprise degli agenti, ma tocca un nervo scoperto per chiunque scriva software con l'AI. Un'esecuzione andata a buon fine non è automaticamente un'esecuzione corretta. Il fatto che l'AI abbia prodotto qualcosa non dimostra che quel qualcosa sia affidabile, spiegabile e sicuro.

Se applichi questa idea al codice, il messaggio è netto: la quantità di funzionalità generate non ti dice nulla sulla loro qualità. E questo cambia il modo in cui dovresti guardare al tuo repository.

Cosa significa se il tuo codice l'ha scritto Lovable

Con Lovable puoi passare da un prompt a un'app funzionante in poche ore. Vedi la schermata, clicchi, i dati compaiono: sembra tutto a posto. È esattamente il tipo di "esecuzione riuscita" che l'articolo mette in discussione. Funziona, ma non sai come è stato prodotto quel risultato, né cosa succede sotto la superficie.

Il punto critico più frequente in questi stack è l'autorizzazione a livello di dati. Lovable si appoggia spesso a un backend con database Postgres e policy di Row Level Security. Il generatore crea le tabelle, espone le API e collega la UI, ma le regole di accesso ai dati vengono lasciate in uno stato permissivo o addirittura disattivate per "far funzionare le cose".

Il risultato è un'app che si comporta perfettamente durante la demo e che, in produzione, permette a un utente qualsiasi di leggere le righe di un altro utente cambiando un identificativo nella richiesta. Nessun crash, nessun errore rosso. Solo dati che escono da dove non dovrebbero. È la differenza esatta tra un'esecuzione riuscita e un'esecuzione corretta.

Perché ora ti serve un audit

L'articolo di partenza ragiona su una catena precisa: usare, eseguire, valutare, tracciare, governare, dimostrare valore. Trasferita al tuo repository, questa catena si ferma quasi sempre al primo anello. Hai usato Lovable, l'app gira, ma nessuno ha mai valutato cosa è stato realmente prodotto né raccolto le evidenze per dimostrarlo.

Un audit serve proprio a chiudere quel divario. Non per rifare il lavoro dell'AI, ma per darti un verdetto su ciò che hai già in produzione. Vuoi sapere se le policy RLS coprono davvero tutte le tabelle sensibili, se esistono endpoint che restituiscono dati senza controllo sul proprietario, se una richiesta manipolata può aggirare le difese.

VibeInspect nasce per questo. Carichi lo ZIP del repository, il codice viene analizzato da specialisti AI e ricevi un PDF con un verdetto. Non gira nessun server, il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice e non promette sicurezza assoluta: ti dice in che stato è davvero il tuo progetto, con evidenze che puoi mostrare a un socio, a un cliente o a un investitore.

È la parte che manca alla maggior parte dei progetti nati con strumenti AI: non la generazione, ma la prova che il risultato regge.

Cosa un linter non vede

È facile confondere un linter con un controllo di sicurezza. Un linter analizza lo stile, la sintassi, le variabili inutilizzate, gli import mancanti. È utile, ma ragiona sulla forma del codice, non sul comportamento del sistema quando qualcuno lo usa in modo ostile.

Un linter non sa che una tabella Postgres è esposta senza Row Level Security. Non capisce che l'endpoint che restituisce un ordine non verifica se quell'ordine appartiene a chi lo sta chiedendo. Non distingue tra una query autorizzata e un accesso indebito, perché per lui sono entrambe righe di codice formalmente valide.

Proprio come una sessione andata liscia non dimostra che l'AI abbia costruito qualcosa di solido, un linter verde non dimostra che il tuo repository sia sicuro. Sono due segnali che misurano cose diverse. Il codice generato con Lovable può superare ogni controllo di stile e restare vulnerabile a un accesso non autorizzato ai dati, perché il problema non è nella sintassi: è nella logica di autorizzazione.

Serve un'analisi che ragioni sul comportamento, non solo sulla forma. Che chieda: cosa succede se un utente prova a leggere dati che non gli appartengono? Questa è la domanda che nessun linter formulerà mai al posto tuo.

Cosa fare questa settimana

Non serve riscrivere l'applicazione. Serve smettere di misurare il tuo progetto da quanto codice hai generato e iniziare a chiederti se quel codice produce risultati corretti e difendibili.

Parti da tre passaggi concreti. Primo: apri il tuo backend e verifica quali tabelle contengono dati di utenti diversi e se hanno la Row Level Security attiva. Secondo: prendi un endpoint che restituisce dati privati e prova a richiamarlo cambiando l'identificativo, per vedere se ottieni informazioni che non dovresti. Terzo: annota ogni punto in cui non sei sicuro di come il codice decida chi può leggere cosa.

Quando hai la lista dei dubbi, trasformala in un verdetto documentato. Carica lo ZIP del tuo repository su VibeInspect e chiedi un'analisi mirata sulle autorizzazioni e sull'accesso ai dati. Il piano Diagnostic ti indica file, riga ed evidenze dei problemi trovati, così sai esattamente dove intervenire prima che sia un utente a scoprirlo al posto tuo.