C’è stato un giorno preciso in cui ho smesso di cercare il bug nel codice.
Stavo lavorando a Genesis — un progetto che costruisco da solo, la sera, dopo il lavoro. Io e un’AI. Nessun team, nessun budget, nessun investitore. Avevo fatto una modifica piccola, una di quelle che non dovrebbero rompere niente. Invece si era rotto tutto — ma non nel punto dove avevo toccato. Si era rotto tre passaggi dopo, in un’area che non c’entrava nulla. O almeno così mi sembrava.
La prima reazione era sempre la stessa: trovare il file, cercare la riga, correggere. Ma quella sera qualcosa è cambiato. Ho guardato la catena di decisioni che mi aveva portato lì e mi sono accorto che il problema non era nel codice. Era nel fatto che non esisteva un processo per decidere cosa modificare, chi verifica, cosa succede dopo.
Ogni decisione era isolata. Presa al momento, senza un passaggio di verifica, senza una separazione tra chi decide e chi esegue. In un progetto dove sei solo con un’AI, questo significa che ogni errore di processo si amplifica — perché non c’è nessun altro a intercettarlo.
Quel giorno ho smesso di guardare il codice e ho iniziato a guardare il processo. E il capovolgimento è stato netto: il problema era lì. Prima del codice. Molto prima.
Ho provato a mettere regole dove prima c’era solo fiducia cieca. Checkpoint dove prima si andava dritto. Rallentare nei punti in cui tutto mi diceva di accelerare — perché era proprio lì che le cose si rompevano senza che me ne accorgessi.
Oggi si parla molto di governance dell’AI. Framework, documenti, policy — ogni settimana esce qualcosa di nuovo. E ha senso che se ne parli. Ma la maggior parte di chi ne parla, ne parla dal punto di vista del documento strategico. Io ne parlo dal punto di vista di chi stava nel cantiere quando è crollato il muro.
Sento che la differenza sta lì. Non nel sapere che serve governance — lo sanno tutti. Ma nel viverla come necessità prima che come best practice. Quando le regole nascono perché senza di esse il progetto muore, hanno una forma diversa da quelle che nascono in un documento.
Non so se questo approccio vale per tutti. È nato dal mio contesto — un progetto costruito da solo, dove ogni errore si amplifica. Ma mi chiedo se non ci sia qualcosa di trasferibile: l’idea che le regole migliori non si scrivono prima di sbagliare, ma dopo.