Enrico Papalini ha passato oltre vent’anni a scrivere e orchestrare sistemi software in contesti dove non ti puoi permettere di pushare codice che “probabilmente funziona”. Come Head of Engineering Excellence and Innovation in Borsa Italiana, parte del gruppo Euronext, lavora su infrastrutture dove un bug non significa solo un ticket su Jira, ma potenzialmente milioni di euro in transazioni bloccate. Prima ancora: Microsoft, Intesa Sanpaolo, startup e grandi corporate. Il suo profilo LinkedIn racconta il percorso di qualcuno che ha dovuto bilanciare innovazione e affidabilità in ogni fase della carriera.
Non è il tipo che teorizza dall’esterno. È uno che ha dovuto rispondere a domande come: “Possiamo deployare questo in produzione?” quando “questo” coinvolge intelligenza artificiale generativa e il sistema gestisce infrastruttura critica.
Ora ha scritto un libro che sintetizza questa esperienza: Intelligenza Artificiale e Ingegneria del Software: Cosa debbono fare le imprese, disponibile anche in inglese come Non-Deterministic Software Engineering. Il libro si basa su ricerche di DX su oltre 180 aziende, integra le metriche DORA adattate allo sviluppo con IA, e analizza case study di chi ci è già passato: OpenAI, Shopify, Google. Per scriverlo ha dialogato con Martin Fowler, Kent Beck e Addy Osmani.
Il patto silenzioso infranto
Mentre continuano a uscire tutorial su “10x your coding with AI”, Papalini ha scelto di affrontare il problema da un’altra angolazione. Gli chiedo cosa l’ha spinto a scrivere proprio questo libro, proprio ora.
“Tutti parlano di velocità, ma la vera rivoluzione è un’altra,” risponde. “È un cambio di natura degli strumenti che usiamo. Per quarant’anni abbiamo dato per scontata una cosa: scrivi del codice, quello fa esattamente ciò che hai scritto. Sempre. È su questa certezza che abbiamo costruito tutto, come testiamo, come facciamo debug, come lavoriamo in team. L’IA generativa rompe questo patto silenzioso. Non perché sia difettosa, ha una natura probabilistica. Le chiedi la stessa cosa due volte, ti dà risposte diverse. A volte geniali, a volte sbagliate con una sicurezza disarmante.”
La metafora che usa colpisce: “Le aziende che pensano di sostituire i programmatori con l’AI e guardano compiaciute a quante righe di codice in più riescono a produrre e si perdono il punto: stanno introducendo una variabile aleatoria nel cuore dei loro sistemi. È un po’ come se un ingegnere civile costruisse un ponte con materiali che potrebbero reggere il peso previsto. Funziona benissimo quando ci passano poche auto, ma quando ci passa il primo camion crolla.”
Ha scritto il libro, dice, “perché mi sembrava che mancasse una guida per chi deve navigare questo cambio senza schiantarsi, ma anche senza rinunciare ai benefici, che sono reali.”
Dal determinismo alla tolleranza
Il cuore concettuale del libro è nel titolo inglese: Non-Deterministic Software Engineering. È un ossimoro deliberato. L’ingegneria del software è sempre stata l’arte di costruire sistemi deterministici: input A produce sempre output B. Papalini sta proponendo di accogliere nei nostri workflow strumenti che, per loro natura, non rispettano questa regola.
Gli chiedo come cambia il paradigma del controllo qualità quando passiamo da un mondo dove il codice faceva esattamente ciò che era scritto, a un mondo dove accogliamo sistemi probabilistici nei nostri IDE.
“Cambia tutto, e allo stesso tempo niente. Lo so, sembra un paradosso,” esordisce. “Cambia tutto perché ‘funziona’ non significa più ‘è corretto’. Il codice generato dall’IA compila, passa i test che hai scritto, ha un aspetto professionale. Ma potrebbe nascondere vulnerabilità, gestire male i casi limite, o essere scritto in un modo che tra sei mesi nessuno capirà. Non cambia niente perché i fondamentali dell’ingegneria del software restano gli stessi: test, review, pensiero progettuale. Anzi, diventano più importanti di prima.”
La chiave, secondo Papalini, sta nell’adottare un approccio che finora è stato estraneo agli sviluppatori: “La vera novità è che dobbiamo imparare a ragionare per ‘tolleranze’. Martin Fowler usa spesso questa analogia: sua moglie è ingegnere strutturale, e non progetta mai al limite esatto. Calcola sempre un margine di sicurezza. Noi sviluppatori non abbiamo mai dovuto farlo perché i nostri ‘materiali’ erano perfettamente prevedibili. Ora non lo sono più. E chi non si costruisce questi margini, prima o poi vedrà crollare il ‘ponte’.”
L’illusione della velocità
Uno dei passaggi più spiazzanti del libro riguarda i dati sulla produttività. Papalini cita uno studio del METR che mostra come gli sviluppatori possano sentirsi il 20% più veloci con l’intelligenza artificiale, mentre i test reali su compiti misurabili indicano che in alcuni casi sono più lenti del 19%.
Gli chiedo come sia possibile questa discrepanza, e soprattutto come possiamo misurare davvero se stiamo lavorando meglio o solo sentendoci più produttivi.
“Sai cosa mi ha colpito di più di quello studio? Non è il dato che con l’IA fossero più lenti del 19%. È che gli sviluppatori credevano di essere più veloci. E continuavano a crederlo anche dopo aver visto i risultati,” racconta Papalini. “Perché succede? Perché l’IA riduce la fatica percepita. Ti senti più fluido, meno bloccato. È come avere un collega sempre disponibile a darti una mano che non ti giudica e non ti fa aspettare. Psicologicamente è potente. Ma ‘mi sento produttivo’ e ‘sto producendo valore’ sono due cose molto diverse.”
La soluzione che propone riguarda anche il livello individuale: “Per non cadere nel hype, un’azienda dovrebbe stabilite una baseline prima di adottare gli strumenti. Senza un ‘prima’, non potrete mai dimostrare un ‘dopo’. Quando il CEO chiederà cosa ha portato l’IA, servono numeri, non sensazioni. Ma i numeri debbono essere quelli giusti: smettetela di misurare linee di codice o quante suggestion dell’IA vengono accettate. Misurate quello che conta: funzionalità rilasciate, bug in produzione, tempo per risolvere gli incidenti. E una cosa fondamentale: misurare quanto motivati rimangono gli sviluppatori.”
La trappola del funziona
Andrej Karpathy ha reso popolare il termine “vibe coding”: programmare seguendo l’intuizione del momento, lasciando che l’IA suggerisca direzioni che “sembrano giuste”. È affascinante e profondamente pericoloso.
Papalini dedica diverse pagine a quello che chiama “It Works Trap”, la trappola del “funziona”. Gli chiedo quali sono i rischi a lungo termine di una codebase scritta principalmente seguendo il vibe, senza validazione rigorosa.
“Ti racconto una storia,” inizia. “Martin Fowler aveva usato l’IA per generare una visualizzazione in formato vettoriale SVG, niente di complesso. Funzionava perfettamente. Poi ha voluto fare una modifica banale: spostare un’etichetta di qualche pixel. Ha aperto il file e ha trovato quello che ha definito ‘roba da pazzi’, codice che funzionava, sì, ma strutturato in modo completamente alieno, impossibile da toccare senza rompere tutto. L’unica opzione? Buttare via e rigenerare da zero.”
L’aneddoto cattura perfettamente il problema: “Questo è il costo reale ed il rischio del vibe coding su scala aziendale. Crei sistemi che funzionano ma che nessuno capisce. E il software aziendale deve vivere anni, a volte decenni. Deve essere modificato, esteso, debuggato alle tre di notte quando qualcosa esplode.”
La soluzione che propone è semplice nella formulazione ma richiede disciplina: “La regola che dobbiamo seguire è semplice: non committare mai codice che non si sa spiegare a un collega. Se è generato con l’IA e non capisco come funziona, non è pronto per la produzione.”
Il prezzo dell’inaffidabilità
Nel libro Papalini introduce il concetto di “unreliability tax”, la tassa sull’inaffidabilità. Gli chiedo di quantificare, dal punto di vista di chi scrive e fa review di codice ogni giorno, quanto costa realmente il codice generato dall’IA che sembra corretto ma nasconde vulnerabilità.
“I numeri fanno riflettere,” esordisce. “Le ricerche mostrano che una percentuale significativa del codice generato dall’IA contiene vulnerabilità, alcune fonti parlano di quasi la metà. E la cosa subdola è che sono vulnerabilità ‘plausibili’: il codice sembra professionale, usa pattern riconoscibili. Solo che manca la validazione dell’input in quel punto critico, o usa una funzione crittografica deprecata.”
Non si tratta di errori evidenti: “Il costo diretto è il tempo di remediation. Ma il costo vero è quello che non vedi subito: la vulnerabilità che passa inosservata per mesi, finché qualcuno la trova. A quel punto non stai pagando ore di sviluppo, stai pagando incident response, potenziale data breach, danni alla reputazione.”
Papalini identifica anche un costo più personale: “C’è anche una tassa più sottile: la perdita di fiducia nel sistema. Quando il team inizia a non fidarsi del proprio codice, rallenta tutto. Ogni modifica diventa un rischio. E lo stesso vale per i clienti: c’è il rischio che passino ad un compito più affidabile.”
La sua raccomandazione è pratica: “L’investimento sensato è in prevenzione: security scanning automatico, formazione mirata, review umano obbligatorio per tutto ciò che tocca autenticazione o dati sensibili. Costa meno che pulire i disastri dopo e perdere clientela.”
La gavetta nell’era delle macchine
Una delle sezioni più provocatorie del libro riguarda il futuro della formazione. C’è una distinzione emergente tra i programmatori tradizionali e la nuova figura dell’AI Engineer, qualcuno che sa orchestrare sistemi intelligenti ma potrebbe non aver mai implementato un algoritmo di sorting da zero.
Gli chiedo se il programmatore “puro” è destinato a scomparire o se l’IA sta semplicemente alzando l’asticella delle competenze necessarie.
“Il programmatore non è destinato a scomparire, ma il suo ruolo sta cambiando parecchio,” risponde. “Pensa a cosa è successo quando sono arrivati i linguaggi ad alto livello. I programmatori assembly non sono spariti, sono diventati specialisti di nicchia. Il grosso del lavoro si è spostato un gradino più su.”
La transizione attuale segue un pattern simile: “Sta succedendo qualcosa di simile adesso. Sta emergendo una figura diversa, chiamiamola ‘orchestratore’: qualcuno che sa scomporre problemi complessi, specificare requisiti con precisione, valutare criticamente quello che l’IA produce, prendere decisioni architetturali.”
Ma qui arriva il paradosso: “Il paradosso? Serve più esperienza, non meno. Un junior può usare l’IA per generare codice che sembra funzionare. Ma solo un senior riconosce quando quel codice è una bomba a orologeria, perché ha visto abbastanza disastri da riconoscerne i segnali.”
Il rischio sistemico che identifica tocca la carriera di ogni developer: “Bisogna fare attenzione poi a non pensare che tutti nascano orchestratori: se deleghiamo tutto il lavoro ‘di gavetta’ all’IA, come formiamo la prossima generazione di senior? I dati ci dicono che l’occupazione degli sviluppatori più giovani sta già calando. Ma anche chi entra nel mercato rischia di non sviluppare mai quelle competenze profonde che si costruiscono solo sbattendo la testa sui problemi.”
Il trio programming
Per risolvere questo dilemma, Papalini propone nel libro un modello che chiama “trio programming”, un’evoluzione del pair programming che include l’IA come terzo attore. È una soluzione pratica per chi lavora quotidianamente con questi strumenti.
“Nel libro propongo il ‘trio programming’ come soluzione al problema della formazione,” spiega. “Il junior lavora con l’IA per implementare le feature. L’IA accelera, suggerisce, genera codice. Fin qui niente di nuovo. Il senior orchestratore non scrive codice, è lì per fare domande. ‘Spiegami cosa fa questo metodo.’ ‘Perché l’IA ha scelto questa struttura dati?’ ‘Cosa succede se l’input è nullo?’ ‘Come gestiresti un errore di rete qui?'”
Il meccanismo è pedagogicamente brillante: “Rispondendo a questi quesiti, il giovane impara. Il senior, dal canto suo, trasferisce quel sapere tacito che non sta in nessun manuale, l’intuizione su cosa può andare storto, la sensibilità per il codice che ‘puzza’, l’esperienza di chi ha visto sistemi crollare.”
È un modello applicabile anche per chi lavora da solo: sostituisci il “senior” con una checklist mentale di domande da farti prima di ogni commit. L’IA ti ha generato quella funzione? Perfetto. Ora spiegala a te stesso. Se non riesci, non è pronta.
Orchestratori, non digitatori
La conversazione ritorna al tema del cambiamento professionale. Se l’IA diventa sempre più brava a scrivere codice, qual è il valore distintivo dell’ingegnere umano? Cosa dobbiamo imparare, cosa dobbiamo preservare?
“Il ruolo dell’ingegnere si sposta verso la specifica e la validazione, meno verso l’implementazione,” sintetizza Papalini. “Ma questo cambiamento richiederà più competenza da parte dei lavoratori, non meno.”
È un punto cruciale che contraddice la narrativa popolare dell’IA come democratizzazione della programmazione. Non stiamo abbassando le barriere all’ingresso, le stiamo spostando. Prima dovevi sapere scrivere codice sintatticamente corretto. Ora devi sapere riconoscere quando il codice sintatticamente corretto è semanticamente pericoloso.
Le competenze che contano stanno cambiando: meno sintassi, più architettura. Meno implementazione, più design. Meno “come si scrive un loop”, più “perché questo approccio è problematico a scala”. È come passare da muratore a ingegnere strutturale: il martello conta meno, la fisica conta di più.
L’atrofia delle competenze
C’è un tema che attraversa l’intero libro: il rischio che l’adozione massiccia dell’IA non amplifichi le nostre capacità ma le atrofizzi. È la domanda che ogni developer dovrebbe farsi.
Gli chiedo direttamente: come possiamo garantire che l’uso quotidiano dell’IA non svilisca la nostra professionalità ma diventi un reale amplificatore delle nostre capacità?
“È la domanda che mi sta più a cuore,” risponde Papalini. “Il rischio concreto lo chiamo ‘atrofia delle competenze’. Un ingegnere intervistato dal MIT Technology Review ha raccontato che dopo mesi di uso intensivo dell’IA, quando ha provato a programmare senza, si sentiva perso, cose che prima erano istinto erano diventate faticose. È esattamente il campanello d’allarme che dovremmo ascoltare.”
La soluzione non è il rifiuto ma l’intenzionalità: “La soluzione non è rifiutare l’IA, sarebbe come rifiutare l’elettricità. Ma dobbiamo essere intenzionali su come la integriamo, specialmente nei percorsi di formazione. È per questo che nel libro propongo modelli come il ‘trio programming’ per coltivare la capacità dei talenti e non commettere l’errore di segare il gradino più basso della scala dalla quale siamo saliti, il processo di apprendimento che ci ha portato dove siamo.”
È una sfida personale per ogni sviluppatore: come usi l’IA dice molto su che tipo di professionista diventerai. Puoi usarla come una stampella che ti permette di evitare di capire cosa stai facendo, o come un amplificatore che ti libera dalle parti noiose per concentrarti su quelle che richiedono giudizio. La prima strada porta all’obsolescenza. La seconda alla crescita.
Il mestiere che cambia
Al termine di questa conversazione, quello che emerge con chiarezza è che stiamo vivendo uno di quei momenti di transizione che ridefiniscono una professione. Il libro Intelligenza Artificiale e Ingegneria del Software non è un manuale su come usare Copilot più velocemente. È più simile a quei testi che escono dopo una rivoluzione tecnologica, quando qualcuno che l’ha vissuta in prima linea cerca di mappare cosa è cambiato davvero e cosa solo in apparenza.
La vera questione non è se useremo l’IA per scrivere codice. La stiamo già usando. La questione è se riusciremo a farlo senza perdere per strada le competenze profonde che ci hanno permesso di diventare sviluppatori capaci. Quelle competenze che si costruiscono solo debuggando per ore un segfault, solo leggendo codice orribile scritto da altri, solo sbagliando in modi creativi e imparando dai disastri.
L’IA può generare codice in secondi. Ma non può generare l’esperienza che ti fa riconoscere quando quel codice nasconde un problema. Non ancora. E forse mai. È quello spazio, tra generazione e giudizio, che definisce il valore di un developer nell’era dell’intelligenza artificiale. La domanda è: stai coltivando quel giudizio, o lo stai delegando?
