Episodio 7 — Benvenuto Developer AI

AI Founder — il diario di una startup

Erano le 23:47 di un martedì. Avevo davanti un messaggio di errore lungo quarantadue righe. Non capivo nemmeno dove finisse l'errore e dove iniziasse la spiegazione dell'errore. Stesso colore. Stesso font. Uguale.

Ho copiato tutto. Ho incollato in Claude. Ho scritto: "Cosa sta succedendo?"

È così che si scrive software senza saper programmare.

Quando ho deciso di costruire BrainRooms, sapevo che avrei dovuto affrontare il problema del codice. Non avevo un CTO. Non avevo budget per assumerne uno — le quotazioni che avevo raccolto parlavano di cifre tra i 4.000 e i 7.000 euro al mese, e io avevo esattamente zero di quei numeri disponibili. Avevo Claude e la mia determinazione a non ammettere che forse stavo sopravvalutando entrambi.

Il piano era semplice: descrivere quello che volevo, Claude lo avrebbe scritto. Come spiegare a un artigiano cosa costruire senza saper usare gli strumenti. Nobile analogia. Peccato che l'artigiano non sbaglia. Claude invece sì.

Il primo blocco funzionante l'ho avuto dopo tre giorni. Autenticazione utenti: entri, esci, la sessione non ti fa fuori dopo trenta secondi. Sembrava poco. Era tutto. Quando hai zero come punto di partenza, ogni pezzo che funziona è una vittoria reale.

Il problema vero è iniziato con la logica dei permessi. BrainRooms ha ruoli diversi: chi propone un'idea, chi la valuta, chi amministra. Ogni ruolo vede cose diverse, può fare cose diverse, viene indirizzato in percorsi diversi. Sulla carta è lineare. Nel codice è una serie di condizioni annidate dentro altre condizioni, dentro funzioni che chiamano altre funzioni.

Ho descritto il comportamento che volevo. Claude ha scritto il codice. Ho testato. Funzionava per tre ruoli su cinque.

Ho segnalato il problema. Claude ha corretto. Funzionava per quattro ruoli su cinque. Il quinto faceva una cosa che non avevo chiesto a nessuno di fare: vedeva tutto, senza restrizioni. Come un master key accidentale. Utile, per carità — ma non era quello il punto.

Ho riscritto quel pezzo tre volte in dieci giorni. Tre volte. La terza volta ho capito che il problema non era nel codice che Claude scriveva. Era nella mia descrizione del problema. Descrivevo il comportamento che vedevo, non la logica che volevo. Differenza sottile. Conseguenze enormi.

Ho imparato qualcosa che non trovi scritto nei tutorial: lavorare con un AI developer richiede precisione descrittiva, non competenza tecnica. Devi sapere cosa vuoi con esattezza. L'AI esegue quello che descrivi, non quello che intendi. Se lasci spazio all'interpretazione, interpreta — e non sempre nella direzione giusta.

Ho iniziato a scrivere le richieste in modo diverso. Non "fai sì che l'utente valutatore non veda le idee in bozza". Ma: "L'utente con ruolo 'valutatore' non deve accedere a nessun record con stato uguale a 'draft', né dalla lista né dalla pagina singola. Se prova ad accedere direttamente via URL, reindirizzalo alla dashboard."

Claude ha scritto il codice al primo tentativo. Funzionava.

La differenza era tutta nella mia testa, non nel modello.

La notte peggiore è stata quella del database. Avevo una struttura che sembrava logica — l'avevo disegnata su carta, poi descritta, poi riscritta — ma quando ho caricato i primi dati reali, le query restituivano risultati che non tornavano. Dati duplicati in alcuni casi. Assenti in altri. Nessun errore visibile. Solo numeri sbagliati.

Erano le 2:10. Stefano stava dormendo — e faceva bene, visto che di mattina aveva appuntamenti. Io avevo caffè e testardaggine.

Ho passato quaranta minuti a descrivere il problema a Claude nel modo più preciso che riuscivo. Non il codice — il comportamento. Cosa succedeva, in quale sequenza, con quali dati di input. Claude ha identificato un conflitto nella struttura delle relazioni tra tabelle. Mi ha spiegato perché succedeva. Mi ha proposto la correzione.

Ho letto la spiegazione due volte. Non perché fossi bravo — per capire se stavo facendo la scelta giusta. Alle 3:20 il database funzionava. Non si stufa, non si innervosisce, non mi guarda come se fossi l'undicesima persona che gli pone la stessa domanda. Alle due di notte è un vantaggio non marginale.

Ad oggi BrainRooms ha autenticazione, gestione ruoli, stanze di lavoro per fase dell'innovazione, un coach AI interno, un blog automatizzato. Settantaquattro componenti funzionanti, se contiamo anche quelli piccoli. Costo mensile dello stack tecnico: poco meno di 200 euro tra cloud e API. Meno di un quarto di quello che costerebbe un singolo giorno di consulenza di un senior developer.

Non so scrivere codice. So descrivere problemi con precisione. È diventata la mia competenza tecnica.

Stefano, che di tecnologia capisce molto più di me, a volte guarda il codice prodotto e dice che è pulito. Lo dice con una certa sorpresa, che cerco di non prendere sul personale. Non sempre ci riesco.

Il prossimo episodio parla di quello che succede dopo che il codice funziona: i primi utenti reali entrano nella piattaforma. Cosa fanno. Cosa non fanno. E perché quello che avevo immaginato e quello che succede davvero sono due cose che si assomigliano solo in superficie.