Il codice che sembra funzionare, e il progetto che funziona davvero

Metodo

Un'azienda decide di costruire internamente un piccolo strumento digitale — un portale per i clienti, un'automazione, un'app interna. Con l'intelligenza artificiale il progetto avanza in giorni, non in mesi. Chi lo ha commissionato è entusiasta: rapido, economico, già online.

Qualche mese dopo, qualcosa si inceppa. Un dato sparisce senza spiegazione. Un accesso che doveva essere limitato non lo era. Un fornitore esterno segnala una falla in una libreria che nessuno in azienda sapeva di usare. Nessuno aveva mai guardato davvero dentro quel codice — perché sembrava funzionare, e funzionare sembrava sufficiente.

Non era un problema di intelligenza artificiale. Era un problema di decisione: nessuno aveva chiesto, prima di dire sì, chi avrebbe verificato ciò che nessuno aveva scritto di proprio pugno.

Questo scenario si sta ripetendo in molte organizzazioni, e non solo nei reparti IT. La rapidità con cui oggi si può produrre software genera un'illusione precisa: se un'app "funziona" — si apre, risponde, non va in errore — allora è pronta. Ma un sistema che funziona oggi, davanti a chi lo guarda, e un sistema che regge nel tempo, sotto pressione, con dati reali e utenti reali, sono due cose diverse. La differenza tra i due non si vede al momento del lancio. Si vede dopo.

È lo stesso principio che vale per un impianto tecnico o un'infrastruttura fisica: il costo e il rischio reali non emergono all'installazione, emergono nella gestione quotidiana, nella manutenzione, nel momento imprevisto. Il software costruito in fretta non fa eccezione — anzi, essendo meno visibile di un impianto, il problema può restare nascosto più a lungo, proprio perché nessuno pensa di doverlo ispezionare.

C'è poi un secondo livello, ancora meno visibile del primo. Un'applicazione generata rapidamente si appoggia quasi sempre su componenti esterni — librerie, moduli, servizi di terzi — scelti in automatico, senza che nessuno si sia chiesto chi li mantiene, quanto sono aggiornati, quanto sono esposti. È un po' come costruire su fondamenta prese in prestito da qualcun altro, senza mai averle ispezionate. Funzionano, finché funzionano. E quando smettono di farlo, il problema non riguarda più una singola applicazione: riguarda tutto ciò che vi si appoggiava.

Nessuna di queste osservazioni è un invito a rallentare, né tantomeno a diffidare degli strumenti che oggi permettono a chiunque di costruire qualcosa di reale in tempi che dieci anni fa erano impensabili. È, piuttosto, un invito a distinguere.

Un prototipo, uno strumento interno a basso rischio, un'idea da validare in fretta: sono terreni dove la velocità è un vantaggio puro, senza contropartite significative. Un sistema che tocca dati sensibili, pagamenti, identità, continuità operativa: è un altro tipo di decisione, e richiede un altro tipo di verifica — non perché la tecnologia sia inadeguata, ma perché nessun errore, in quel contesto, è privo di conseguenze.

La domanda giusta non è se l'intelligenza artificiale sappia scrivere codice buono. La domanda è: chi, nella vostra organizzazione, si è fermato a guardare cosa è stato costruito — prima che lo scoprisse qualcun altro al posto vostro.