Episodio 7 — Benvenuto Developer AI

Come si scrive software senza saper programmare. Spoiler: male, poi meno male, poi abbastanza bene da andare avanti.

Erano le 23:47 di un martedì. Avevo davanti uno schermo con quattrocentosessanta righe di codice Python che non capivo, un messaggio di errore che non capivo, e la certezza assoluta di aver rotto qualcosa che fino a due ore prima funzionava.

Il log diceva: AttributeError: 'NoneType' object has no attribute 'get'. Chiarissimo. Come leggere un referto medico in latino.

Ho incollato tutto su Claude. Ho scritto: "Cosa ho rotto?"

Come sono arrivato a scrivere codice a mezzanotte

Facciamo un passo indietro. A febbraio avevamo l'idea, avevamo il modello di business abbozzato su un documento di dodici pagine, avevamo Stefano. Quello che non avevamo era la piattaforma. E io non avevo mai scritto codice serio in vita mia — il BASIC del Commodore 64 non conta, era trent'anni fa e piangevo lo stesso.

La scelta era semplice: trovare uno sviluppatore, oppure provare con Claude Code. Uno sviluppatore bravo costa tra i 400 e i 600 euro al giorno. Noi avevamo un budget mensile per tutto — infrastruttura, API, tool — che stava intorno ai 200 euro. La matematica era chiara. Nel senso che non c'era scelta.

Ho aperto Claude Code a marzo. Prima sessione: due ore per costruire lo scheletro dell'applicazione. Backend in Python con Flask, database PostgreSQL, struttura delle cartelle, prime route API. Funzionava. Ero euforico come un bambino che vede la neve per la prima volta. Poi ho scoperto che non avevo gestito nessun caso d'errore e che la prima volta che un utente avrebbe fatto qualcosa di inatteso, l'app sarebbe esplosa in modo spettacolare.

È esplosa la settimana dopo. Durante un test con Stefano.

Il problema con "sembra che funzioni"

Quando non sai programmare, il tuo criterio di successo è uno solo: la pagina si carica. Se la pagina si carica, hai vinto. Se non si carica, hai perso. Una visione del mondo che regge per circa quattro giorni, poi il mondo reale si presenta.

Il mondo reale si è presentato con Stefano che ha caricato un file con caratteri speciali nel nome. Crash totale. Poi ha provato ad accedere a una stanza senza permessi — invece di un messaggio d'errore, vedeva i dati di tutti. Poi ha lasciato un campo vuoto in un form che non avevo reso obbligatorio. Crash diverso, stesso risultato. Tre bug in quaranta minuti. Ero orgoglioso della velocità, non del codice.

Ho imparato la parola "validazione" in quel pomeriggio. Non nel senso motivazionale che si usa nelle presentazioni — nel senso tecnico: controllare che i dati in ingresso siano quelli che ti aspetti, prima di fare qualsiasi cosa. Concetto ovvio per chiunque abbia studiato informatica. Per me era una rivelazione alle quattro di pomeriggio di un giovedì.

Come lavoro davvero con Claude Code

Ho sviluppato un metodo. Non elegante, ma funziona.

Prima scrivo cosa voglio in italiano semplice. Non "implementa un sistema di autenticazione JWT con refresh token e blacklist su Redis" — non saprei nemmeno leggere quella frase ad alta voce con sicurezza. Scrivo: "Voglio che gli utenti facciano login, restino connessi per sette giorni, e che se cambio la password dal pannello admin vengano disconnessi subito."

Claude traduce in requisiti tecnici, poi scrive il codice, poi me lo spiega. La spiegazione è la parte che conta. Se non capisco perché funziona, la prossima volta che si rompe non so neanche da dove iniziare a guardare. Quando il codice non funziona — e non funziona spesso — incollo il messaggio di errore, descrivo cosa stavo cercando di fare, e aggiungo sempre: "Spiegami cosa ho sbagliato, non solo come correggerlo." Quella frase mi ha insegnato più cose di qualsiasi corso online avrei potuto seguire.

Ho sbagliato la logica dei permessi per ruolo tre volte. La prima Claude l'ha corretta. La seconda anche. La terza mi ha spiegato che affrontavo il problema nel modo sbagliato dall'inizio e mi ha proposto un'architettura diversa. Abbiamo riscritto quel pezzo da zero in una sera. Funziona ancora — è uno dei pochi pezzi di cui sono ragionevolmente sicuro.

I numeri onesti

Da marzo a oggi ho aperto probabilmente 340 sessioni con Claude Code. Stima, non dato preciso — non ho tenuto il conto all'inizio, errore mio. Di queste, direi che il 60% hanno prodotto codice funzionante al primo tentativo. Il 30% ha richiesto due o tre iterazioni. Il restante 10% sono le notti come quella del martedì alle 23:47.

Quella notte ho capito cosa stava succedendo dopo quarantacinque minuti di analisi insieme a Claude. Avevo un oggetto che in certi casi tornava None invece del dizionario che mi aspettavo. Poi cercavo di chiamarci sopra il metodo .get(). Una riga di controllo ha risolto tutto. Una riga.

Quarantacinque minuti per una riga. Questo è lo sviluppo software quando non sai sviluppare.

La piattaforma oggi ha circa 4.200 righe di codice tra backend e frontend. Ne ho scritte direttamente forse duecento — commenti, piccole correzioni, variabili rinominate. Il resto è Claude. Ma so leggere tutto. So spiegare cosa fa ogni pezzo principale. Non sono diventato uno sviluppatore. Sono diventato qualcuno che capisce il codice che ha in produzione, che è una cosa diversa ma non è poco.

Cosa non ti dicono sul "vibe coding"

C'è un termine che gira — vibe coding, costruire software descrivendolo in linguaggio naturale senza capire il codice sottostante. Lo trovo pericoloso come approccio, almeno per quello che stiamo facendo noi.

Se non capisci il codice che hai in produzione, non sai cosa può andare storto. Quando va storto alle 23:47, sei solo davanti a quattrocentosessanta righe di geroglifici. Il mio obiettivo non è mai stato non capire. È imparare abbastanza da non essere completamente cieco.

Claude è un co-developer eccellente. Non è un sostituto del capire cosa stai costruendo.

Stefano mi ha detto una cosa la settimana scorsa, mentre guardavamo insieme un pezzo di logica che non tornava: "Stai diventando un programmatore che non lo sa." Non so se era un complimento. L'ho preso come tale.

Il prossimo episodio parla di RistoDocs — la prima applicazione verticale che abbiamo staccato da BrainRooms per portarla su un mercato specifico. Come si decide di fare un pivot prima ancora di avere utenti. E perché Stefano aveva ragione e io avevo torto, cosa che nella nostra storia accade con una frequenza che preferisco non quantificare.