Quali errori commettono gli sviluppatori nel codificare con assistenti AI?

Assistenti AI come Copilot, Claude e i modelli integrati di Cursor hanno cambiato la velocità con cui il codice viene scritto. Non hanno cambiato il livello di attenzione con cui deve essere revisionato. La maggior parte dei problemi che ho visto dal coding assistito da AI derivano da poche abitudini ripetibili, non dai modelli stessi.

Accettare suggerimenti senza leggerli

Il più grande è premere tab per accettare un completamento perché sembra plausibile e compila. Plausibile non significa corretto. Ho visto una query SQL suggerita eliminare silenziosamente una clausola WHERE durante un refactor, e la persona l'ha accettata perché i nomi delle variabili corrispondevano. Se non stai leggendo ogni riga che un assistente ti fornisce alla stessa velocità con cui leggeresti una pull request di un collega, finirà per finire online qualcosa che non comprendi. Tratta ogni suggerimento come una prima bozza da uno sviluppatore junior che è veloce ma non ha memoria delle convenzioni della tua codebase.

Fidarsi di esso per codice sensibile alla sicurezza

Gli assistenti AI sono addestrati su enormi quantità di codice pubblico, e gran parte di quel codice ha problemi di sicurezza incorporati. Chiedi un gestore di caricamento file veloce e spesso otterrai qualcosa senza controllo dell'estensione, senza limite di dimensione e un percorso costruito tramite concatenazione di stringhe invece di os.path.join o una chiamata a una libreria sicura. Lo stesso per l'auth: gli assistenti amano suggerire di memorizzare i JWT in localStorage, o confrontare segreti con == invece di un confronto a tempo costante. Niente di tutto questo è malizioso, è semplicemente statisticamente comune nei dati di addestramento. Per qualsiasi cosa che tocchi autenticazione, I/O di file, deserializzazione o SQL, scrivi la logica tu stesso o fai passare l'output dell'AI attraverso le stesse domande di threat modeling che faresti per qualsiasi nuovo codice: cosa succede con input ostili, cosa succede se questa chiamata fallisce, chi altro può raggiungere questo endpoint.

Lasciargli inventare dipendenze e API

I modelli allucinano nomi di pacchetti e firme di funzioni con totale sicurezza. Questo è il problema dello "slopsquatting" — gli attaccanti registrano i nomi di pacchetti falsi che i modelli suggeriscono frequentemente, quindi un pip install o npm install non verificato può scaricare qualcosa che non è affatto la tua libreria di logging. Prima di aggiungere una dipendenza che un assistente consiglia, verifica che esista effettivamente su PyPI o npm, controlla il suo conteggio di download e la data di ultima pubblicazione, e leggi il sorgente se è abbastanza piccolo. La stessa cautela si applica alle chiamate API: se l'assistente fa riferimento a un metodo che non riconosci, controlla la documentazione effettiva prima di dare per scontato che esista.

Perdere il modello mentale del tuo codice

Quando scrivi il codice tu stesso, costruisci una mappa mentale del perché ogni pezzo esiste. Quando accetti grandi blocchi di codice generato da AI nel corso di una sessione, quella mappa diventa sottile velocemente. Poi un bug appare tre settimane dopo e stai debuggando codice che non hai mai veramente scritto e non ricordi completamente. La soluzione non è evitare il codice generato da AI, è rallentare abbastanza da spiegare ogni blocco a te stesso, o a un collega, prima di farlo il merge. Se non riesci a spiegare cosa fa una funzione e perché lo fa in quel modo, non farne ancora il merge.

Saltare i test perché il codice