L'errore più costoso non era il codice. Ero io.

Erano le 23:47 di un martedì di gennaio. Avevo appena cancellato 340 righe di CSS scritte in tre sessioni diverse, spalmate su due settimane. Non era un refactor. Era un funerale.

Il contatore nella cronologia di Git segnava 47 commit in 22 giorni. Quarantasette salvataggi di cose che non funzionavano, o che funzionavano per trenta minuti e poi smettevano quando cambiavi la larghezza del browser. Tutta questa attività frenetica per arrivare a cancellare tutto e ricominciare. Produttività da manuale.

Non ero stanco. Ero stupito di me stesso.

La libreria sbagliata — tre volte, non due

Il problema tecnico vero aveva un nome preciso: avevo scelto la libreria CSS sbagliata. Non una volta. Non due. Tre volte distinte, in tre momenti diversi, con tre motivazioni diverse che all'epoca mi sembravano solide.

Prima scelta: una libreria leggera, minimalista, sembrava perfetta per chi non sa il CSS. Risultato: bellissima su desktop, completamente rotta su mobile. Schermata da 375px e l'interfaccia collassava come un portafoglio vuoto.

Seconda scelta: una libreria più strutturata, componenti pronti, documentazione decente. Ogni componente aveva il suo sistema di classi proprietario. Quando Claude generava codice, generava classi che non esistevano in quella versione. Ho perso ore a capire perché un bottone non aveva il colore giusto. Il colore. Un bottone.

Terza scelta: sono tornato sulla prima. Pensavo di conoscerla meglio. Non la conoscevo meglio. La conoscevo solo da più tempo.

Ho buttato tutto a febbraio. Sono passato a un approccio utility-first che Claude gestisce in modo molto più prevedibile. Da allora non ho più riscritto CSS due volte per lo stesso componente. Non lo scrivo per sembrare saggio — lo scrivo perché ci ho messo quattro mesi a capire una cosa che un developer junior avrebbe risolto in quattro giorni.

L'errore sotto l'errore

Il punto non era la libreria. Il punto era come prendevo le decisioni tecniche.

Avevo un metodo: Claude suggerisce, io valuto, decido. In teoria funziona. In pratica valutavo con criteri sbagliati, perché non avevo i criteri giusti. Scegliev basandomi su "sembra popolare" o "la documentazione è leggibile". Criteri da utente, non da builder.

Claude non poteva correggermi su questo. Rispondeva alle domande che facevo. Se non facevo la domanda giusta, ricevevo una risposta tecnicamente corretta a un problema mal formulato. Non è un limite di Claude — è il limite di chi non sa ancora cosa chiedere.

Ho impiegato tre mesi a capire che dovevo cambiare le domande, non le risposte.

Il refactor da zero — numeri reali

A metà febbraio ho fatto una cosa che ogni guida di startup sconsiglia: ho fermato lo sviluppo per due settimane e ho riscritto l'architettura frontend da zero. Nessuna nuova funzione. Nessun progresso visibile. Stefano mi guardava con l'espressione di chi sa che hai ragione ma non lo dirà mai esplicitamente.

Il risultato: il codebase è passato da qualcosa che solo io riuscivo a seguire — e a tratti neanche io — a qualcosa con una logica riproducibile. I componenti si comportano in modo prevedibile. Claude genera codice compatibile al primo tentativo nell'80% dei casi, contro il 40% di prima. Quel 40% di gap non era magia. Era struttura.

Costo del refactor: due settimane di ritardo sul lancio. Beneficio: ogni ora di sviluppo da marzo in poi vale il doppio di prima. Non so fare il calcolo preciso, ma so che RistoDocs — il nostro primo verticale — l'abbiamo costruito in tre settimane dopo il refactor. Prima ne avrebbe richieste sei, almeno.

Cosa ho imparato, detto senza farlo sembrare una lezione

Ho 58 anni. Non sono uno che impara in fretta quando si tratta di ammettere che stava sbagliando strada. Carattere, non età — ci tengo a precisarlo.

La cosa più utile che ho fatto in questi mesi non è stata una scelta tecnica. È stata smettere di ottimizzare quello che non funzionava e accettare di buttarlo. Il sunk cost fa male anche quando non hai soldi investiti ma hai investito tempo. Forse fa più male.

Claude non si è mai lamentato delle riscritture. Ha rifatto ogni pezzo senza commenti sul fatto che lo avessimo già fatto. Questo è un vantaggio reale delle due di notte, quando vorresti che qualcuno ti dicesse che hai sbagliato ma senza il tono di chi ha ragione da sempre.

Il vero errore costoso non erano le librerie sbagliate. Era il tempo che ho perso prima di decidere di ricominciare. Ogni giorno in più su una strada sbagliata ha un costo. Non lo vedi nel conto corrente. Lo vedi nel calendario.

Il prossimo episodio: come abbiamo costruito RistoDocs in tre settimane, cosa significa costruire un verticale quando hai già una piattaforma che regge, e perché il primo utente reale ti insegna più di sei mesi di development in solitudine.