Come revisionare il codice generato dall’IA

Per revisionare il codice generato dall’IA, inizia da ciò che è cambiato — quali file e perché — poi testa tu stesso il comportamento prima di leggere qualsiasi riga di codice. Dopodiché controlla le aree in cui il codice dell’IA sbaglia più spesso: controlli dei permessi lato server mancanti, segreti esposti al browser, input non validati, pacchetti o funzioni che non esistono, e modifiche a cose che non gli avevi chiesto di toccare.

L’IA scrive codice che di solito funziona e spesso sembra ordinato. Questo rende facile approvarlo senza controllarlo davvero. Questa guida è una routine di revisione che funziona sia che tu legga il codice con disinvoltura, sia che non lo legga affatto.

Commisura la revisione al rischio

Non ogni modifica richiede la stessa attenzione.

Passo 1: vedi cosa è cambiato

Prima di giudicare il codice, ottieni l’elenco delle modifiche:

• Se il progetto è in Git, guarda il diff: i file e le righe cambiate dall’ultimo commit. Vedi come usare Git con un’app creata con l’IA.
• Oppure chiedi direttamente all’IA:

Elenca ogni file che hai modificato nell’ultima modifica, e per ciascuno spiega in una frase cosa è cambiato e perché.

Segnali d’allarme in questa fase: file non collegati alla richiesta, file eliminati, modifiche alla configurazione o alle dipendenze che non avevi chiesto.

Passo 2: testa prima il comportamento

Leggere il codice ti dice cosa dovrebbe fare; testarlo ti dice cosa fa davvero. Prima di leggere:

• Prova la modifica come un utente normale, su desktop e su uno schermo di dimensioni da telefono.
• Prova con input sbagliati: campi vuoti, testi molto lunghi, numeri negativi, una data nel passato.
• Provala senza essere connesso e come un utente diverso.
• Ripeti i flussi più importanti: registrazione, login, l’azione principale, pagamento.

Se il test fallisce, hai risparmiato tempo di lettura — segnalalo chiaramente e lascia che l’IA lo corregga. Vedi come scrivere una buona segnalazione di bug.

Passo 3: controlla i permessi sul server

La cosa più importante da verificare. Gli strumenti IA spesso nascondono un pulsante nella pagina ma lasciano il server pronto a eseguire l’azione per chiunque la chieda.

Per ogni rotta o funzione che legge o modifica dati, chiediti:

• Verifica che l’utente sia connesso?
• Verifica che questo utente possa accedere a questo record?
• Quel controllo è sul server, non solo nella pagina?

Per ogni rotta API che hai aggiunto o modificato, dimmi quale controllo dei permessi fa sul server, citando la riga. Segnala ogni rotta che non ne ha uno.

Poi testalo: accedi come utente A, annota l’ID di un record, accedi come utente B e richiedilo. La checklist di sicurezza per le app create con l’IA contiene il test completo.

Passo 4: cerca segreti esposti

• Cerca nei file modificati qualsiasi cosa che assomigli a una chiave o a una password.
• Verifica che le chiavi segrete vengano lette da variabili d’ambiente e usate solo nel codice server.
• Fai attenzione ai prefissi pubblici come VITE_ o NEXT_PUBLIC_ sulle variabili segrete — quelli finiscono integrati nel codice del browser.

Vedi come proteggere le chiavi API.

Passo 5: controlla input ed errori

• Validazione sul server. I controlli nel browser possono essere aggirati. Campi obbligatori, lunghezze, formati e valori consentiti devono essere verificati anche dal server.
• Le query al database usano parametri, non testo costruito unendo l’input dell’utente in una query.
• Gli errori non vengono ignorati. Un try/catch che non fa nulla nasconde i guasti. Gli errori devono essere registrati, e agli utenti va mostrato un messaggio semplice.
• Nessun dettaglio interno mostrato agli utenti — stack trace ed errori del database appartengono ai log.

Passo 6: verifica che sia reale

I modelli IA a volte producono codice che sembra corretto ma si riferisce a cose che non esistono.

• Pacchetti: ogni nuova dipendenza deve essere un pacchetto reale, mantenuto, con esattamente quel nome. Diffida dei nomi che sembrano errori di battitura di quelli popolari.
• Funzioni e opzioni API: se il codice chiama una funzione di libreria o un’opzione di un’API esterna che non hai mai visto, controlla la documentazione ufficiale.
• Codice segnaposto: cerca TODO, mock, fake, dati di esempio scritti nel codice o funzioni che restituiscono un valore fisso.

Hai aggiunto nuovi pacchetti? Per ciascuno, indica il nome esatto, a cosa serve e se potremmo farne a meno.

Passo 7: verifica che si integri

Il codice può funzionare e rendere comunque l’app più difficile da modificare in seguito:

• Duplicazione. La stessa logica copiata in più punti si disallineerà.
• Coerenza. Deve seguire i pattern che usa il resto dell’app.
• Dimensione. Una richiesta di 20 righe che ha prodotto 600 righe merita una domanda.
• Codice morto. Versioni vecchie lasciate accanto a quelle nuove.

Ci sono parti del progetto che ora non vengono più usate a causa di questa modifica, oppure logica duplicata altrove? Non cambiare nulla; elencale soltanto.

Errori comuni

• Approvare perché sembra pulito. Il codice ordinato può comunque saltare un controllo dei permessi.
• Leggere invece di testare. Prima testa, poi leggi.
• Testare solo il percorso ideale. Prova input errati, l’utente sbagliato e l’accesso senza login.
• Ignorare modifiche a file non collegati. Chiedi perché sono cambiati tutti quei file.
• Fidarsi completamente di un’auto-revisione. Usa la revisione dell’IA come primo passaggio e confermala con i test.
• Revisionare in blocco una settimana di modifiche. Revisiona le modifiche piccole man mano che arrivano.

Checklist

• So quali file sono cambiati e perché, e nulla di non correlato è cambiato.
• La modifica funziona su desktop e telefono, con input errati, senza login e come un altro utente.
• Ogni rotta che legge dati verifica login e proprietà sul server.
• Nessun segreto nel codice o nei bundle del browser.
• L’input è validato sul server; le query usano parametri.
• Gli errori vengono registrati, non ignorati, e non mostrati nel dettaglio agli utenti.
• I nuovi pacchetti sono reali e necessari; non restano funzioni inventate o segnaposto.
• Le modifiche ad alto rischio sono state lette con attenzione e, dove serve, revisionate da una seconda persona.

Revisionare il codice su Mythex

• La modalità Ask risponde a domande sul codice senza modificarlo — ideale per richieste del tipo “spiega ogni modifica” e “quali rotte non hanno un controllo dei permessi”. Vedi Chat.
• La vista Codice mostra l’albero dei file, l’editor e il terminale su ogni piano (in sola lettura nel piano Free, modificabile nel piano Pro), così puoi leggere tu stesso cosa è cambiato. Vedi Editor del codice.
• /test fa cliccare all’agente l’anteprima come un utente e segnala i flussi rotti.
• I checkpoint ti permettono di annullare una modifica che non supera la revisione.

Se uno sviluppatore ti sta aiutando nella revisione, come lavorare con uno sviluppatore su un’app creata con l’IA spiega il passaggio di consegne; se la revisione fa emergere un bug, vedi come fare debug di un’app creata con l’IA.

Domande