Codice generato dall’AI: 7 controlli per non programmatori
MarkdownL’IA ha scritto il codice, ma non sai leggerlo? Una checklist pronta all’uso con 7 controlli e prompt per individuare codice difettoso e falle di sicurezza prima della pubblicazione.
Leggi l’articolo completo
Punti chiave
L’IA scrive il codice per te in pochi minuti, ma ora tocca a te controllarlo. La scrittura del codice in sé non è più il collo di bottiglia. Ora conta quanto bene capisci il compito e quanto bene sai controllare il risultato. Di seguito trovi 7 controlli per individuare codice difettoso, falle di sicurezza e invenzioni dell’IA prima di mostrare il tuo progetto a qualcuno. Non devi saper leggere il codice.
L’IA ti ha messo insieme un sito web o un bot in una serata. Si apre tutto, i pulsanti funzionano e sembra andare. Mostri il progetto alle persone e, un giorno dopo, scopri che il modulo di pagamento addebita i soldi, ma gli ordini non arrivano. Oppure che il database con i numeri di telefono dei clienti è accessibile a tutto internet.
Anch’io spedivo così i miei primi progetti: cose che sembravano funzionare riservavano sorprese agli utenti reali. Ora, prima di mostrare qualsiasi cosa alle persone, passo il progetto attraverso la stessa checklist. Non leggo una sola riga di codice mentre lo faccio: non è per questo che sono qui, e probabilmente neanche tu.
E non è paranoia. Anthropic ha analizzato 400.000 sessioni di Claude Code: in sette mesi, la quota di lavoro dedicata a correggere codice difettoso è scesa dal 33% al 19%. È diminuita, ma non è scomparsa. Una sessione su cinque riguarda ancora «correggi ciò che l’IA ha rotto».
La scrittura del codice in sé non è più il collo di bottiglia. Ora conta quanto bene capisci il compito e quanto bene sai controllare il risultato.
Altri materiali sulla configurazione degli strumenti sono disponibili nella documentazione di Ailoot.
Perché controllare il codice generato dall’IA se funziona già?
Punti chiave
«Funziona» e «funziona correttamente» sono due cose diverse. L’IA ottimizza il codice per farlo eseguire e sembrare completo, non per renderlo sicuro, economico e capace di fare esattamente ciò che volevi. Controllarlo ti protegge dalle sorprese che emergono con utenti reali.
L’IA scrive codice che a prima vista sembra a posto. Funziona, la schermata viene visualizzata e la demo è convincente. Ma avviarlo non ti dice se i calcoli dei pagamenti sono corretti, se il database è esposto all’esterno o se tutto andrà in crash quando arriverà il centesimo utente.
I numeri lo confermano. Il benchmark FrontierCode ha verificato nel giugno 2026 quanto fosse pronto per il lavoro reale, senza modifiche, il codice generato dall’IA. Anche per i migliori modelli e le attività più difficili, la quota era circa il 13%. In altre parole, nelle attività serie la maggior parte del codice generato dall’IA deve essere perfezionata a mano prima di potervi fare affidamento.
La buona notizia è che chiunque può fare questi controlli. Ecco cosa ha concluso Anthropic dalle stesse 400.000 sessioni:
Il successo dipende da quanto bene una persona comprende il compito che sta risolvendo, non dal fatto che sappia programmare.
Il tuo vantaggio rispetto a qualsiasi programmatore che coinvolgi è che capisci il tuo compito. Anche controllare richiede comprensione; non devi saper leggere il codice. I controlli che seguono sono proprio quelli che puoi fare da solo, senza complicazioni.
Cosa può andare davvero storto con il codice generato dall’IA?
Punti chiave
Cinque tipi di problemi: il codice non funziona; funziona, ma non come volevi; ci sono falle di sicurezza; è costoso o lento; l’IA si è inventata qualcosa. Ognuno dei sette controlli seguenti affronta uno o più di questi rischi. È utile conoscere questi cinque tipi prima di iniziare i controlli: così sai cosa cercare in ogni fase.
Prima di controllare, è utile sapere cosa cercare. Il codice generato dall’IA presenta cinque problemi tipici, e puoi individuarli tutti senza leggere il codice, osservando come si comporta il progetto.
| Cosa non va | Come te ne accorgi |
|---|---|
| Non funziona | Un pulsante non risponde, la pagina è vuota, «errore 500» |
| Funziona in modo errato | Il pagamento va a buon fine, ma non viene creato alcun ordine; l’email arriva alla persona sbagliata |
| Falla di sicurezza | Una chiave segreta è visibile nel codice; il database è aperto; il modulo si può compromettere con un input |
| Costoso o lento | Il sito impiega 10 secondi a caricarsi; a fine mese arriva una fattura per l’API di IA |
| L’IA si è inventata qualcosa | Fa riferimento a uno strumento inesistente; ha usato dati di prova invece di dati reali |
Seguono sette controlli, in ordine. I primi individuano i casi in cui «non funziona» e «funziona in modo errato»; quelli centrali riguardano sicurezza e invenzioni; gli ultimi sono misure di protezione prima della pubblicazione. È meglio procedere in sequenza: ognuno si basa sul completamento del controllo precedente.
Controllo 1: chiedi all’IA di spiegare il suo codice in parole semplici
Punti chiave
La prima cosa che faccio è chiedere all’IA di riassumere ciò che ha fatto con parole normali, senza codice. Se il riepilogo non corrisponde a ciò che avevi chiesto, il codice è già sbagliato, anche se funziona. Così controlli se l’IA ha capito il compito come l’avevi inteso tu.
Hai descritto il compito a parole. L’IA lo ha tradotto in codice. Tra questi due passaggi il significato può perdersi: l’IA potrebbe averti capito diversamente, aver completato le informazioni di propria iniziativa o aver preso scorciatoie. Puoi individuare la discrepanza senza leggere il codice: basta chiederle di descrivere in parole semplici ciò che ha fatto.
Prompt
Chiedi all’IA di spiegare cosa ha fatto
Spiega in parole semplici, senza codice, esattamente cosa hai appena fatto:
quale compito risolve questo codice
cosa succederà quando un utente fa clic sul pulsante o invia il modulo
dove sono archiviati i dati e chi può accedervi
cosa potrebbe rompersi e in quale situazione
Scrivi come se lo stessi spiegando a qualcuno che non ha mai programmato. Se c’è qualche aspetto di cui non sei sicuro, dillo chiaramente.
Leggi la risposta e confrontala con ciò che avevi in mente. Se corrisponde, passa avanti. Se l’IA «si perde in chiacchiere», si confonde nella propria spiegazione o descrive qualcosa di diverso da ciò che avevi chiesto, significa che non capisce del tutto cosa ha creato. Chiedile di rivederlo fornendo un chiarimento, invece di fidarti della sua parola.
A proposito, se l’IA fa regolarmente qualcosa di diverso da ciò che chiedi, spesso il problema è come hai formulato il compito, non il modello. Ho un approfondimento separato su perché Claude non fa ciò che chiedi.
Controllare il risultato dell’IA fa parte del context engineering: controlli sia ciò che le dai in ingresso sia il modo in cui valuti il risultato in uscita. Il toolkit comprende un clone dell’IA, un Second Brain e il Context Engineering. Dopodiché Claude smette di essere un «assistente che ha allucinazioni» e diventa uno strumento a cui puoi davvero affidare un progetto.
Controllo 2: prova gli scenari come farebbe un utente reale
Punti chiave
Apri il progetto e fai ciò che farebbe un utente: registrati, paga, invia un modulo. Poi prova deliberatamente a mandare tutto in errore: inserisci dati senza senso, fai clic due volte, lascia vuoti i campi. Metà dei problemi emerge proprio qui, senza leggere una sola riga di codice. Controlla i pagamenti separatamente e con attenzione: l’ordine è stato creato quando è stato addebitato il denaro?
Una demo dell’IA segue sempre il percorso ideale: dati corretti, un clic e tutto va bene. Un utente reale non si comporta così. Fa errori, clicca sulla cosa sbagliata o inserisce un’emoji nel campo del telefono. Il tuo compito è provare il progetto come farebbe lui.
Completa lo scenario principale dall’inizio alla fine
Fai ciò per cui esiste il progetto: registrati, effettua un ordine, invia una richiesta. Arriva fino in fondo, non fermarti a metà.
Controlla i pagamenti separatamente e sul serio
Se il progetto accetta pagamenti, effettua tu un pagamento dell’importo minimo in modalità di test. Verifica che l’ordine venga creato, che lo stato cambi e che arrivi un’email a te e al cliente. Un pagamento che «va a buon fine» ma non crea un ordine è un classico errore silenzioso.
Prova deliberatamente a mandare tutto in errore
Lascia vuoti i campi. Inserisci lettere dove sono previsti numeri. Fai clic su «Invia» due volte di seguito. Carica un file nel formato sbagliato. Un buon progetto ti dirà gentilmente «non puoi farlo»; uno fatto male andrà in crash o inghiottirà i dati senza avvisarti.
Aprilo su un telefono
Metà dei tuoi utenti arriverà da un telefono. Verifica che il layout non si sia scomposto e che gli stessi pulsanti funzionino anche lì.
Fornisci all’IA tutto ciò che hai trovato, in un unico elenco: «Ecco cosa si è rotto in questi passaggi; correggilo e spiega perché è successo». Non affrontare un problema alla volta: dalle l’elenco, così l’IA può vedere il quadro completo e ha meno probabilità di rompere una cosa mentre ne corregge un’altra.
Controllo 3: chiedi all’IA di verificare la sicurezza con questo prompt
Punti chiave
La sicurezza è ciò che un non programmatore non può vedere a occhio, ma che può fare più danni: chiavi trapelate, un database esposto, un modulo che permette a qualcuno di entrare. Non devi cercare queste cose da solo: chiedi all’IA di eseguire un audit e spiegare ogni risultato in parole semplici. Di seguito trovi un prompt pronto all’uso che controlla il progetto per le cinque falle più comuni.
Un pulsante rotto è subito evidente. Una falla di sicurezza no: il progetto continua a funzionare come se nulla fosse, finché qualcuno non ne approfitta. I problemi più comuni nei progetti realizzati con il vibe coding sono chiavi segrete scritte direttamente nel codice, un database esposto a internet e moduli che permettono di inviare input dannosi. L’IA può trovare tutto questo se glielo chiedi direttamente.
Prompt
Controlla il mio progetto per individuare falle di sicurezza
Esegui un audit di questo progetto per individuare problemi di sicurezza e spiega ogni risultato in parole semplici, senza gergo tecnico. Esamina questo elenco:
Verifica se nel codice sono scritte direttamente chiavi segrete, password o token. I segreti privati devono essere usati soltanto sul server, con configurazioni locali come .env escluse da Git. .env e .gitignore non impediscono che le variabili frontend o pubbliche finiscano nella build del browser. Esamina JavaScript, source map, HTML e risposte di rete effettivamente consegnati al client e verifica l’assenza delle chiavi private.
Verifica se il database è esposto a internet e chi può accedervi.
Verifica se gli input possono compromettere i moduli: inserimenti nelle query del database o codice aggiuntivo nei campi di testo.
Cosa succederà se un utente invia dati dannosi?
Verifica se ci sono pagine interne o il pannello di amministrazione accessibili senza password.
Per ogni punto, indica se c’è un problema, fornisci un esempio chiaro del rischio e spiega come risolverlo. Inizia dal problema più pericoloso.
Controlla anche che il progetto non esegua alla cieca qualunque cosa riceva dall’esterno. Si chiama indirect prompt injection: un comando è nascosto in un’email, in un commento o nel file di qualcun altro, e il tuo agente IA lo segue scambiandolo per un compito. Se il progetto legge dati esterni e agisce di conseguenza, chiedi all’IA cosa succederebbe se quei dati contenessero un’istruzione nascosta.
È un argomento complesso, e un solo prompt non può coprirlo del tutto. Se il progetto gestisce denaro o dati personali dei clienti, leggi la guida separata sulla sicurezza nel vibe coding.
Controllo 4: l’IA ha inventato librerie o dati?
Punti chiave
A volte l’IA fa riferimento a strumenti inesistenti e lascia dati di prova al posto di quelli reali. Sembra tutto convincente, ma poi si rompe. Una domanda diretta all’IA e un’esecuzione del progetto bastano a individuare il problema in un minuto. La stessa domanda protegge anche da codice altrui che gli aggressori camuffano usando nomi di librerie inventati.
L’IA scrive con sicurezza cose che non esistono. Può aggiungere una libreria con un nome plausibile che però non esiste davvero. Può lasciare segnaposto di prova nel progetto: un prodotto chiamato «Esempio», l’indirizzo email example@example.com o testo riempitivo al posto dei contenuti reali. È facile non accorgersene in una demo, ma per un utente reale è imbarazzante o causa malfunzionamenti.
Puoi individuarlo in due passaggi. Per prima cosa, chiedi direttamente:
Prompt
Controlla se hai inventato qualcosa
Esamina il progetto e controlla con onestà:
Tutti gli strumenti e le librerie esterni che hai aggiunto esistono davvero e si installano correttamente? Hai inventato qualcosa?
Ci sono ancora segnaposto di prova, esempi o testo riempitivo al posto dei dati reali?
Tutti i link, gli indirizzi e i recapiti nel progetto sono reali e non segnaposto?
Elenca ciò che hai trovato e suggerisci con cosa sostituirlo.
Secondo, avvia semplicemente il progetto e guardalo. Una libreria inventata provoca quasi sempre un errore all’avvio. E i segnaposto si individuano facilmente: se la pagina dice «Prodotto 1», non li hai sostituiti.
Le librerie inventate comportano un pericolo ulteriore, perché gli aggressori registrano apposta strumenti con i nomi che l’IA tende a inventare. Installane uno e il codice di qualcun altro entra nel tuo progetto. Ecco perché dovresti prendere sul serio la domanda «ma questa libreria esiste davvero?»: riguarda direttamente la sicurezza del tuo progetto.
Controllo 5: chiedi a un secondo modello di controllare il primo
Punti chiave
La stessa IA che ha scritto il codice non è una buona verificatrice: tende a darsi ragione. Affida il progetto a un altro modello per una revisione o almeno apri una nuova sessione: il punto di vista fresco individua ciò che al primo è sfuggito. È il tipo di secondo parere che chiederesti a un altro medico prima di un’operazione.
L’IA ha un tratto sgradevole: è accondiscendente. Chiedile «va tutto bene?» e confermerà che è tutto a posto perché si adatta alla risposta che si aspetta. Questo comportamento si chiama sycophancy dell’IA e ne ho parlato separatamente. Un interlocutore così sarà indulgente con il proprio lavoro.
La soluzione è semplice: chiedi un secondo parere. Apri una nuova sessione o usa un altro modello e affidagli il progetto da controllare con lo stesso prompt del Controllo 3, aggiungendo: «un’altra IA ha scritto questo codice; trova i suoi punti deboli». Un modello nuovo non è legato alla conversazione precedente ed è più propenso a segnalare i problemi.
Apri una sessione pulita o usa un altro modello
Usa un secondo modello oppure lo stesso in una nuova finestra, senza cronologia delle attività.
Fornisci il progetto e il contesto giusto
Dillo chiaramente: «un’altra IA ha scritto questo codice; il tuo compito è trovare errori e rischi, non lodarlo». Questo limita la sycophancy.
Confronta i due pareri
Se entrambi concordano, probabilmente hanno ragione. Se non sono d’accordo, approfondisci quel punto: è lì che le cose si fanno interessanti.
È esattamente ciò che sta succedendo nel settore: l’IA scrive, l’IA controlla e la decisione finale resta a una persona. Non puoi delegarla al modello: è compito tuo.
Controllo 6: come puoi annullare le modifiche se qualcosa si rompe?
Punti chiave
Prima di ogni modifica, salva in git una versione funzionante. Così, se il controllo successivo rompe qualcosa, puoi tornare indietro con un comando invece di ricostruire il progetto. È una misura di protezione che richiede dieci secondi. Non devi leggere il codice per farlo: bastano due semplici richieste all’IA.
I controlli di questo elenco spesso portano a modifiche, e a volte le modifiche rompono ciò che funzionava. Per evitare che diventi un disastro, salva in git la versione funzionante prima di ogni ciclo di correzioni. È come salvare una partita: se rompi qualcosa, carichi l’ultimo punto di salvataggio.
Non devi leggere il codice per farlo. Chiedi semplicemente all’IA: «salva la versione funzionante attuale in git con un’etichetta chiara prima di cambiare qualsiasi cosa». E se dopo le modifiche va tutto storto: «ripristina il progetto alla versione salvata in precedenza».
Se git è ancora un territorio sconosciuto, ecco due guide: come annullare le modifiche in Claude Code e cosa fare se l’IA ha eliminato il tuo database. La seconda serve quando è ormai troppo tardi per annullare le modifiche, ma puoi ancora recuperare i dati.
Controllo 7: cosa controllare per ultimo prima della pubblicazione?
Punti chiave
Ultima verifica prima della pubblicazione: i pagamenti sono passati dalla modalità di test a quella reale, i segreti privati restano sul server e fuori dai file consegnati al client, i dati hanno una copia di backup e la pubblicazione e il dominio funzionano. Controlla l’elenco breve e poi lancia il progetto. È qui che le persone perdono più spesso i primi pagamenti: il progetto funziona, ma hanno dimenticato un’impostazione.
I primi sei controlli riguardano ciò che fa il codice. Il settimo riguarda la preparazione del progetto a incontrare il pubblico. È qui che le persone inciampano più spesso: il progetto funziona, ma hanno dimenticato di passare il pagamento dalla chiave di test a quella reale, così i primi clienti pagano «per finta».
Pagamenti: da test a reali
Se accetti pagamenti, assicurati che sia collegata la chiave reale del sistema di pagamento, non quella di test. Effettua un pagamento reale dell’importo minimo e rimborsalo a te stesso.
I segreti sono al posto giusto
Chiedi all’IA: «Le chiavi private sono usate solo sul server e .env è escluso da Git? La build effettiva del browser o una risposta al client contiene una chiave privata, anche tramite variabili frontend/pubbliche o source map?» Controlla i file compilati e le risposte di rete del browser, non soltanto .env nel sorgente. L’esclusione da Git non impedisce che un valore entri nel bundle frontend.
Fai una copia di backup dei dati
Assicurati che il database venga salvato automaticamente da qualche parte. Se il progetto gira sul tuo server, spiego cosa fare per la pubblicazione nella guida a Coolify.
Verifica la pubblicazione da un dispositivo diverso dal tuo
Apri il progetto sul telefono usando un link esterno, non solo sul tuo computer. Ciò che funziona in locale non sempre funziona dopo la pubblicazione.
Completa tutti e quattro i passaggi e potrai mostrare il progetto alle persone senza preoccupazioni. Se qualcosa non torna, è meglio dedicarci mezz’ora adesso che dover affrontare clienti scontenti più avanti.
E se il controllo richiede troppo tempo: dovresti fidarti e basta dell’IA?
Punti chiave
La tentazione è forte: l’IA è intelligente, quindi perché ricontrollare? Ma fidarsi senza controllare è come firmare un contratto senza leggerlo. Il controllo richiede pochi minuti, mentre un progetto difettoso che coinvolge persone reali ti costa reputazione e denaro. Ed è una competenza che diventa presto un’abitudine. Sei comunque responsabile del risultato, e non puoi delegare questa responsabilità al modello.
Capisco la tentazione. Controllare sembra noioso e «non è per questo che ho chiesto aiuto all’IA». Ma la responsabilità del risultato è tua, non del modello. L’IA non ha reputazione e non ne subisce le conseguenze: ha prodotto il codice e se n’è dimenticata. Sarai tu a dover rispondere al cliente il cui pagamento non è andato a buon fine.
Il creatore di Claude Code offre una prospettiva ancora più ampia:
La scrittura del codice ha smesso di essere il collo di bottiglia: se ne è occupata l’IA. Ora il valore sta altrove: nel capire il compito e controllare il risultato. Questo è il tuo punto di forza: sai meglio di qualunque sviluppatore esterno quale risultato dovrebbe ottenere il tuo cliente.
Perché controllare è una competenza e non un’attività da fare una volta sola?
Punti chiave
Passare una volta attraverso la checklist è utile. Ma la vera differenza si vede quando controllare diventa parte del tuo modo di lavorare con l’IA: il contesto giusto in ingresso e l’abitudine di controllare il risultato in uscita. Così l’IA smette di essere una roulette e diventa uno strumento. E ogni progetto successivo si realizza più velocemente del precedente.
Questi sette controlli sono il minimo che distingue «l’ho pubblicato e spero» da «l’ho pubblicato e so che funziona». Passali in rassegna una volta e individuerai già la maggior parte delle sorprese prima dei tuoi clienti.
Da lì, diventa un’abitudine. Fornisci all’IA il contesto giusto in ingresso e controlla il risultato in uscita: ogni nuovo progetto si realizzerà più velocemente, perché non partirai da zero.
Clone dell’IA, Second Brain e Context Engineering: trovi altri materiali su come lavorare con gli strumenti nella documentazione di Ailoot.
Maggiori dettagli
Domande frequenti
Mettere una chiave API in .env basta a mantenerla segreta?
No. Le chiavi private devono essere usate solo sul server. .env e .gitignore aiutano con il repository, ma le variabili frontend o pubbliche possono essere copiate nel bundle del browser. Esamina i file e le risposte effettivamente consegnati al client.
Cosa dimostra che il pagamento funzioni oltre una demo convincente?
Completa lo scenario utente previsto e verifica ordine, stato, ricevuta o email e risultato persistito dopo il pagamento. Prova anche input vuoti, invii duplicati e gestione dei guasti: un addebito riuscito non dimostra che l’ordine sia stato creato correttamente.