Come individuare i bug nel codice generato dall'IA prima che arrivino in produzione

Un assistente IA può produrre una funzionalità apparentemente funzionante in pochi secondi. La parte difficile non è più generare il codice: è capire se puoi fidartene. I modelli IA sono sicuri di sé anche quando sbagliano, allucinano API che non esistono e "sistemano" allegramente un test che fallisce cancellando l'asserzione. Se metti in produzione qualunque cosa l'agente ti consegni, non stai davvero costruendo software: stai scommettendo.

La buona notizia: non serve leggere ogni riga come un revisore paranoico. Serve una rete di sicurezza a livelli, così gli errori evidenti vengono intercettati automaticamente e solo le decisioni interessanti arrivano sotto i tuoi occhi. Ecco come costruirne una, dalla più economica alla più accurata.

1. Leggi il diff, non la chat

L'abitudine di gran lunga più preziosa: rivedi le modifiche reali ai file, non il riassunto che ne fa l'IA. Strumenti come Claude Code, Cursor e Copilot mostrano tutti un diff prima che tu accetti le modifiche. Scorrilo con tre domande:

• Ha toccato file che non mi aspettavo? A volte gli agenti, "per aiutare", modificano la configurazione, cancellano test o riscrivono funzioni non correlate.
• Ha inventato un import o un'API? Un campanello d'allarme è la chiamata a un metodo di libreria che non hai mai visto. Verifica che esista prima di fidartene.
• Ha indebolito qualcosa? Gestione degli errori rimossa, un tipo allentato, un controllo commentato, o un test che ormai asserisce quasi nulla.

Questa scansione di 30 secondi intercetta la maggior parte dei momenti "l'IA ha fatto una sciocchezza".

2. Lascia che sia la macchina a controllare la macchina

Gli esseri umani sono pessimi nell'individuare un punto e virgola mancante e ottimi nell'individuare una logica sbagliata. Ribalta il lavoro noioso sul tooling, così la tua attenzione va dove conta. Tre livelli economici e gratuiti:

• Un linter (ESLint, Ruff, ecc.) per lo stile e gli errori comuni.
• Un type checker (TypeScript, mypy) per intercettare i bug della classe API-allucinata e dato-di-forma-sbagliata.
• Un test runner per il comportamento.

Il trucco è renderli non opzionali collegandoli a un pre-commit hook, così girano prima che qualsiasi commit vada a buon fine. Ecco un esempio minimale con Husky in un progetto JavaScript:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

Ora, se il codice dell'IA non supera il linter, rompe i tipi o fa fallire un test, il commit viene semplicemente rifiutato. L'errore dell'agente non raggiunge mai il tuo branch. (In Python, l'equivalente è il framework pre-commit che esegue ruff, mypy e pytest.)

3. Fai scrivere — ed eseguire — i test all'IA

Gli assistenti IA sono davvero bravi a generare test, e i test sono la migliore difesa contro la prossima modifica che rompe silenziosamente questa. Ma c'è un'insidia: un agente che scrive ed esegue i propri test può barare rendendo il test banalmente superato. Quindi separa i passaggi nel tuo prompt:

"Scrivi test per questa funzione coprendo l'input vuoto, il percorso felice e un caso limite. Non modificare la funzione stessa."

Poi esegui i test tu stesso, o in CI, e conferma che esercitino davvero un comportamento reale. Un test come expect(result).toBeDefined() è teatro; expect(addTax(100, 0.2)).toBe(120) è un controllo vero. Leggi almeno un'asserzione per assicurarti che sia del secondo tipo.

4. Aggiungi un quality gate in CI

Gli hook locali proteggono la tua macchina; un controllo in CI protegge il progetto da chiunque (incluso te-futuro in una sera stanca). Aggiungi un workflow che riesegue linting, tipi e test su ogni pull request, e configura il branch in modo che i merge siano bloccati finché non passa. È esattamente l'idea che le grandi piattaforme stanno ora vendendo come prodotto: GitHub Code Quality, in disponibilità generale a luglio 2026, aggiunge gate che bloccano un merge quando la manutenibilità o la copertura calano, e Cursor ha riformulato il suo comando /review come gate pre-commit all'inizio di quest'anno. Puoi ottenere l'80% del valore gratuitamente con un semplice job di GitHub Actions o GitLab CI.

5. Mantieni un umano nel ciclo per il 5% rischioso

L'automazione non può giudicare se una funzionalità è quella giusta, se una decisione architetturale invecchierà bene, o se cancellare quella funzione "inutilizzata" è sicuro. Riserva la tua attenzione vera a: tutto ciò che tocca autenticazione, pagamenti o cancellazione di dati; le migrazioni di database; e le modifiche al codice condiviso da cui dipendono molti altri file. Per tutto il resto, lascia che sia la rete di sicurezza a lavorare.

Una semplice regola pratica

Più autonomia dai all'IA, più robusti devono essere i tuoi gate. Se accetti con attenzione una modifica alla volta, una rapida lettura del diff può bastare. Se lasci un agente in esecuzione per dieci minuti senza supervisione, vuoi linting, tipi e test a fare da barriera tra lui e il tuo branch principale. Costruisci la rete una volta e potrai lasciare che l'IA si muova in fretta senza che rompa silenziosamente le cose alle tue spalle.