Errori di coding con l'AI:4 modi in cui Claude ti sabota

Gli errori di coding con l'AI non sabotano il tuo codebase con codice che si rompe. Lo sabotano con codice che funziona, per circa sei mesi. Claude sbaglia con sicurezza in continuazione, e la versione pericolosa non è quando sbaglia in modo ovvio. È quando sbaglia in modo plausibile: codice che compila, gira e sembra a posto, costruito su un'ipotesi sbagliata sui tuoi dati o sulla tua logica di business.

Durante gli undici mesi di costruzione di FIKR Space, dall'AI sono usciti sempre gli stessi quattro pattern sbagliati. Ognuno, se l'avessi accettato, avrebbe creato sei mesi dopo un dolore diverso e specifico. Eccoli in parole semplici: cosa propone Claude, perché sembra ragionevole e cosa ti costa esattamente più avanti.

Perché l'AI usa di default codice mediocre

Claude è stato addestrato su milioni di codebase, e la maggior parte era mediocre. Quando non specifichi cosa vuoi, ottieni l'output del codebase mediano, pieno di scorciatoie e compromessi che gli ingegneri esperti non accetterebbero mai. Nessuna di queste scorciatoie fallisce oggi. Tutte falliscono più tardi, ed è esattamente per questo che sopravvivono alla revisione di un fondatore che controlla soltanto se la funzionalità funziona adesso.

Il tuo compito non è scrivere il codice. Il tuo compito è essere la voce senior nella partnership: opporti quando qualcosa non ti convince, anche quando non riesci a spiegarne subito il motivo.

Errore 1: il blob JSON, un cassetto della roba invece di uno schedario

Claude ti suggerirà di memorizzare dati strutturati come un blob JSON, un unico campo flessibile che contiene tutto, invece di una vera tabella con vere colonne. Immagina di buttare i tuoi documenti in un cassetto della roba invece che in uno schedario. Il cassetto funziona benissimo finché ci sono dieci documenti.

A me è successo alla terza settimana. Claude ha proposto di memorizzare i dati degli obiettivi strategici degli utenti (obiettivi trimestrali, stato degli OKR, metriche di allineamento) come colonna JSON nella tabella degli utenti. Avrebbe funzionato. Per circa tre mesi. Poi mi serviva rispondere a una domanda di business basilare: mostrami tutti gli utenti il cui completamento degli obiettivi del Q3 è sotto il sessanta per cento. Con un blob JSON, rispondere significa aprire il cassetto di ogni utente e leggere tutto ciò che contiene prima di poter filtrare: un approccio che reggeva con cinquanta utenti e sarebbe morto a cinquecento. Correggerlo dopo avrebbe significato migrare sei mesi di dati dei clienti e riscrivere dodici servizi. Oppormi alla terza settimana è costato un'ora in più di discussione sul design. Ricostruire al sesto mese sarebbe costato tre settimane.

Errore 2: gli enum, scolpire nella pietra le opzioni di oggi

Un enum è un campo i cui valori ammessi sono fissati in anticipo, come stampare il menu del tuo ristorante invece di scriverlo su una lavagna. Claude ha una forte propensione di default verso gli enum per qualsiasi campo con un insieme piccolo e noto di valori: livello di abbonamento, ruolo utente, tipo di notifica. Ognuno, sul momento, sembra ovviamente fisso.

Ognuno dei miei ha avuto bisogno di nuovi valori entro un anno: un nuovo livello di abbonamento, un nuovo ruolo, una nuova categoria di notifica. E cambiare un enum nel database richiede un rituale in più passaggi: eliminare i vincoli, ricreare il tipo, aggiornare ogni riga. Una tabella di lookup, la versione lavagna, è una normale tabella che cresce aggiungendo una riga. L'enum blocca la colonna alla realtà di oggi; la tabella di lookup accoglie quella di domani. Stesso pattern, default diverso. Opponiti. Pretendi la tabella di lookup.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Errore 3: i tipi any, disattivare l'allarme antincendio

Il compito di TypeScript è intercettare un'intera classe di bug prima che i tuoi utenti li vedano, verificando che ogni dato abbia la forma che il codice si aspetta. Quando questo controllo fallisce su qualcosa di complesso, Claude a volte propone di marcare il dato come any, che significa "smetti di controllare questo". L'errore sparisce. La build riesce. La funzionalità viene rilasciata. Hai appena disattivato un allarme antincendio, e non succede nulla finché non c'è del fumo.

È il pattern più insidioso perché il sintomo è invisibile. Sei mesi dopo cambi qualcosa altrove nel prodotto, e l'errore di tipo che avrebbe dovuto intercettare il danno non lo fa, perché da qualche parte a monte un any sta inghiottendo il segnale in silenzio. Il bug arriva in produzione. Lo scopri da una segnalazione di un cliente. Ogni any che accetti adesso è un futuro martedì pomeriggio passato a fare debug di un problema che il sistema di tipi avrebbe dovuto prevenire.

Errore 4: errori inghiottiti in silenzio, fallimenti che nessuno sente

Il peggiore dei quattro. Claude a volte scrive l'equivalente di try { ... } catch (e) { return null }, cioè "se qualcosa va storto, non dire nulla e restituisci un risultato vuoto", e lo chiama gestione elegante degli errori. Quel codice supera ogni test che scrivi, perché i tuoi test non provocano deliberatamente la modalità di fallimento.

In produzione, quando si verifica il vero guasto, la funzione non restituisce nulla. In silenzio. Il resto del sistema non sa che è andato storto qualcosa. L'utente vede una schermata vuota. L'errore non viene registrato da nessuna parte. Lo scopri solo quando un cliente si lamenta, e anche allora non riesci a ricostruire cosa sia successo, perché nessun errore è mai stato sollevato. Combatti questo pattern ogni singola volta: fallimenti specifici, gestiti in modo specifico, registrati a voce alta. Le cinque righe di codice in più ti evitano il prossimo blackout.

Il filo comune dei quattro errori di coding con l'AI

La buona notizia: Claude reagisce bene quando lo contesti. Quando dici "no, voglio questo come tabella separata, non come blob JSON, ed ecco perché", ristruttura il codice con eleganza e spesso migliora ciò che aveva proposto all'inizio. Il modello è collaborativo. Devi solo essere tu la voce senior.

Due abitudini rendono l'opposizione sistematica invece che fortunata. Dai all'AI un briefing adeguato prima che costruisca qualsiasi cosa: è il metodo PRP. E non lasciare mai che la velocità sostituisca la struttura: è tutta la lezione della trappola del vibe coding. Specifica. Opponiti. Pretendi la struttura giusta. Costa un po' più di tempo per funzionalità e ti compra un codebase che puoi ancora far evolvere al dodicesimo mese invece di uno da ricostruire.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Domande frequenti

Perché il codice generato dall'AI causa problemi mesi dopo?

Perché l'AI ottimizza per far funzionare la richiesta di oggi, non per come il codice evolve. Addestrata su milioni di codebase per lo più mediocri, ricorre di default a scorciatoie (blob flessibili, liste di valori fisse, controlli disattivati, errori inghiottiti) che superano ogni test adesso e rivelano il loro costo solo quando il prodotto cresce o cambia.

Come riconosco il codice AI sbagliato se non so leggere il codice?

Interroga il cambiamento e il fallimento, non la sintassi. Chiedi all'AI: cosa succede quando dobbiamo aggiungere un nuovo valore qui? Come cercheremmo in questi dati quando ne avremo dieci volte di più? Cosa succede quando questa operazione fallisce: dove va a finire l'errore? Se le risposte parlano di migrazioni, riscritture o "non restituisce nulla", opponiti.

Devo lasciare che Claude prenda le mie decisioni di architettura?

No. Claude è un brillante esecutore e un architetto mediocre. Chiedigli se una cosa debba essere una tabella separata o una colonna JSON e la risposta di solito va bene, a volte è sbagliata, ogni tanto è ottima, e non puoi capire quale sia a meno che tu non abbia sviluppato un tuo gusto architetturale. Le decisioni architetturali sono tue; le decisioni di implementazione sono di Claude.

Opporsi all'AI non rallenta la costruzione?

Un po', per funzionalità, ed è il miglior compromesso che farai mai. Oppormi al blob JSON mi è costato un'ora in più di discussione sul design alla terza settimana. Accettarlo mi sarebbe costato tre settimane di ricostruzione al sesto mese, più la migrazione di sei mesi di dati dei clienti.