Come usare l'IA per programmare senza codice fragile

Se ti chiedi come usare l'IA per programmare senza ritrovarti codice che nessuno sa spiegare, parti da questo: apri un ticket, incolli la descrizione in una chat e ricevi indietro 200 righe di codice plausibile. Compilano. Due giorni dopo un reviewer chiede perché ignorano il tuo wrapper di retry, e nessuno nel team sa rispondere. Il problema di solito non è la generazione, che funziona. È tutto quello che le sta intorno. Il flusso di lavoro che do ai nuovi ingegneri tratta il modello come un junior veloce e sicuro di sé che non ha mai visto il tuo repo, ed è costruito attorno al tempo di revisione, non al tempo di scrittura.

Ti rende davvero più veloce nel codice?

A volte sì, e la risposta onesta dipende dal compito. Lo Stack Overflow Developer Survey 2025 rileva che l'84% dei rispondenti usa o prevede di usare strumenti IA, ma solo il 33% si fida del risultato in una certa misura. La lamentela più diffusa, citata dal 66%, è un codice "quasi giusto, ma non del tutto". Un altro 45,2% dice che il debug del codice generato dall'IA richiede più tempo del previsto.

I dati controllati sono meno lusinghieri. In uno studio del 2025 di METR, 16 sviluppatori open source esperti hanno lavorato su 246 issue reali in repo che conoscevano bene. Con l'IA consentita hanno finito circa il 19% più lentamente, pur credendo di essere stati circa il 20% più veloci. METR ha nel frattempo pubblicato dati più recenti, quindi tratta quel numero come la fotografia degli strumenti dei primi mesi del 2025, non come un verdetto.

La lezione non è che "l'IA rallenta". È che la sensazione di velocità è uno strumento di misura pessimo. Misura i minuti che passano dal ticket alla PR unita, non la rapidità con cui è comparsa la prima bozza.

Cosa scrivere prima di qualsiasi prompt

Un piano, con parole tue, in meno di dieci righe. Se salti questo passaggio, il modello riempie i vuoti con le sue supposizioni, che per definizione sono generiche.

Il mio modello è breve:

1. Il cambiamento di comportamento, in una frase.

2. I file che pensi di toccare, anche se non ne sei sicuro.

3. La funzione o il pattern esistente che il nuovo codice deve riutilizzare.

4. Una cosa che non deve fare, per esempio aggiungere una dipendenza o cambiare lo schema.

5. Come saprai che funziona: un test, una chiamata curl, uno screenshot.

Il punto 3 è quello che la gente salta, ed è da lì che arriva gran parte del codice "quasi giusto". Il modello non sa che esiste il tuo helper withRetry a meno che tu non lo nomini o non possa leggerlo.

Evita il prompt "costruisci l'intera app". Principianti e senior ottengono lo stesso risultato: un diff enorme che nessuno capisce e un progetto rimasto a metà.

Come si presenta un buon prompt, in pratica?

Prendi un lavoro reale: il sender dei webhook perde eventi quando il ricevitore va in timeout. Un prompt debole dice "sistema l'affidabilità dei webhook". Uno utilizzabile si legge come un ticket.

Aggiungi retry con backoff esponenziale a sendWebhook() in src/webhooks/sender.ts.
Riusa withRetry() da lib/http.ts. Massimo 4 tentativi, con jitter attivo.
Non cambiare la firma pubblica e non aggiungere dipendenze.
Aggiungi un test vitest per un ricevitore che fallisce due volte e poi riesce.

Il prompt indica il file, l'helper da riusare, un limite e una verifica. Il risultato è un diff di circa 30 righe che puoi leggere in una sola seduta. Se il diff torna a 150 righe, il modello si è perso, e tu lo rifiuti invece di correggerlo a mano.

Due trucchi aiutano. Chiedi prima un piano e leggilo prima che qualunque file cambi: un piano sbagliato costa trenta secondi, un diff sbagliato costa dieci minuti. E quando una risposta non va, ribadisci il vincolo violato invece di discutere. "Hai aggiunto una dipendenza, la regola è nessuna" funziona meglio di un paragrafo di spiegazioni.

Quale strumento per quale lavoro

Esistono tre forme, e confonderle è il secondo errore più comune.

Il completamento inline prevede le righe successive mentre scrivi. Va bene per il boilerplate e per i test, dove il pattern è già sullo schermo. La chat nell'editor risponde a domande sul codice selezionato e propone modifiche che accetti blocco per blocco. Gli agenti prendono un compito, leggono file, eseguono comandi e tornano con un branch.

Scegli in base a quanto puoi verificare a basso costo. Un completamento che leggi in due secondi ha un rischio basso. Un'esecuzione di agente che tocca 14 file ha un guadagno alto e un costo di revisione altrettanto alto.

Cursor è l'opzione pensata per l'editor: un fork di VS Code con un buon completamento con Tab e sessioni di agenti in parallelo. Vale la pena se passi la giornata nell'editor. Saltalo se il tuo team è standardizzato su JetBrains e non intende cambiare.

GitHub Copilot è la scelta a basso attrito per i team già su GitHub, perché PR, issue e review stanno nello stesso posto. Controlla la fatturazione: da giugno 2026 passa a crediti basati sull'uso, quindi un uso intenso degli agenti costa più di quanto suggerisca il prezzo per postazione.

Claude Code è nativo del terminale e agentico: deleghi un refactoring o la caccia a un bug, poi rivedi il risultato. Non ha completamento inline automatico e usa solo i modelli Claude. È uno scambio equo se vuoi delegare a livello di compito.

Aider è l'opzione scriptabile e nativa di git. Crea un commit automatico per ogni modifica con un messaggio, quindi il rollback è un git revert. Paghi solo i token del modello, il che si adatta a chi vuole controllare i costi.

Come evitare che il codice ignori il tuo repo

Fornisci il contesto in modo deliberato. Gran parte dell'output scadente deriva dal fatto che il modello non ha mai visto il file rilevante.

Tre abitudini aiutano. Primo, allega i due o tre file che definiscono il pattern, non l'intera cartella. Secondo, incolla il test fallito o l'errore alla lettera invece di descriverlo. Terzo, tieni nel repo un breve file di regole (naming, gestione degli errori, librerie vietate) che lo strumento legge a ogni esecuzione. La maggior parte degli strumenti agentici ne supporta uno.

# AI-RULES.md
- Errori: restituisci Result, non lanciare eccezioni nei services/
- Le chiamate HTTP passano da lib/http.ts (ha retry e tracing)
- Nessuna nuova dipendenza senza una nota nella descrizione della PR
- Test: vitest, accanto al codice come *.test.ts

Quattro righe così eliminano una quota sorprendente dei commenti in review. Aiutano anche gli esseri umani.

Su un repo che non conosci ancora, fai domande prima di chiedere modifiche. "Dove viene fatta rispettare la scadenza della sessione, e cosa la richiama?" è un primo prompt migliore di "aggiungi un refresh token". Leggi la risposta, apri i due file che cita, e solo allora decidi cosa cambiare. È lo stesso ciclo di grep, blame e domanda a un collega che fai già, solo più veloce.

Come rivedere il codice generato dall'IA

Più lentamente di come rivedi il codice di un collega. Un collega ha una storia con la tua codebase. Il modello no.

La mia checklist, in ordine:

• Eseguilo prima di leggerlo. Un test che hai scritto tu batte una spiegazione sicura di sé.

• Leggi gli import. I pacchetti inventati e gli helper sconosciuti emergono lì per primi.

• Cerca ciò che manca. Percorsi di errore, gestione dei null, pulizia delle risorse. I modelli scrivono bene il percorso felice.

• Controlla la dimensione del diff. Se hai chiesto una correzione di 10 righe e ne arrivano 120, è stato riscritto qualcosa che non hai chiesto.

• Elimina ciò che non sai spiegare. Se non riesci a difendere una riga in review, non si unisce.

Tieni il commit piccolo e il messaggio onesto. "Aggiungi retry al sender dei webhook (assistito dall'IA, test aggiunti)" va bene. Nasconderlo non aiuta nessuno e rende più difficile il debug successivo.

Cosa non affidare mai all'IA

Qualsiasi cosa in cui sbagliare sia silenzioso e costoso. La logica di autenticazione, i flussi di pagamento, le migrazioni dei dati e i controlli dei permessi sono i luoghi in cui il "quasi giusto" passa i test e fallisce in produzione.

Puoi comunque usarla lì, ma in un'altra modalità: chiedile di rivedere il tuo codice ed elencare i rischi, invece di scrivere il codice. Leggere un elenco di cinque possibili problemi costa tre minuti. Leggere una migrazione generata ti costa il pomeriggio che passerai a dubitarne.

Se stai imparando, c'è una seconda esclusione. Scrivi tu la prima versione, poi chiedi al modello di criticarla. Un junior che accetta sempre la versione generata impara a fare prompt, non a programmare, e il divario si vede al primo guasto in produzione.

Come cambia tutto in team, con un piano per la prima settimana

La differenza tra singoli e team è il carico di revisione. Uno sviluppatore che usa agenti può aprire più PR al giorno di quante i revisori riescano a leggerne. Concordate presto tre cose:

1. Un limite di dimensione. Le PR oltre qualche centinaio di righe modificate vanno divise, chiunque o qualunque cosa le abbia scritte.

2. Una norma di trasparenza. Dichiara quando una modifica è assistita dall'IA, così i revisori regolano la loro attenzione.

3. Un file di regole condiviso. Una sola fonte di verità per le convenzioni batte cinque prompt personali.

Per l'onboarding, il miglior uso che ho visto è la lettura guidata dalle domande. I nuovi arrivati chiedono all'assistente dove vivono le cose, poi verificano nel codice. Così accorci la prima settimana fatta di "di chi è questo modulo?", senza consegnare codice che non sapranno mantenere.

Ecco un piano che puoi copiare. Giorno 1: usa solo il completamento inline, per test e boilerplate. Giorno 2: fai tre domande al giorno sulla codebase in chat e verifica ogni risposta. Giorno 3: lascia che la chat proponga una piccola modifica per compito e leggi ogni blocco. Giorno 4: prova un agente su un lavoro a basso rischio, come rinominare una chiave di configurazione in più file, su un branch. Giorno 5: scrivi il tuo file di regole a partire da ciò che ti ha infastidito in review.

Tieni d'occhio un numero durante la settimana: i minuti dall'inizio di un ticket alla PR unita, correzioni di review incluse. Se non è sceso, hai imparato dove lo strumento non si adatta al tuo lavoro, che è anch'esso un risultato.

Usala prima per leggere, poi per scrivere. Il guadagno più onesto che ho visto non è la generazione, ma la comprensione: capire un modulo sconosciuto in dieci minuti invece che in un'ora. Scrivere codice non è mai stata la parte lenta del lavoro. Lo erano leggere, decidere e verificare. Punta lo strumento lì, tieni il tuo giudizio sul pulsante di merge, e il resto viene di conseguenza.