Prologo: La chiamata inattesa
Eleanor Rsync sta revisionando il backlog quando squilla il telefono interno. È Woodrow Bash, il CEO di FinTech Dynamics.
"Eleanor, hai cinque minuti? Devo parlarti."
Quarantadue anni, background misto: cinque anni come developer, otto come QA, quattro come project manager. Eleanor ha visto progetti fallire per fretta e progetti morire per burocrazia. Non è entusiasta per natura, ma non è nemmeno cinica. È semplicemente... pragmatica.
Nell'ufficio di Bash c'è anche Calvin Ssh, il CTO.
"Siediti," dice Bash. "Abbiamo una proposta per te."
Eleanor si accomoda, curiosa.
"Sai che stiamo valutando l'adozione di AI generativa per lo sviluppo," inizia Ssh. "Abbiamo fatto due pilot. Uno è andato... male. L'altro è andato troppo lento."
Eleanor annuisce. Ha sentito le storie: Franklin Nmap e il disastro da mezzo milione, Rosalynn Cat e il framework di 47 pagine.
"Vogliamo un terzo tentativo," dice Bash. "Ma questa volta vogliamo qualcuno che non cada in nessuno dei due estremi. Qualcuno che sappia bilanciare velocità e sicurezza."
"E pensate a me."
"Esatto," dice Ssh. "Tu hai esperienza tecnica. Sai scrivere codice, quindi capisci cosa l'AI può e non può fare. Hai fatto QA, quindi conosci i rischi. E come PM hai gestito sia progetti agili che progetti critici. Sei... equilibrata."
Eleanor riflette. "Perché non James Ping? Il suo pilot è andato bene."
"James è bravo," ammette Bash, "ma opera in ambiente meno critico. Tu lavori su sistemi di pagamento. Se un bug passa, non perdiamo faccia. Perdiamo soldi. Nostri e dei clienti."
Eleanor capisce. FinTech è regolamentato, ma non come pharma. C'è margine di manovra, ma zero tolleranza per errori finanziari.
"Cosa vi aspettate da me?" chiede.
"Che tu ci mostri come si fa," risponde Ssh. "Né troppo veloce come Franklin, né troppo lento come Rosalynn. Giusto."
"'Giusto' è soggettivo," dice Eleanor.
"Appunto," sorride Bash. "Per questo serve qualcuno con giudizio."
Atto I: Fare i compiti a casa
Una settimana prima del kick-off ufficiale - Casa di Eleanor, sera
Eleanor ha sempre fatto così: quando arriva una sfida nuova, studia. Non si butta. Studia.
Sul tavolo: tre pile di documenti.
Pila 1 - Success cases:
- Paper Anthropic: "Building trusted AI in the enterprise"
- Caso Novo Nordisk: 12 settimane → 10 minuti per Clinical Study Reports
- Nota personale di Eleanor: "Ma DOPO aver formalizzato processo. Quanto ci hanno messo a formalizzare?"
- Caso DoorDash: voice AI contact center in 2 mesi
- Nota: "Infrastruttura già matura. Non partivano da zero."
- Caso Thomson Reuters: fine-tuning diventa cheaper dei modelli tradizionali
- Nota: "Ma solo dopo extensive prompt engineering. Quanto costa quello?"
Pila 2 - Failure cases:
- Report CISQ: $2.08 trilioni di costi per scarsa qualità software (2020)
- Caso Provident Financial: £17.42 → £4.50 per un bug
- Caso interno (Franklin Nmap): €450K danni
- Studio BCG: 62% C-suite cita "skills shortage" come ostacolo
Pila 3 - Framework e standard:
- ISO31000 per risk management
- Framework Anthropic in 4 fasi (Strategy → Value → Production → Deploy)
- Graduation criteria per evitare "pilot purgatory"
- LLMOps best practices
Eleanor scrive sul suo quaderno:
Pattern comuni nei successi:
1. Hanno formalizzato PRIMA di automatizzare
2. Hanno fatto pilot selettivi, non big bang
3. Hanno metriche chiare PRIMA di scalare
4. Hanno governance proporzionale al rischio
Pattern comuni nei fallimenti:
1. Confuso velocità con valore (Franklin)
2. Confuso prudenza con paralisi (Rosalynn)
3. Eliminato controlli senza capire perché esistevano
4. Adottato tool senza ripensare processo
Sottolinea due volte: "L'AI amplifica quello che già c'è - buoni processi o caos".
Il giorno dopo - Ufficio di Ssh
"Ho fatto un po' di ricerca," dice Eleanor mostrando i suoi appunti. "Prima di partire, ho bisogno di capire tre cose."
"Dimmi."
"Uno: quali sono i nostri processi adesso? Non quelli che vorremmo avere. Quelli reali."
Ssh sorride. "Onestà. Mi piace. Abbiamo un process doc di 80 pagine che nessuno segue. Nella realtà, ogni team fa un po' a modo suo."
"Due: dove sono i nostri colli di bottiglia? Cosa ci rende davvero lenti?"
"Code review," risponde Ssh senza esitare. "Abbiamo tre senior che revisionano tutto. Sono oberati. A volte un PR resta in pending una settimana."
"Tre: quali sono i nostri veri rischi? Non quelli teorici. Quelli che ci tengono svegli la notte."
Ssh riflette. "Bug in produzione che causano transazioni errate. Non possiamo permettercelo. Anche un errore di un centesimo, moltiplicato per 100.000 transazioni..."
"Diventa €1.000. Capisco." Eleanor annota. "Quindi: processo informale, bottleneck in review, rischio principale = correttezza finanziaria."
"Esatto."
"Bene. Allora non possiamo copiare né Franklin né Rosalynn. Dobbiamo inventare qualcosa di nostro."
Atto II: Mappare prima di muoversi
Workshop con il team - Due settimane dopo
Eleanor ha scelto il team con cura: sei developer (tre senior, tre junior), due QA specialist, un DevOps engineer. Persone con cui ha già lavorato. Si fida di loro.
"Questo workshop," dice Eleanor, "non è per decidere se usare AI. È per decidere dove e come."
Proietta una matrice 2x2:
Alto Beneficio
|
Basso ←─────┼─────→ Alto
Rischio | Rischio
|
Basso Beneficio
"Ogni task che facciamo, lo posizioneremo qui. Poi decideremo."
Warren Wget, uno dei senior, chiede: "Tutto? Ci vorrà una settimana."
"No," risponde Eleanor. "Solo i task che occupano più del 5% del nostro tempo. Ho già fatto l'analisi."
Proietta una lista:
- Scrivere API REST standard
- Scrivere unit test
- Generare documentazione
- Code review
- Scrivere business logic critica (validazioni pagamenti)
- Debugging production issues
- Refactoring codice legacy
- Scrivere migration script database
"Lavoriamo insieme," dice Eleanor. "Per ogni task, discutiamo: quanto rischio? Quanto beneficio?"
Task 1 - API REST standard
Barbara Sed, senior developer: "Beneficio alto. Sono sempre le stesse. Rischio... medio? Se l'AI sbaglia l'autenticazione..."
"Ma," interviene Michelle Find, QA, "le testiamo comunque. Quindi il rischio è rilevabile."
Dopo discussione: Alto beneficio, Medio rischio → Candidato AI con review
Task 2 - Unit test
Harry Tail, junior: "Beneficio medio. I test non sono la parte lenta."
"Vero," dice Eleanor, "ma l'AI trova edge case che noi dimentichiamo. Come il caso Sansan che ho letto - AI ha trovato race condition che umani avevano saltato."
Dopo discussione: Medio beneficio, Basso rischio → Candidato AI con review leggera
Task 5 - Business logic critica
Warren: "Questo no. Troppo rischioso."
Eleanor: "Aspetta. Rischio alto, sì. Ma beneficio? Se l'AI suggerisce implementazione che poi noi revisioniamo pesantemente?"
Barbara: "Io suggerirei: AI come suggerimento, non come implementazione. Noi scriviamo, ma l'AI ci dà idee."
Dopo discussione: Alto beneficio potenziale, Alto rischio → AI suggerisce, umano implementa, doppia review
Finiscono con una mappa chiara:
Quadrante ALTO BENEFICIO / BASSO RISCHIO:
- Documentazione API
- Boilerplate code
- Test generazione (con review)
Quadrante ALTO BENEFICIO / ALTO RISCHIO:
- Business logic critica (AI suggerisce, umano decide)
- Migration script (AI genera, senior valida linea per linea)
Quadrante BASSO BENEFICIO / qualsiasi rischio:
- Non toccare con AI (almeno per ora)
"Questo," dice Eleanor indicando la mappa, "è il nostro piano di battaglia. Non usiamo AI per tutto. La usiamo dove ha senso."
La formalizzazione - Settimana successiva
Eleanor non scrive 47 pagine come Rosalynn. Scrive 5 pagine di principi.
PRINCIPIO 1: Trust but Verify
"L'AI è uno junior developer infinitamente veloce ma che può essere confidently wrong. Trattiamola di conseguenza."
Implicazioni:
- Output AI non va mai in produzione senza review umana
- Livello di review proporzionale al rischio
- Low risk → una persona, light check
- High risk → due persone, heavy check
- Mission-critical → tre persone + testing esteso
PRINCIPIO 2: Risk-Proportional Governance
"Non tutti i task sono uguali. Non tutti meritano lo stesso livello di controllo."
Classificazione:
-
GREEN zone (basso rischio): documentazione, test, boilerplate
- Review: 1 persona, focus su correttezza tecnica
- Timeline: merge in 24h se ok
-
YELLOW zone (medio rischio): API standard, utility functions
- Review: 1 senior, focus su security e edge cases
- Testing: obbligatorio prima di merge
- Timeline: 48h
-
RED zone (alto rischio): business logic, financial calculations, auth
- Review: 2 senior, uno focalizzato su business, uno su security
- Testing: unit + integration + manual verification
- Sign-off: PM o TL prima di merge
- Timeline: quando è pronto, no rush
PRINCIPIO 3: Formalize Before Automate
"Se non riesci a spiegare il processo a un umano, l'AI lo farà a modo suo (probabilmente sbagliato)."
Regola pratica: Prima di chiedere all'AI di generare codice per task complesso:
- Scrivi le requirement in prosa chiara
- Identifica edge cases e corner cases
- Definisci cosa significa "corretto"
- Solo allora: chiedi all'AI
PRINCIPIO 4: Measure What Matters
"Non quante righe genera l'AI, ma: stiamo meglio di prima?"
Metriche:
- Bug in produzione (obiettivo: non aumentare)
- Time to market (obiettivo: ridurre 20-30%)
- Developer satisfaction (survey mensile)
- Code review backlog (obiettivo: ridurre 50%)
- Customer incidents (obiettivo: zero aumento)
PRINCIPIO 5: Iterate Continuously
"Questo non è un piano fisso. È un esperimento continuo."
Processo:
- Ogni mese: retrospettiva su uso AI
- Cosa funziona? Scala.
- Cosa non funziona? Ferma o aggiusta.
- Nuovi use case? Valuta con matrice rischio/beneficio.
- Feedback team? Integra.
"Cinque principi," dice Eleanor presentando al team. "Non cinquanta regole. Perché voglio che usiate il cervello, non che compiliate checklist."
Atto III: Il pilot selettivo
Sprint 1 - Febbraio 2024
Eleanor non dice "usiamo AI ovunque". Sceglie TRE pilot specifici.
Pilot 1 - Documentation (GREEN zone)
Task: L'AI genera documentazione API da codice esistente.
Setup:
- Harry scrive codice manualmente (come sempre)
- Quando finisce, chiede a Claude: "Generate OpenAPI spec for this endpoint"
- Review: Harry stesso, check veloce (15 min)
- Merge se ok
Risultato dopo 2 settimane:
- Tempo documentazione: da 2h → 20min per endpoint
- Qualità: comparabile a quella manuale
- Bug: zero (la documentazione descrive, non esegue)
- Developer feedback: "Fantastico, odiavo fare docs"
Decisione di Eleanor: SCALE UP - diventa procedura standard
Pilot 2 - Test Generation (YELLOW zone)
Task: AI genera unit test per funzioni esistenti.
Setup:
- Warren Wget scrive funzione di validazione IBAN
- Chiede a Claude: "Generate comprehensive unit tests including edge cases"
- Claude genera 25 test
- Warren review: trova che AI ha pensato a edge case che lui aveva dimenticato
- IBAN con spazi
- IBAN con caratteri minuscoli
- IBAN con checksum invalido
- IBAN di paesi non-EU
- Aggiunge i test, mergea
Risultato dopo 2 settimane:
- Copertura test: da 78% → 89%
- Edge case trovati: +40%
- Bug rilevati in fase test: +3 (che sarebbero finiti in produzione)
- Tempo scrittura test: invariato (generazione veloce, ma review accurata richiede tempo)
Decisione di Eleanor: ADOPT - ma con review obbligatoria senior
Pilot 3 - Critical Business Logic (RED zone)
Task: Implementare nuovo sistema di fee calculation per transazioni internazionali.
Setup:
- Barbara scrive requirement dettagliata (2 pagine)
- Chiede a Claude suggerimenti implementazione
- Claude propone approccio con lookup table + formula
- Barbara valuta, decide di usare formula ma non lookup table
- Implementa a mano, ispirandosi parzialmente a suggestion AI
- Review: Warren + Eleanor (doppia)
- Testing: Michelle scrive test manuali per 50 scenari
- Sign-off: Eleanor prima del merge
Risultato dopo 1 mese:
- Accelerazione: ~30% (grazie a suggerimenti AI che hanno evitato vicoli ciechi)
- Controllo: totale (umano ha sempre l'ultima parola)
- Bug trovati in test: 2 (trovati da test umani, non AI)
- Developer feedback: "Utile per esplorare approcci, ma decisione finale deve essere mia"
Decisione di Eleanor: CONTINUE CAUTIOUSLY - AI come consulente, non implementatore
Retrospettiva Sprint 1
"Abbiamo fatto tre pilot," dice Eleanor. "Tutti e tre hanno funzionato. Ma per ragioni diverse."
Mostra slide:
Documentation: AI perfetta perché task ripetitivo e basso rischio
Test generation: AI ottima per trovare edge case che umani dimenticano
Business logic: AI utile per suggerire, pericolosa per implementare
"Pattern?" chiede Eleanor.
Warren: "AI è brava su task con pattern chiari e rischio basso."
Barbara: "Ma anche su task complessi è utile, se la teniamo al guinzaglio."
Michelle: "La chiave è capire dove mettere il controllo umano. Non prima (blocchi AI), non dopo (troppo tardi), ma durante."
Eleanor annuisce. "Esatto. E questo cambia per ogni tipo di task."
Atto IV: Il quasi-disastro
Sprint 3 - Marzo 2024
Le cose vanno bene. Troppo bene. Eleanor inizia a preoccuparsi. Quando arriverà il problema?
Arriva un martedì mattina.
Harry ha fatto commit di codice AI-generated senza review adeguata. È codice YELLOW zone (API per recupero storico transazioni), ma Harry l'ha trattato come GREEN.
Il code non passa CI/CD - test falliscono. Ma Harry bypassa dicendo "sono test vecchi, aggiorno".
Il codice arriva in staging.
Michelle, facendo test esplorativi, nota qualcosa di strano: "Le query al database sono... lente. Molto lente."
Chiama Warren. Insieme guardano il codice.
"Madonna," dice Warren. "Harry, questo fa una query per ogni transazione. Se un cliente ha 10.000 transazioni, sono 10.000 query."
"Ma l'AI ha detto—" inizia Harry.
"L'AI non sa del nostro schema database," l'interrompe Warren. "Ha generato codice che tecnicamente funziona ma praticamente è inutilizzabile."
Eleanor viene chiamata. Guarda il codice. Poi guarda Harry.
"Questo è YELLOW zone. Richiedeva review senior. L'hai fatta?"
Harry arrossisce. "Ho pensato... fosse semplice..."
"Nulla che l'AI genera è 'semplice' finché un senior non lo verifica," dice Eleanor. Non urlando, ma ferma. "Abbiamo processi per un motivo."
Fortuna: il bug è stato rilevato in staging, non in produzione. Ma è stato close.
Post-mortem - Due giorni dopo
Eleanor convoca il team. Non per punire, ma per imparare.
"Cosa è andato storto?"
Harry: "Ho sottovalutato il rischio. Mi sono fidato troppo dell'AI."
"Altro?" chiede Eleanor.
Barbara: "I nostri colori (GREEN/YELLOW/RED) forse non sono chiari. Harry ha pensato fosse GREEN quando era YELLOW."
"Giusto," dice Eleanor. "Dobbiamo essere più espliciti."
Risultato del post-mortem:
AGGIORNAMENTO PROCESSO
1. Classificazione task visibile:
- Ogni ticket in Jira ha tag: AI-GREEN, AI-YELLOW, o AI-RED
- Assegnato da PM/TL, non dal developer
2. Review obbligatoria non bypassabile:
- CI/CD blocca merge se:
- Tag = YELLOW e reviewer ≠ senior
- Tag = RED e reviewer < 2
3. AI usage log:
- Ogni commit che usa AI-generated code ha campo:
- "AI prompt used"
- "AI output modified? (Y/N)"
- "Review level applied"
"Questo," dice Eleanor, "non è burocrazia. È memoria. Se tra sei mesi abbiamo un bug, voglio poter ricostruire: era AI-generated? Come l'abbiamo revisionato? Cosa è sfuggito?"
Atto V: Scalare l'equilibrio
6 mesi dopo - Agosto 2024
Eleanor presenta risultati al board.
Slide 1 - Metriche tecniche:
- Velocity: +25% (da 40 → 50 story points per sprint)
- Bug in produzione: -15% (da 8 → 7 per trimestre, poi 6)
- Code review backlog: -60% (da 2 settimane → 3 giorni)
- Test coverage: da 78% → 91%
- Time to market nuove feature: -30%
Slide 2 - Metriche umane:
- Developer satisfaction: 8.2/10 (era 7.1)
- Quote principali:
- "Non mi sento sostituito, mi sento amplificato"
- "Finalmente tempo per pensare architettura invece di scrivere boilerplate"
- "Review è più facile perché arriva codice già pulito"
Slide 3 - Costi:
- Licenze AI: €12K/anno
- Training team: €8K one-time
- Tempo setup processi: ~100 ore PM
- ROI: positivo già al mese 4
Woodrow Bash, il CEO, chiede: "Perché non siamo veloci come i competitor che dicono 'AI al 100%'?"
Eleanor risponde calma: "Perché voglio ancora avere clienti tra un anno. Loro stanno accumulando technical debt invisibile. Stanno facendo come Franklin Nmap - veloce ora, esplosione dopo. Noi stiamo costruendo fondamenta."
"Ma se non esplodono?" insiste Bash.
"Allora," ammette Eleanor, "avrò sbagliato a essere prudente. Ma preferisco questo rischio a quello opposto."
Ssh, il CTO, interviene: "Woodrow, guarda i numeri. Non solo velocity. Guarda bug in produzione: giù. Guarda satisfaction: su. Eleanor non ha scelto velocità o sicurezza. Ha scelto entrambe, in proporzione sensata."
Bash riflette. Poi: "Ok. Continua così. Ma se i competitor ci schiacciano, torneremo a parlarne."
Corridoio - Dopo il meeting
Ssh ferma Eleanor. "Brava presentazione."
"Grazie. Ma ho sentito la tensione. Bash vorrebbe di più."
"Bash vorrebbe tutto," ride Ssh. "È il suo lavoro. Il nostro è trovare l'equilibrio sostenibile."
"A volte," confessa Eleanor, "mi chiedo se non sono troppo cauta. Vedo James Ping, vedo altri team che vanno full AI..."
"Eleanor," dice Ssh serio, "hai mai sentito di Franklin Nmap?"
"Quello dei €450K? Sì."
"Ecco. E di Rosalynn Cat?"
"La 47-pagine-di-framework. Sì."
"Tu," dice Ssh, "non sei né Franklin né Rosalynn. E questo è esattamente perché funzioni. Ma devi accettare una cosa."
"Cosa?"
"Che l'equilibrio è scomodo. Franklin dormiva sonni tranquilli perché era convinto di aver ragione. Rosalynn pure. Tu dormi male perché sai che potresti sbagliare in entrambe le direzioni."
Eleanor sorride amaro. "Grazie. Mi hai consolato un sacco."
"Non volevo consolarti. Volevo dirti: quella sensazione di scomodità? È il segnale che stai facendo bene. Il giorno che ti sentirai sicura al 100%, preoccupati."
Atto VI: La tentazione
8 mesi dopo - Ottobre 2024
Arriva la notizia: un competitor diretto ha avuto major outage. Bug generato da AI, non rilevato. Sistema di pagamenti down per 6 ore. Danni: stimati in €2M+ tra transazioni perse e compensazioni clienti.
Eleanor legge il post-mortem (reso pubblico per trasparenza). Suona familiare:
"AI-generated code committed without adequate review. Assumption that passing tests meant production-ready. Race condition in payment processing queue under high load."
Praticamente identico al caso Franklin Nmap.
Il manager di quel progetto? Licenziato.
Email da Rosalynn Cat
Oggetto: "Visto?"
Corpo: "Eleanor, hai visto cosa è successo a FinPay? Te l'avevo detto che l'AI è troppo rischiosa. Forse dovresti rallentare anche tu. Meglio lenti che distrutti."
Eleanor guarda l'email. Parte di lei è tentata: Ha ragione. Dovrei essere più prudente.
Ma poi rilegge il post-mortem. Il problema non era l'AI. Era:
- Review inadeguata
- Test insufficienti per scenari real-world
- Pressione a rilasciare veloce
- Mancanza di monitoring
Tutte cose che Eleanor ha nel suo processo.
Risponde a Rosalynn:
"Cara Rosalynn, grazie per la segnalazione. Stiamo revisionando i nostri processi alla luce di questo caso. Credo che la chiave sia governance proporzionale, non assenza o eccesso. Ma capisco le tue preoccupazioni."
Team meeting - Retrospettiva post-incidente-competitor
"Ho visto che avete tutti letto del FinPay," dice Eleanor. "Qualcuno è preoccupato?"
Silenzio.
Poi Warren: "Un po'. Voglio dire, anche noi usiamo AI per codice critico."
"Vero," dice Eleanor. "Ma come?"
Barbara: "Con doppia review. Con test estesi. Con sign-off."
Michelle: "E con monitoring in produzione. Se qualcosa va storto, lo vediamo in minuti, non ore."
"Esatto," dice Eleanor. "Il problema di FinPay non era l'AI. Era la governance. O meglio, la mancanza."
"Ma," dice Harry, "potremmo aggiungere ulteriori controlli? Per sicurezza?"
Eleanor lo guarda. "Harry, ricordi il nostro principio 2?"
"Risk-proportional governance."
"Esatto. Più controlli non sempre significa più sicurezza. A volte significa solo più lentezza senza beneficio. La domanda è: i controlli che abbiamo coprono i rischi reali?"
Discussione. Alla fine, decidono:
UN aggiustamento:
- Per codice RED zone che tocca sistemi finanziari: aggiungere simulation test con dati produzione-like (anonimizzati) prima di staging
ZERO cambi al resto.
"Questo," dice Eleanor, "è iterazione intelligente. Non panico. Non burocrazia. Aggiustamento mirato."
Atto VII: L'equilibrio instabile
12 mesi dopo - Febbraio 2025
Un anno dall'inizio. Eleanor fa bilancio.
Successi:
- 14 feature majors rilasciate (prima erano 8-9)
- Zero incidenti critici in produzione
- Team satisfaction stabile (8.1/10)
- Bug down, velocity up, morale ok
Sfide continue:
- Developer junior vogliono "più AI, meno lentezza"
- CFO vuole "più velocità, meno costi"
- Compliance (per regolamentazione fintech) vuole "più controlli, meno rischi"
- Competitor continuano ad accelerare
Ogni giorno è una negoziazione.
Scena: Junior developer meeting
Harry e altri due junior chiedono incontro.
"Eleanor, possiamo parlare del processo AI?"
"Certo."
"È troppo... lento. Voglio dire, capisco i controlli per codice critico. Ma anche per task semplici dobbiamo seguire tutto il processo."
Eleanor: "Esempio?"
"Settimana scorsa, ho generato un helper function per parsing date. GREEN zone. Ho dovuto comunque fare PR, aspettare review, tutto. Per 15 righe di codice."
Eleanor riflette. "Hai ragione. GREEN zone dovrebbe essere più veloce. Proposta?"
"Self-merge per GREEN zone se test passano?"
"No," dice Eleanor. "Ma: se è GREEN e test passano, review può essere async. Fai merge, senior rivede dopo. Se trova problema, revert. Va bene?"
I junior si guardano. "Sì, ci sta."
"Fatto. Da prossimo sprint."
Scena: CFO pressure
Email da CFO: "Eleanor, ottimi risultati. Ma competitor X rilascia ogni 3 settimane, voi ogni 6. Possiamo accelerare?"
Eleanor risponde:
"Possiamo. Ma ci sono due modi:
- Ridurre controlli → rilasciamo più veloce ma con più bug
- Aumentare team → rilasciamo più feature con stessa qualità
Preferenza?"
CFO: "Opzione 2 costa."
Eleanor: "Opzione 1 costa di più quando il bug arriva. FinPay ha perso €2M in un giorno."
CFO: "Point taken. Per ora continuate così. Ma tieni d'occhio competitor."
Scena: Compliance review
Auditor esterno per certificazione PCI-DSS (necessaria per pagamenti).
"Ms. Rsync, vedo che usate AI-generated code. Come garantite conformità?"
Eleanor mostra il processo:
- Classificazione rischio
- Review proporzionale
- Test requirements
- Audit trail completo
- Monitoring in produzione
Auditor: "Molto meglio di altri che ho visto. Approvato."
Dopo che esce, Eleanor tira un sospiro di sollievo. Uno scoglio passato.
Epilogo: L'equilibrio è dinamico
18 mesi dopo - Agosto 2025
Eleanor riceve email da Bash: "All-hands meeting, Friday. Good news to share."
Nel meeting, Bash annuncia: "Abbiamo chiuso il Q2 con risultati record. Revenue +40%, customer satisfaction all-time high, zero incidenti critici da 18 mesi."
Applausi.
"Voglio ringraziare particolarmente," continua Bash, "il team di Eleanor Rsync. Il loro approccio all'AI - bilanciato, pragmatico, sostenibile - è diventato il modello per tutta l'azienda."
Dopo il meeting, vari PM si avvicinano a Eleanor.
"Come hai fatto?" chiede uno. "Io ho provato AI e è stato un disastro."
Eleanor: "Hai fatto come Franklin? Troppo veloce?"
"Forse."
"Il trucco," dice Eleanor, "non è andare veloce. È andare alla velocità giusta."
"E come si trova?"
"Sperimentando. Misurando. Aggiustando. Ogni settimana. Non c'è formula magica."
Ufficio di Eleanor - Sera tardi
Eleanor rilegge i principi che ha scritto 18 mesi fa. Cinque pagine.
Ora sono diventate otto. Ha aggiunto:
PRINCIPIO 6: Accept Discomfort
"L'equilibrio non è comodo. Se ti senti sicuro al 100%, probabilmente hai sbagliato in una direzione."
PRINCIPIO 7: Iterate or Die
"Quello che funziona oggi potrebbe non funzionare domani. I competitor imparano. La tecnologia migliora. I rischi cambiano. Il processo deve cambiare con loro."
PRINCIPIO 8: Culture Over Process
"Le regole non sostituiscono il giudizio. Se il team deve seguire checklist senza capire, hai già perso."
Il telefono squilla. È Ssh.
"Eleanor, ho una proposta. Vogliamo che tu guidi il rollout AI a tutta l'engineering organization. 12 team, 100+ developer. Interessata?"
Eleanor esita. Scalare è difficile. Quello che funziona con 8 persone può crollare con 100.
"Calvin, ho paura di diventare Rosalynn Cat. Di costruire burocrazia che non scala."
"Per questo voglio te," ride Ssh. "Perché hai paura. Franklin non aveva paura. Rosalynn era paralizzata dalla paura. Tu hai paura sana. Quella che ti fa procedere con cautela ma senza fermarti."
Eleanor riflette. "Ok. Ma a una condizione."
"Dimmi."
"Ogni team adatta i principi al suo contesto. Non impongo le mie otto pagine. Impongo i principi, non il processo."
"Deal."
Riflessione finale
La storia di Eleanor Rsync non ha lieto fine. Almeno, non un lieto fine hollywoodiano con risoluzione chiara.
Ha un work-in-progress ending.
Eleanor non ha risolto il problema dell'AI. Ha imparato a conviverci. Che è diverso.
Franklin Nmap aveva fallito credendo che l'AI fosse la soluzione. Rosalynn Cat aveva fallito credendo che l'AI fosse il problema.
Eleanor ha capito che l'AI non è né soluzione né problema. È un amplificatore.
Se i tuoi processi sono buoni, li amplifica. Se sono caotici, amplifica il caos.
Se il tuo team è competente, li amplifica. Se sono insicuri, amplifica l'insicurezza.
Se la tua governance è intelligente, funziona. Se è burocrazia, rallenta.
Il framework di Eleanor (ora otto pagine) non è "migliore" di quello di Rosalynn (47 pagine) perché è più corto. È migliore perché è adattivo.
I cinque - ora otto - principi non sono regole rigide. Sono lenti attraverso cui guardare ogni decisione:
- Questo task richiede alta fiducia o alta verifica?
- Questo rischio giustifica questo controllo?
- Questo processo nasce da strategia o da paura?
- Queste metriche misurano valore o solo output?
- Questo funziona oggi? Funzionerà domani?
La differenza tra Eleanor e i suoi predecessori è che lei sa di non sapere.
Franklin sapeva che l'AI avrebbe risolto tutto. Sbagliato.
Rosalynn sapeva che l'AI era troppo rischiosa. Sbagliato.
Eleanor non sa se sta facendo bene. Ma lo verifica continuamente.
Questo è scomodo. Ssh aveva ragione: l'equilibrio è scomodo. Dormi male perché ogni giorno potrebbe essere quello in cui hai sbagliato la calibrazione.
Ma è l'unico approccio sostenibile.
I dati che Eleanor aveva studiato all'inizio - Novo Nordisk (12 settimane → 10 minuti), BCG (62% skills shortage), CISQ ($2.08T), il disastro di Franklin (€450K) - non erano ricette. Erano warning.
Dicevano: l'AI è potente. Usala male e ti distrugge. Usala con paura e non la usi. Usala con giudizio e... forse funziona.
"Forse" è la parola chiave.
Eleanor tra 18 mesi potrebbe aver fallito. I competitor potrebbero averla schiacciata. Il board potrebbe averla sostituita con qualcuno più aggressivo.
Oppure potrebbe aver costruito qualcosa di sostenibile. Un modello che regge non per un trimestre ma per anni.
Non lo sa. Nessuno lo sa.
Ma questo è il punto: nel mondo dell'AI, chiunque ti dica di avere certezze sta mentendo. A te o a sé stesso.
L'unica certezza è l'incertezza.
E l'unica risposta ragionevole all'incertezza non è paralisi (Rosalynn) né cieca fiducia (Franklin).
È iterazione continua, misurazione onesta, e disponibilità a dire: "Ho sbagliato, aggiusto."
Eleanor ancora non lo dice ad alta voce, ma lo pensa ogni giorno.
E questo, forse, è il suo vero superpotere.
Non la perfezione. L'umiltà.
Non la certezza. Il dubbio produttivo.
Non il framework perfetto. Il framework adattabile.
La storia continua. Domani ci sarà un nuovo competitor, una nuova tecnologia, un nuovo rischio.
Eleanor non sa come reagirà.
Ma sa che reagirà. Osserverà. Misurerà. Aggiusterà.
E andrà avanti.
Alla velocità giusta.
Qualunque essa sia.