Code review umana in 15 minuti sul codice ChatGPT e Cursor

Hai generato codice con ChatGPT o Cursor? Ecco una code review umana in 15 minuti: ordine di lettura, cosa cercare e quando fermarti, senza tool automatici.

Hai chiesto a ChatGPT un modulo di login, o hai premuto Accept su una decina di file in Cursor. L’istinto è avviare il server, vedere se «si vede», e fare commit.

Fermati un attimo.

Il codice da vibe coding porta rischi tipici — scorciatoie, config deboli, confini confusi. Non puoi però passare due ore su ogni riga prodotta in due secondi: perderesti il vantaggio del flusso.

Serve un metodo. Qui: code review umana in 15 minuti sul diff appena generato. Non è un penetration test e non certifica l’app. Serve a intercettare le falle più evidenti prima di produzione o di un repo pubblico. Complementa il catalogo delle 7 falle e il kickoff con vincoli.

Cosa è (e cosa non è) questa review

Mirata a un diff (una sessione / un Accept), non a un monorepo da 50k righe.

Non sostituisce npm audit / scansioni dipendenze: quelli restano per i pacchetti noti (guida npm audit). I tool non sanno se l’IA ha salvato password in un .txt. L’occhio, nei punti giusti, sì.

⚠️ Attenzione — Auto-revisione IA
Non chiedere all’assistente «il codice che hai scritto è sicuro?». Può confermare le proprie scelte. Il perimetro lo tracci tu.

Minuto 0 — Setup

1. Isola le modifiche — Source Control in VS Code/Cursor: solo file creati/modificati nell’ultimo giro.
2. Conta i file — Se ne ha toccati decine per una sola feature, la review da 15 minuti non basta. Annulla e chiedi passi piccoli (allineato all’architettura a moduli).
3. Parti il timer.

La review in 5 blocchi

Gerarchia di rischio: prima danni immediati, poi logica.

Minuti 0–3 — Segreti e env

Cosa cercare nel diff:

• Connection string con user:password@… nei sorgenti
• Chiavi tipo sk-… / token hardcodati invece di os.getenv / process.env
• .env creato ma non escluso da .gitignore
• Path assoluti personali (C:\Users\…, /Users/nome/…) finiti nei commenti o nei config di esempio

Credenziali reali in chiaro → stop. Togli, ruota se sono uscite dalla macchina (chat, gist, screen share), imponi env. Il pattern «mai secret nel sorgente» è già nel kickoff.

Esempio tipico da rifiutare: una funzione get_client() che costruisce l’URL del DB con password letterale «per farmi partire». Funziona in locale; è una bomba nel commit.

Minuti 3–7 — Rete, TLS, binding, CORS

• verify=False (Python) / rejectUnauthorized: false (Node)
• Bind 0.0.0.0 invece di 127.0.0.1 / localhost senza bisogno
• Access-Control-Allow-Origin: * su API con dati (approfondimento: CORS e asterisco)

Dettaglio pattern: 7 falle codice IA.

Minuti 7–10 — File I/O e shell

• Path da input utente concatenati senza normalizzazione (path traversal: ../../etc/passwd o equivalente Windows)
• Download/upload che prendono il nome file dal client e lo scrivono «dove capita»
• Sovrascritture silenziose non volute
• subprocess / exec / shell=True con pezzi di input nel comando

Se vedi shell=True + stringa costruita con f-string/interpolazione da request: trattalo come allarme rosso, anche se «è solo un tool interno».

Minuti 10–13 — Auth, sessioni, privilegi

• Delete/update senza check «il record è di questo utente?»
• Cookie di sessione senza HttpOnly / Secure (vedi cookie di sessione)
• Hash password fai‑da‑te (MD5/SHA‑1 «per nascondere») invece di bcrypt/Argon2

Minuti 13–15 — Dipendenze e buchi

• Nuove voci in requirements.txt / package.json: serve davvero? È nota?
• except Exception: pass / catch vuoti che inghiottono errori
• Log di secret (print(token), console.log(password))

💡 Consiglio pratico
Salta CSS/layout/traduzioni pure. Tempo solo dove ci sono dati, rete, file, auth.

Grep / Find in Files — stringhe spia

Ctrl+Shift+F (Windows/Linux) o Cmd+Shift+F (macOS). Un termine alla volta:

password=
api_key
sk-
verify=False
rejectUnauthorized
0.0.0.0
Access-Control-Allow-Origin
shell=True
eval(
exec(
console.log(password
print(token

Da terminale (macOS/Linux, o Git Bash su Windows), esempio:

rg -n "verify=False|shell=True|0\.0\.0\.0|rejectUnauthorized" .

(Equivalente con grep -rn se non hai rg.)

Regola dello stop — verdetto

ℹ️ Nota / Prerequisito operativo — Regola dei 3 errori
Tre o più difetti architetturali gravi in 15 minuti → ferma. Il modello ha preso una direzione sbagliata. Rifiuta, stringi i vincoli, rigenera a pezzi.

Sulla domanda «l’IA scrive codice sicuro al 100%?» resta l’approfondimento sui limiti.

Domande Frequenti (FAQ)

Come faccio una code review veloce sul codice di ChatGPT?

Diff in editor → ordine: segreti → rete/TLS/CORS → file/shell → auth → dipendenze. Poi Find in Files sulle stringhe spia.

15 minuti bastano sempre?

No. Bastano per una feature / un set ridotto di file. Un monorepo intero va spezzato.

Meglio review umana o auto-revisione IA?

Umana per logica e confini. Tool automatici per dipendenze. L’IA può giustificare sé stessa.

Prima cosa in assoluto?

Segreti hardcodati e .env non ignorato da Git.

Devo essere un esperto di sicurezza?

No, ma leggere assegnamenti, HTTP e aperture file. Il metodo dà l’ordine; la disciplina fa il resto.

Cosa faccio se Accept ha già mescolato 40 file?

Undo / ripristina, spezza i task, riparti da kickoff + un modulo alla volta.

Devo usare anche tool automatici?

Sì, in parallelo: review umana sul tuo diff; npm audit / equivalenti sulle dipendenze. Non sono sostituti l’uno dell’altro.

Dove metto questa routine nel flusso vibe coding?

Dopo ogni Accept «grosso» (auth, file, rete, pagamenti). Prima del commit e prima di esporre una porta. Il kickoff riduce i pasticci; i 15 minuti li intercettano quando passano comunque.

Letture opzionali

• Vibe coding: rischi che non vedi
• 7 falle di sicurezza nel codice IA
• Prompt di avvio con vincoli
• Prompt di sicurezza: generici vs checklist misurabili
• Refactoring automatico con AST, Ruff e Rope
• L’AI scrive codice sicuro al 100%?
• CORS e asterisco
• Dipendenze e npm audit