Uno sviluppatore di medio livello entra in un progetto nuovo. Invece di passare le prime settimane a capire il codice esistente e come funziona il dominio, apre un assistente AI e inizia a produrre feature. I ticket si chiudono, le pull request arrivano, i test passano. Tutto sembra ottimo. Dopo un mese, i numeri parlano: questa persona produce il doppio di chi è entrato con lo stesso ruolo un anno fa. Un anno fa sarebbe stato un mezzo disastro, oggi sembra una notizia entusiasmante. Non lo è, e la differenza tra le due cose si paga in produzione.
Una scena che si ripete
In un punto del prodotto c'è un'operazione che, quando l'utente salva, deve aspettare un calcolo in background prima di aggiornare una parte della pagina. Ci sono due modi ovvi di farlo. Il primo: aspettare qualche decimo di secondo in più, salvare, rileggere il dato, mostrarlo. Venti righe di codice. Il secondo: salvare subito, far girare il calcolo in modo asincrono, notificare la pagina quando il calcolo finisce e aggiornare il DOM in tempo reale. Un sistema di code, un canale di notifica real-time al browser, logica di reconnect, gestione degli stati intermedi. È anche molto più interessante da scrivere.
Lo sviluppatore sceglie il secondo. L'AI lo aiuta, il codice esce pulito, ordinato, testato, e la PR passa la review. Arriva in produzione e non succede nulla. Per qualche settimana.
Il problema emerge dopo: il calcolo in background, nel sistema reale, non dura mezzo secondo. Dura minuti, a volte ore — il backend lo gestisce in una coda che dipende dal carico. Nel frattempo l'utente ha cambiato pagina, aperto altro, riaperto lo stesso schermo in un'altra scheda. Quando finalmente la notifica arriva, trova un DOM che non esiste più, o peggio ne aggiorna uno che non doveva aggiornare. L'utente vede la pagina rompersi in modo incomprensibile. A volte perde dati.
L'errore non era nel codice
Il codice era scritto decentemente. La review non ha trovato nulla perché tecnicamente era tutto corretto. L'errore era una scelta architetturale che nessuno ha mai discusso esplicitamente: non serviva un sistema real-time per un problema che si risolveva aspettando mezzo secondo al salvataggio. La soluzione semplice era anche quella giusta, la soluzione sofisticata ha introdotto una classe di bug che nel modello banale non poteva nemmeno esistere.
Lo sviluppatore non l'ha visto perché non conosceva ancora il prodotto — era da poco sul progetto e aveva saltato la fase di studio. Non sapeva che quei calcoli potevano durare ore, non aveva osservato come gli utenti usavano davvero quella pagina. L'AI non poteva vederlo: ha risposto alla domanda "come aggiorno una pagina in modo asincrono" con la risposta più sofisticata disponibile, non con quella più adatta al contesto. Nessuno dei due aveva il contesto, e il contesto è l'unica cosa che l'AI non può ricostruire da sola.
La review non l'ha intercettato per un motivo strutturale: una PR review guarda il codice, non l'architettura. Controlla che i test passino, che lo stile sia giusto, che non ci siano errori evidenti. Raramente chiede "ma serviva davvero fare così?". Quando il codice è pulito e viene da qualcuno che usa l'AI, la review diventa ancora meno sensibile, perché quel codice è indistinguibile da qualsiasi altro codice dello stesso tipo.
Velocità di produzione, superficie di decisioni
Questa non è una scena isolata. È quello che sta succedendo in tantissimi team che hanno adottato l'AI senza ripensare come lavorano. La produttività sale ed è facilmente misurabile: più PR, più ticket chiusi, più codice in arrivo. Sotto la superficie si accumulano scelte architetturali che nessuno ha mai vagliato, e ognuna di quelle scelte è una piccola bomba a tempo.
La bomba non esplode nelle settimane di sviluppo. Esplode in produzione, mesi dopo, quando gli utenti iniziano a segnalare bug che si moltiplicano quando tocchi qualcosa, data loss a bassa frequenza ma alto impatto, comportamenti strani che in ambiente di test non si riproducono. Casi limite che non corrispondono mai alla documentazione, perché la documentazione non esiste: chi ha scritto il codice non aveva tempo, e l'AI lo ha seguito sulla velocità.
Il costo lo paga chi ha commissionato il software. Lo paga nel crescere dei ticket di produzione, nei tempi di risposta del team su problemi che "non capiamo da dove vengano", nel momento in cui qualcuno deve smantellare un'architettura inutilmente complicata e rimetterla semplice — una seconda volta, con un altro team.
L'AI amplifica quello che già c'è
L'AI nelle mani di uno sviluppatore senior amplifica il giudizio: chi già sa riconoscere quando una soluzione semplice batte una soluzione impressionante usa l'AI per andare più veloce su quella strada. L'AI nelle mani di uno sviluppatore meno esperto amplifica l'ottimismo: la fiducia che, siccome il codice funziona nei test, allora la soluzione è giusta. Più aumenta la velocità con cui il team produce, più aumenta la superficie di decisioni non controllate.
La contromisura non è togliere l'AI al team, cosa che nessuna azienda con un minimo di senso farà. È cambiare il criterio con cui si valuta il lavoro. Il mestiere oggi non è produrre codice: quello l'AI lo fa in fretta, pulito, spesso meglio di un umano. Il mestiere è capire il problema, scegliere la soluzione più semplice che risolve davvero, proteggere le scelte architetturali nei momenti in cui conta farlo.
La domanda da fare al team
Chi guida o commissiona un team che usa l'AI dovrebbe smettere di chiedere "quanto producete in uno sprint?" e iniziare a chiedere "quanto di quello che avete prodotto negli ultimi tre mesi pensate di tenere tra un anno?". È la domanda che filtra la velocità utile dalla velocità pericolosa. Oggi molti team non sanno rispondere, o peggio rispondono "tutto" senza averci pensato sopra.
Il fatto che il codice funzioni non significa che sia una buona idea. È una distinzione che l'AI ha reso molto più importante, perché il codice che funziona ma è una cattiva idea oggi si produce dieci volte più in fretta di prima. In produzione si paga esattamente uguale.
Simone Giusti
Consulente software strategico
