Perché il Codice Generato dall'AI Ha Bisogno di una Revisione Umana (E Perché Va Bene Così)

Oggi lo sviluppo software corre velocissimo. Strumenti come Claude o ChatGPT ti portano da un'idea a un'app funzionante in pochi giorni. Descrivi la feature, accetti le modifiche, iteri e pubblichi. Un boost incredibile per la produttività.

C'è però un intoppo.

Ho passato un pomeriggio a rivedere codice nato proprio così: uno strumento interno semplice, non critico, ma tipico di come molti team lavorano nel 2024. Non ho trovato mostri tipo "l'AI ha impazzito". Piuttosto, 28 problemi sparsi, quasi tutti legati alla security. Vulnerabilità classiche, da OWASP Top 10 degli anni 2000.

Non è l'AI a essere il villain. È la velocità che supera il ragionamento strutturato, lasciando buchi che diventano rischi.

Il Vero Guasto Non È l'AI, Ma la Domanda che Manca

Il codice era solido. Architettura pulita, componenti ben divisi, librerie azzeccate. Se l'avessi scritto io in un weekend, sarebbe sembrato uguale.

Il problema sta nel livello superiore. Quelle riflessioni prima di toccare la tastiera.

L'AI eccelle in ciò che le chiedi. "Fammi un sistema di gestione utenti", e eccolo lì. Ma non ti sollecita: chi accede? Quali dati sono sensibili? L'autenticazione dove sta? E se aggirano il frontend?

L'AI sforna feature. Non l'architettura sicura che ti fa dormire sonni tranquilli.

Esempio Concreto: La Funzione Admin Senza Difese

Immagina una serverless function per operazioni admin: crea utenti, resetta password, cancella account. Logica server-side per le credenziali potenti, niente nel browser. Bravi.

Mancava ogni controllo di autenticazione.

Zero. Niente di debole o sbagliato. Assolutamente assente. Chiunque aprisse DevTools, trovasse l'endpoint e mandasse una POST poteva fare danni enormi.

Sul frontend c'era un check che nascondeva il bottone agli utenti normali. Sembrava sicuro. Inutile: la security via UI è un'illusione.

Authorization bypass puro, in lista vulnerabilità dal 2003. L'AI non l'ha segnalato perché il prompt era "funzione per admin che crea utenti". La fa. E lascia fare a tutti, perché non hai specificato di no.

Lezione chiave: l'AI non indovina i tuoi buchi.

Il Database Sicuro Solo Sulla Carta

Altro caso comune. Il database ha row-level security (RLS) per limitare accessi per riga, in base all'utente. Ottimo, specie con API key nel frontend JavaScript.

Un ingegnere chiede all'AI di aggiungere supporto multi-utente. Lei crea tabelle nuove con RLS attivo. Perfetto.

Le cinque tabelle esistenti – i tuoi dati veri – restano intoccate. RLS attivo? No? La migration non controlla, non attiva, non avverte.

Lanci npm run db:push su infra fresca: nuove tabelle blindate, vecchie aperte a chiunque con connessione e URL.

L'AI non sbaglia. È solo parziale. Risolve il compito stretto, senza far emergere assunzioni implicite (vuoi blindare tutto?).

Cosa Cambia nel Tuo Flusso di Lavoro

Non sto contro l'AI-assisted dev. La velocità conta. Iterare e shippare rapido è oro. Ma obbliga a review umane sulle scelte architetturali, non solo sintassi.

Ecco cosa funziona:

Crea una checklist security prima di partire. Domande tipo: chi chiama questo endpoint? Cosa se lo chiama senza permessi? I dati sono pubblici? Ogni tabella ha RLS? Documentale, non scoprile dopo.

Senior per threat modeling, non riga per riga. I miei 28 issue erano lacune strutturali, non refusi. AI per generare codice, umani per security thinking.

Rendi auth e auth espliciti nei prompt. Non "endpoint gestione utenti", ma "endpoint gestione utenti solo per admin loggato, documenta assunzioni auth". Spinge l'AI a ragionare.

Testa auth separati dalla funzione. Verifica che non-autenticati non possano agire, non solo che autenticati possano.

Il Pattern da Capire

L'AI non produce codice insicuro di suo. È maestra nel fare esattamente ciò che chiedi, e cieca su ciò che ometti.

È un pregio: segue i tuoi input senza inventare. Ma sposta il peso su di te. Non deleghi la security all'AI. La esegue su tuo design.

Nel codice rivisto, bastava un umano che dicesse "questo endpoint vuole auth". Fix in minuti. Vulnerabilità vecchia di 20 anni contro workflow 2024: vince il workflow, ma solo con occhi esperti.

Modello sostenibile: AI per velocità, umani per architettura. Entrambi indispensabili.

Vuoi evitare questi tranelli nel tuo codice? Da NameOcean vediamo startup crescere con debito tecnico da feature velocissime. La nostra piattaforma di cloud hosting ha security strutturale incorporata: rate limiting, gestione API key, audit logging sempre attivi, prompt o no. Un worry in meno mentre shippi a razzo.