Prologo: La riunione che cambia tutto
È un lunedì mattina di gennaio 2024 quando Franklin Nmap riceve la convocazione. Oggetto: "Strategia digitale 2024 - presenza obbligatoria". Nel corridoio verso la sala riunioni incrocia Eleanor, una delle developer senior del suo team.
"Sai di cosa si tratta?" chiede lei.
Franklin sorride. "Ho sentito voci. Pare che finalmente investiremo seriamente in AI."
Eleanor alza un sopracciglio. "Tipo?"
"Coding assistants, automazione, roba così. Era ora, no? Tutti lo fanno."
Nella sala riunioni ci sono già una ventina di persone: CTO, altri project manager, alcuni team lead. Il CEO, Theodore Sudo, prende la parola senza preamboli.
"Siamo in ritardo. I nostri competitor rilasciano feature ogni due settimane, noi ogni due mesi. Il board mi ha dato mandato di rivoluzionare il processo di sviluppo. La risposta è una sola: intelligenza artificiale generativa."
Schermo: slide con grafici impressionanti. "GitHub Copilot riduce il tempo di coding del 15%". "Claude può scrivere microservizi completi in minuti". "OpenAI reports: teams are 3x faster".
Franklin sente l'adrenalina. Finalmente. Anni a sentirsi dire "fate più veloce" senza averne gli strumenti. Ora arrivano.
"Cercherò volontari per un progetto pilota," continua Sudo. "Chi ha il coraggio di essere pioniere?"
Franklin alza la mano prima ancora di pensarci. È il primo. Altri tre lo seguono, più titubanti.
Uscendo, Eleanor lo ferma. "Franklin, sei sicuro? Questi tool sono potenti ma..."
"Ma cosa? Eleanor, hai visto i numeri. Quindici percento è un regalo. E probabilmente sono prudenti."
"I numeri misurano velocità, non qualità. E comunque—"
"Eleanor," l'interrompe Franklin, non sgarbato ma risoluto. "Ho trentotto anni. Ho passato metà carriera a sentirmi dire che eravamo troppo lenti. Questa è la svolta. Se non la cogliamo noi, la coglierà qualcun altro."
Atto I: L'euforia del convertito
Due settimane dopo - Kick-off del progetto pilota
Franklin ha preparato la presentazione con cura maniacale. Venti slide, ciascuna più entusiasta della precedente. Il team è al completo: otto developer (tre senior, cinque junior), due QA specialist, un DevOps engineer.
"Benvenuti nel futuro," esordisce Franklin. Lo schermo mostra il logo di Claude e GitHub Copilot affiancati. "Questi tool ci daranno superpoteri."
Scorre i case study che ha trovato:
- CloudWalk: "da spec a working code in minuti, non giorni"
- Una startup non nominata: "abbiamo eliminato il 70% del boilerplate code"
- Virgin Atlantic: "context switching ridotto, developer più focalizzati"
"La domanda non è se usarli," dice Franklin, "ma come usarli al meglio."
Abraham Curl, uno dei developer junior, è visibilmente eccitato. "Quindi posso chiedere all'AI di scrivermi una REST API completa?"
"Esatto. Tu ti concentri sulla logica di business, l'AI fa il lavoro sporco."
Eleanor alza la mano. Ha quell'espressione che Franklin ha imparato a riconoscere: sta per fare la guastafeste.
"Franklin, una domanda. Come gestiamo il codice che non abbiamo scritto noi? Intendo: in code review, come facciamo a capire se quello che ha generato l'AI è corretto?"
"Ottima domanda," risponde Franklin, che in realtà l'aveva sperata di non ricevere. "L'AI è addestrata su milioni di repository. GitHub, Stack Overflow, tutto il codice open source del mondo. Probabilmente conosce pattern e best practice meglio di noi."
"Ma non capisce cosa scrive," insiste Eleanor. "Genera pattern probabilistici. Se gli chiedi una cosa strana, ti dà una risposta che sembra sensata ma—"
"Eleanor," l'interrompe Ronald Chmod, il DevOps engineer. "Con tutto il rispetto, questa è la classica resistenza al cambiamento. Quando è arrivato Git dicevano che CVS era più sicuro. Quando è arrivato Agile dicevano che Waterfall era più controllato. Siamo ancora qui a temerci per ogni innovazione?"
Qualche risatina nel team. Eleanor non risponde, ma Franklin vede che stringe le labbra.
"Tranquilli," dice Franklin in tono conciliante. "Faremo tutto con criterio. Ora: ridefiniamo la Definition of Done."
Proietta sullo schermo la DoD corrente:
- Codice implementato e committed
- Unit test copertura minima 80%
- Integration test per gli endpoint
- Code review approvata da senior
- Documentazione API aggiornata
- Nessun warning del linter
"Alcune di queste voci," dice Franklin, "erano necessarie quando scrivevamo tutto a mano. Ora possiamo snellire."
Eleanor: "Quale per esempio?"
"I test manuali. Se l'AI genera codice e test insieme, verificati per coerenza, perché dovremmo riscriverli?"
Silenzio imbarazzato.
"Franklin," dice finalmente Eleanor, "i test non servono solo a verificare che il codice funzioni. Servono a documentare le intenzioni. Se li genera l'AI, chi garantisce che testino quello che vogliamo testare, non solo quello che il codice fa?"
Franklin sente montare l'irritazione. Eleanor è brava, ma a volte è troppo accademica.
"Guarda," dice, "facciamo così. Primo sprint: sperimentiamo. AI-generated code con AI-generated tests. Facciamo code review attenta. Se vediamo problemi, aggiustiamo. Va bene?"
Annuiscono tutti. Anche Eleanor, seppur di malavoglia.
Sprint Planning - Febbraio 2024
Franklin guarda il backlog con soddisfazione. Ottanta story points. Di solito ne facevano quaranta.
"Sicuro?" chiede Jacqueline Kill, una delle QA specialist. "Non rischiamo di over-committare?"
"Jacqueline, fidati. Con l'AI possiamo fare il doppio. Anzi, probabilmente siamo ancora prudenti."
Assegna le user story. Ad Abraham, il junior, tocca una particolarmente complessa: "Implementare sistema di code delle transazioni con retry logic e dead letter queue."
Abraham impallidisce. "Franklin, questa normalmente la farebbe un senior..."
"Esatto: normalmente. Ma tu hai Claude. Spiegagli il requirement, chiedigli l'implementazione, studia quello che ti dà. È un'occasione di crescita."
Abraham annuisce, non convintissimo.
Prima settimana di sprint - L'illusione della velocità
La daily standup del mercoledì è euforica.
Abraham: "Ho finito la queue con retry. Claude mi ha scritto tutto il boilerplate, io ho solo aggiustato la business logic. Mezza giornata invece di tre giorni."
Ronald: "Ho automatizzato il deployment. L'AI mi ha generato gli script Terraform che avrei impiegato una settimana a scrivere."
Anche i senior sembrano impressionati. Eleanor ha usato l'AI per refactoring di un modulo legacy - "mi ha suggerito pattern che non avevo considerato, devo ammetterlo."
Franklin è raggiante. Venerdì sera manda email al CTO: "Sprint a metà, già completato 60% delle story. Saremo in anticipo."
Il CTO risponde in cinque minuti: "Ottimo lavoro. Il board sarà felice."
Atto II: Le prime crepe
Seconda settimana - Il dettaglio che sfugge
Lunedì mattina. Jacqueline, la QA, ferma Franklin prima della standup.
"Ho un problema con la queue di Abraham."
"Che tipo di problema?"
"I test passano tutti. Ma quando ho provato a simulare un carico reale con 1000 transazioni concorrenti... si comporta in modo strano."
"Strano come?"
"A volte alcune transazioni spariscono. Non vanno in errore, non finiscono nella dead letter queue. Semplicemente... svaniscono."
Franklin aggrotta le sopracciglia. "Hai un esempio riproducibile?"
"È intermittente. Succede circa 1 volta ogni 500 run."
"Jacqueline, guarda, abbiamo una deadline. Un bug che capita lo 0.2% delle volte in condizioni di stress test... lo mettiamo nel backlog per dopo. Ora dobbiamo chiudere lo sprint."
Jacqueline esita. "Ma è un sistema di transazioni finanziarie..."
"Lo so. E infatti lo sistemeremo. Ma dopo il rilascio. Priorità: chiudere le feature pianificate."
Jacqueline non sembra convinta ma annuisce.
Sprint Review - Fine febbraio
La demo è un trionfo. Il CTO è presente, e persino Sudo, il CEO, si collega in videochiamata.
Franklin mostra le otto user story completate. Tutte funzionano perfettamente nelle demo. Il team ha fatto 85 story points - più del doppio della velocity storica.
"Straordinario," dice il CTO. "Franklin, questo è il modello. Voglio che gli altri team adottino lo stesso approccio."
Dopo la riunione, Eleanor ferma Franklin.
"Hai visto la faccia di Jacqueline durante la demo?"
"Era concentrata. Perché?"
"Franklin, quel bug della queue... l'hai considerato davvero?"
"Eleanor, è uno 0.2%. E succede solo sotto stress test."
"È un race condition," dice Eleanor a voce bassa. "Ho guardato il codice. L'AI ha usato un pattern che in teoria è corretto ma ha una finestra di 30 millisecondi dove due thread possono interferire. Nel test funziona perché il carico è basso. In produzione..."
"In produzione," l'interrompe Franklin, "avremo il monitoring. Se c'è un problema, lo vedremo e lo fixeremo. Eleanor, apprezzo la tua attenzione al dettaglio, ma non possiamo fermare il progresso per paranoia."
Eleanor lo guarda per un lungo momento. "Ok, Franklin. Spero tu abbia ragione."
Atto III: Il deploy maledetto
Early March - Production Release
Il deploy è programmato per il giovedì sera. Franklin ha organizzato una "war room" virtuale: tutto il team in call, pronti a intervenire al primo segnale di problema.
- 22:30 - Deploy completato
- 22:45 - Smoke test: tutto verde
- 23:00 - Primi utenti reali sul sistema: nessun errore
- 23:30 - Franklin manda il team a casa. "Ottimo lavoro. Ci vediamo domani."
Venerdì mattina, Franklin si sveglia con 47 notifiche Slack.
Il cuore gli si ferma.
Apre la chat. Ronald, il DevOps, ha scritto alle 6:43: "@franklin URGENT: errori massivi sul database. Sistema offline."
Franklin chiama mentre si veste.
"Che è successo?"
La voce di Ronald è tesa. "Stanotte, verso le 3, qualcosa ha iniziato a corrompere i record nel database delle transazioni. Prima pochi, poi sempre di più. Alle 6 abbiamo fatto rollback ma... Franklin, abbiamo perso dati."
"Quanti?"
"Stiamo ancora verificando. Ma parliamo di almeno duecento clienti con transazioni corrotte o scomparse."
Franklin sente il sangue defluire dalla testa.
La root cause analysis - Una settimana dopo
La sala riunioni è piena. CTO, COO, Legal, Compliance, e tutto il dev team. Nessuno sorride.
Eleanor presenta i risultati dell'indagine. Ha passato quattro giorni a ricostruire cosa è successo.
"Il problema," dice proiettando del codice sullo schermo, "è in questo punto. La queue implementation generata da Claude."
Mostra una sezione:
def process_transaction(self, transaction):
if self.cache.get(transaction.id):
return # Already processed
self.cache.set(transaction.id, True)
result = self.execute(transaction)
if not result.success:
self.dead_letter_queue.add(transaction)
"Sembra corretto," continua Eleanor. "C'è un check per evitare duplicati, c'è la gestione errori. Il problema è la tempistica. Tra il get e il set del cache, c'è una finestra di circa 30 millisecondi. Se due thread gestiscono la stessa transazione in quella finestra, entrambi vedono che non è nel cache, entrambi la processano."
"Ma questo," interviene Abraham, visibilmente scosso, "doveva essere gestito dai test."
"I test," dice Eleanor senza accusare, "erano stati generati dall'AI insieme al codice. Testavano che il codice facesse quello che diceva di fare, non che fosse thread-safe in scenari reali."
Silenzio pesante.
Il CTO chiede: "Danni economici?"
Il COO risponde: "Ancora da quantificare completamente. Ma parliamo di almeno 450.000 euro tra recovery, compensazioni clienti, e costi legali. Forse di più."
Sudo, il CEO, è in video. La sua voce è gelida: "Voglio capire come è stato possibile. Franklin?"
Franklin deglutisce. "Abbiamo accelerato il processo di sviluppo usando AI. I test automatici passavano tutti. Non abbiamo rilevato la race condition perché—"
"Perché non avete fatto code review seria," l'interrompe Sudo. "Giusto?"
"Abbiamo fatto code review," si difende Franklin. "Ma ci siamo fidati dell'AI. I dati dicono che genera codice di qualità, quindi—"
"I dati," lo interrompe di nuovo Sudo, "dicono che l'AI scrive codice velocemente. Non dicono che scrive codice sicuro. Questa confusione ci è costata mezzo milione di euro e la fiducia di duecento clienti."
Franklin sente il pavimento mancare sotto i piedi.
Atto IV: Il reckoning
Post-mortem meeting - Due settimane dopo
La situazione è sotto controllo, tecnicamente. I dati sono stati recuperati (per fortuna avevano backup). I clienti sono stati compensati. Ma il danno reputazionale è fatto.
Franklin ha scritto un documento di 15 pagine: "Lessons Learned and Corrective Actions". Lo presenta al team.
"Ho identificato cinque problemi critici:
- Abbiamo rimosso salvaguardie senza valutarne l'impatto
- Abbiamo confuso velocità con valore
- Abbiamo delegato all'AI responsabilità che erano nostre
- Non abbiamo fatto risk assessment adeguato
- Abbiamo ignorato warning signals"
Eleanor alza la mano. "Franklin, con tutto il rispetto... questi sono sintomi, non cause. La causa è che hai trattato l'AI come una soluzione invece che come uno strumento."
"Che intendi?"
"L'AI non risolve problemi di processo. Li amplifica. Se il tuo processo era: 'scrivi veloce, testa poco, rilascia', l'AI ti ha permesso di farlo 3x più veloce. Il risultato è un disastro 3x più grande."
Franklin sente la rabbia montare. "Eleanor, è facile fare la splendida col senno di poi. Anche tu hai usato l'AI. Anche tu hai—"
"Io," l'interrompe Eleanor con calma, "ho usato l'AI per refactoring con supervisione umana completa. Tu hai usato l'AI per scrivere logica business critica e poi hai rimosso i controlli perché 'rallentavano'. C'è una differenza."
Abraham, che finora era stato zitto, interviene. "È colpa mia. Io ho scritto quel codice."
"No," dice Eleanor gentile. "Tu sei junior. Hai fatto quello che ti è stato chiesto. La responsabilità è di chi ha creato il processo."
Tutti guardano Franklin.
L'incontro privato - Ufficio del CTO
"Franklin, sei un ottimo project manager. Ma hai fatto un errore classico: hai letto i dati che confermavano quello che volevi credere."
"I dati di OpenAI, GitHub, erano chiari—"
"Erano incompleti," lo corregge il CTO. "Dicevano: 15% più veloci nel coding. Non dicevano: e la qualità? E la sicurezza? E il technical debt? Tu hai preso la metà della storia che ti piaceva."
"Cosa vuoi che faccia?"
"Voglio che tu capisca: l'AI è un moltiplicatore. Se moltiplichi competenza, ottieni eccellenza scalata. Se moltiplichi fretta e superficialità, ottieni disastri scalati. Non c'è via di mezzo."
Franklin annuisce, ma sente che il CTO non ha finito.
"C'è un'altra cosa. Il board ha deciso che il progetto AI continua, ma non sotto la tua guida. Eleanor prenderà il controllo."
"Eleanor? Ma lei era scettica dall'inizio!"
"Esatto. E aveva ragione. Non era luddismo, era prudenza. Aveva capito che accelerare senza capire dove vai significa solo schiantarsi più velocemente."
Epilogo: Il trasferimento
Sei mesi dopo
Franklin ha cambiato azienda. Una startup nel settore e-commerce, ambiente più dinamico, meno regole. Quando in colloquio gli hanno chiesto dell'esperienza con AI, ha risposto con sicurezza: "Ho guidato un progetto pilota. Abbiamo imparato molto."
Non ha menzionato il disastro. Non tecnicamente una bugia - hanno davvero imparato.
Primo giorno nella nuova azienda. Il CTO presenta la roadmap: "Adotteremo Claude e Copilot per accelerare lo sviluppo. Tu hai esperienza, vero Franklin?"
"Sì," risponde Franklin. "Questa volta faremo le cose per bene."
Ma mentre lo dice, sente un'eco nella mente: ho già detto questa frase?
Riflessione finale
La storia di Franklin non è rara. È la norma.
Quando arriva una nuova tecnologia potente, il primo istinto è l'entusiasmo. I dati sembrano chiari: 15% più veloci, 3x productivity, costi ridotti. Chi non vorrebbe?
Il problema è che quei dati misurano output, non outcome. Misurano quante righe di codice scrivi, non se quel codice risolve il problema giusto. Misurano quanto veloce vai, non se stai andando nella direzione corretta.
Franklin aveva letto i case study di successo: CloudWalk che genera microservizi in minuti, Novo Nordisk che passa da 12 settimane a 10 minuti. Ma aveva saltato la parte importante: quei successi erano arrivati dopo aver formalizzato i processi, dopo aver capito cosa automatizzare e cosa no, dopo aver costruito le guardrail.
Lui aveva fatto il contrario: aveva rimosso le guardrail pensando fossero friction inutile. I test manuali, la code review rigorosa, la prudenza di Eleanor - tutto sembrava rallentarlo. E invece erano l'ultima difesa contro l'errore umano amplificato dall'AI.
L'ironia è che Franklin aveva ragione su una cosa: i competitor stavano accelerando. Ma quelli che avevano successo non erano quelli che andavano più veloce. Erano quelli che andavano alla velocità giusta - abbastanza veloci da competere, abbastanza cauti da non schiantarsi.
Nella nuova azienda, Franklin dice "questa volta faremo le cose per bene". Ma senza aver capito cosa è andato storto - non tecnicamente, ma culturalmente - probabilmente ripeterà gli stessi errori.
Perché il vero problema di Franklin non era l'AI. Era la sua convinzione che accelerare fosse sempre meglio. Che i processi fossero burocrazie da eliminare. Che i warning fossero pessimismo da ignorare.
L'AI aveva solo reso queste tendenze più evidenti, più veloci, più costose.
La lezione che Franklin non ha ancora imparato è questa: non puoi automatizzare il giudizio. Puoi automatizzare l'esecuzione, la generazione, la ripetizione. Ma decidere cosa vale la pena fare, come farlo in modo sicuro, quandofermarsi a riflettere - questo è irriducibilmente umano.
L'AI è uno strumento magnifico. Ma nelle mani di chi pensa che "più veloce" sia sempre meglio, diventa un amplificatore di disastri.
E i disastri, quando arrivano, costano €450.000.
O forse di più.