Ted accetta. Mentre tira, racconta una storia. Da bambino lo sottovalutavano sempre tutti, perché era piccolo, perché era educato, perché diceva quello che pensava. Un giorno ha letto una frase attribuita a Walt Whitman (“be curious, not judgmental”) e da allora ha deciso di non comportarsi più come chi lo guardava dall’alto. Avrebbe smesso di valutare le persone prima di averle viste. Avrebbe avuto curiosità nei loro confronti, anche nei confronti di chi lo derideva. Detto questo, Ted prende l’ultimo dardo, fa un perfetto centro e vince la partita. Si scopre che ha giocato a freccette con il padre per anni.

Cosa abbiamo fatto a una parola

La parola ingenuo deriva dal latino ingenuus: in- unito a gignere, generare. Il senso letterale è “nato dentro”. Nel diritto romano ingenuus designava chi era nato libero all’interno della società, in contrapposizione al libertinus — il liberto, lo schiavo che si era conquistato l’affrancamento. Era una distinzione giuridica. L’ingenuus portava la libertà come condizione originaria, non come trofeo. Da quella condizione discendevano le qualità morali che i romani gli attribuivano: franchezza, generosità, schiettezza, nobiltà d’animo, autonomia di pensiero. Quelle qualità discendevano dal fatto di non aver mai dovuto difendersi. La sicurezza che dava la libertà originaria diventava un modo di stare al mondo.

C’è una parentela etimologica che la modernità ha quasi dimenticato. La stessa radice in-gignere che genera ingenuus genera anche ingenium: il talento, la disposizione naturale, l’inventiva, ciò che nasce dentro come capacità creativa. Da ingenium il latino medievale ricava ingeniarius, il nostro ingegnere. Ingenuità e ingegneria sono parole sorelle: l’una conserva la libertà di ciò che nasce dentro, l’altra ne dispiega le possibilità.

Una parola svilita

Il percorso si può raccontare per tappe. Nel mondo romano l’ingenuus è il libero per nascita, e la sua franchezza è il segno di una condizione, non un tratto del carattere. Nel cristianesimo medievale l’ingenuità non scompare: si trasforma, si incrocia con l’umiltà, con il “siate semplici come le colombe” del Vangelo, con la purezza di cuore. Il significato resta alto: cambia il segno sociale, da aristocratico a evangelico.

Le cose cominciano a cambiare tra il Rinascimento e l’Illuminismo. L’ingenuo, in un mondo in cui ogni gesto è una mossa, comincia a sembrare fuori posto. È in questo passaggio che Machiavelli, nel Principe del 1513, codifica il calcolo come razionalità politica: il principe che voglia durare deve essere volpe e leone, conoscere i lacci ed esibire la forza, non parlare franco. Da quel momento, il pensiero politico europeo legge la franchezza come imprudenza tecnica. Il Romanticismo aggiunge un altro strato: l’ingenuo è il puro, il fresco, il non sovrastrutturato, l’infanzia non rovinata dal mondo. Salvo che, di nuovo, “non rovinato dal mondo” finisce per dire “non in grado di affrontare il mondo”.

Il Novecento porta a compimento la caduta. Le organizzazioni complesse, i mercati, la politica di massa, la comunicazione professionale, tutto insegna che chi parla franco si espone, chi si fida senza riserve viene fregato, chi propone senza calcolo perde la presa. Il vocabolario manageriale del secondo Novecento non usa quasi mai la parola ingenuità in senso positivo. Si parla di competenza, di postura strategica, di intelligenza emotiva intesa come capacità di leggere e di gestire. L’ingenuo, in questo vocabolario, è chi si mette fuori dal gioco.

Una società che chiama ingenuo chi non finge afferma che fingere è la norma. Una società che considera vulnerabile chi parla franco sta dicendo che la franchezza ha bisogno di protezioni che il sistema non offre. Tutti sosteniamo che vorremmo più franchezza (nelle aziende, in politica, nei rapporti privati) e tutti, nelle posizioni di responsabilità, premiamo chi calcola meglio. È il piccolo paradosso quotidiano che fa la differenza tra come parliamo del mondo e come lo viviamo.

La finta franchezza

Una parte considerevole di ciò che si presenta come “franchezza” nel discorso pubblico contemporaneo è in realtà il suo opposto: una provocazione calcolata, costruita per generare contrapposizione e attirare l’audience. Il talk show urlato, il commentatore che sceglie la frase più estrema per restare in scaletta, l’influencer che alza i toni perché l’algoritmo premia l’indignazione, il politico che dice volutamente la cosa sgradevole sapendo che incassa attenzione. Sono strateghi del rumore. La loro presunta franchezza è una merce e funziona per la ragione opposta a quella antica: dove l’ingenuus parlava per non dover calcolare, il provocatore strilla perché ha calcolato che strillare paga. È un rovesciamento esatto, mascherato dal fatto che produce all'esterno lo stesso suono.

L’ingenuità dei forti

Il titolo di questo post ha una doppia faccia: questa è la prima. L’ingenuità dei forti. L’ingenuità, nel senso che le tradizioni antiche conservano, è un privilegio di chi è abbastanza solido da non aver bisogno di difendersi. È la libertà che si concede a chi conosce bene il proprio terreno.

Ho conosciuto persone così, nei trent’anni di lavoro. Sono spesso le più qualificate al tavolo. Il senior partner ammette di non capire un passaggio tecnico e chiede di spiegarglielo. Lo studioso che riconosce il valore di un’osservazione che gli arriva da una disciplina lontana dalla sua, senza la prudenza calcolata che gli studiosi maturi costruiscono come scudo. Il dirigente che dice “su questo ho sbagliato”, senza far seguire un “ma” di difesa. Sono gesti che il vocabolario corrente classifica come ingenui, ma che in realtà sono atti di solidità. Solo chi sta saldo nel proprio mestiere può permettersi di esporlo al dubbio. Solo chi non teme di perdere il riconoscimento può permettersi di riconoscere gli altri.

L’aristocrazia romana lo sapeva, e per ragioni molto diverse dalle nostre: era libera per nascita, e la libertà originaria la metteva al riparo dal bisogno di apparire libera. Noi abbiamo perso quella libertà strutturale e ne abbiamo costruita un’altra, fatta di posizioni, ruoli, capitale reputazionale. Difenderla richiede calcolo permanente. E il calcolo permanente, alla lunga, erode esattamente ciò che dovremmo permetterci: la franchezza.

La forza degli ingenui

La seconda faccia. La forza degli ingenui. Se l’ingenuità è un privilegio dei forti, è anche, per movimento contrario, una scelta che produce forza in chi la fa.

Nel piccolo lo vediamo tutti. La riunione cambia temperatura quando qualcuno dice qualcosa di vero invece di qualcosa di atteso. La discussione di progetto si sblocca quando si smette di difendere la propria posizione e si ammettono i propri limiti. La relazione regge gli urti quando c’è una persona che dice quello che pensa anziché quello che conviene. Sono effetti minori, perfino impercettibili se presi singolarmente. Sommati, fanno la differenza tra un’organizzazione che si decompone in cordate e un’altra che continua a produrre senso, tra una vita di lavoro vissuta dietro lo scudo e una vissuta a viso scoperto.

La scelta

Per il romano, forza e ingenuità coincidevano: si era forti perché si era ingenui, si era ingenui perché si era forti; entrambe le qualità provenivano dalla libertà ricevuta in eredità alla nascita. La modernità ha separato le due cose. Ha definito la forza come capacità di calcolo e l’ingenuità come incapacità di calcolare.

Quindici anni fa, su un blog che oggi sembra di un’altra epoca, scrissi un pezzo intitolato “Voglio essere un ingenuo”. Difendevo un appello civile contro le critiche che lo ritenevano irrealistico. Il senso è rimasto lo stesso, anche se il contesto è cambiato. Si rivendica la libertà di non fingere.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

L’offerta di musica alternative & indie è vastissima e si fa un po’ fatica a trovare qualcosa di realmente nuovo o quanto meno diverso rispetto alla media. Ho scoperto questa artista grazie alle segnalazioni di Qobuz, che ha presentato la sua recente produzione come album della settimana.

In effetti, è un album che offre passaggi interessanti, come la ricerca di un suono originale. Ciò che colpisce è soprattutto la voce: modula il timbro come se fossero registri diversi della stessa persona, e ha un carattere asciutto che non assomiglia a quasi nient’altro di ciò che si sente in giro.

Non si fa ricordare subito. Va assimilato ascoltandolo più volte per qualche giorno, senza pretese. Dopo un po’ lo si apprezza davvero.

Da ascoltare.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

C’è un film del 2004 di Peter Segal, 50 First Dates, che da noi è uscito col titolo 50 volte il primo bacio. Adam Sandler si innamora di Drew Barrymore, ma lei ha un trauma cerebrale: ogni notte, mentre dorme, la memoria di tutto ciò che è successo durante il giorno si cancella. Henry — Adam Sandler — capisce che esiste un modo per costruire comunque una relazione. Le registra su VHS un diario quotidiano in cui le racconta chi è lui, come si sono conosciuti e che cosa hanno vissuto insieme. Ogni mattina Lucy lo guarda e, in qualche modo, ricostruisce la sua vita.

Da quando uso quotidianamente i Large Language Model per il mio lavoro, mi ritrovo a fare la stessa cosa. Ogni nuova sessione comincia con un’operazione di ricostruzione: un file .md con il contesto, le skill che descrivono ciò che stiamo facendo e le istruzioni globali per ricordare al modello chi sono e quali sono le mie convenzioni. È diventato un riflesso. E somiglia al diario di Henry.

Una macchina senza stato che scommette

Per andare oltre l'immagine letteraria, è necessario ricordare due questioni tecniche, senza le quali la somiglianza non illumina il problema.

La prima: i transformer (l’architettura su cui si basano tutti gli LLM moderni) sono nati nel 2017 con un mandato preciso, descritto da Vaswani e colleghi nel paper “Attention Is All You Need” [1]. Servono a tradurre, cioè a trasformare una sequenza di input in una di output. Sono una funzione senza memoria: input → output. Non c’è uno stato interno che persiste tra una chiamata e l’altra. Quella che chiamiamo “conversazione” è un’illusione, fabbricata reinviando l'intero storico a ogni nuova chiamata. Uno storico che cresce a ogni interazione, rendendo ogni chiamata sempre più complessa e costosa dal punto di vista computazionale ed economico. Atlan, in un articolo recente sul problema della memoria negli agenti AI, lo dice in modo nitido:

Statelessness is a deliberate trade-off that enables scale and reproducibility. All continuity, including session history, organisational knowledge, and user preferences, must be built externally and injected at runtime [2].

La seconda: il modello non risponde, scommette. Matt Calkins, CEO di Appian, lo ha riassunto sul Wall Street Journal con una formula che vale la pena ricordare:

AI is probabilistic technology, which means it’s slightly unpredictable. Underneath the surface, it is constantly guessing. This is an immutable characteristic of large language models [3].

Anche qui: caratteristica immutabile, non un difetto in attesa di una patch.

Il martello e i chiodi, di nuovo

Qui torno su un tema che ho già trattato in “Per un martello, il mondo è fatto solo di chiodi”. La legge dello strumento ci spinge a considerare l’AI generativa come la risposta a ogni domanda. Quando il problema è integrare l’AI in un processo operativo aziendale — un workflow di approvazione, un sistema transazionale, una procedura amministrativa — la tentazione è di prendere il martello e cercare chiodi ovunque.

Ma i processi operativi che hanno sostenuto l’IT degli ultimi quarant’anni poggiano su tre assunzioni implicite:

1. Lo stato persiste.

2. Il comportamento è deterministico.

3. Il sistema è riproducibile e auditabile.

Tre proprietà che consentono di certificare, controllare, eseguire test di regressione e ricostruire chi ha deciso cosa e perché. Gli LLM violano tutte e tre per design. L’immaturità del prodotto non c’entra: conta la natura dell’architettura.

E nemmeno la corsa allo scaling cambierà queste caratteristiche. I miglioramenti pratici ci sono, perché le innovazioni e le estensioni introdotte aumentano la potenza e la capacità di risolvere i problemi. Ma questo aumento di prestazioni si paga, e si paga molto: un modello di frontiera costa decine di volte più di uno più piccolo. Lo scaling sposta la soglia, ma non la cancella, perché non è in grado di cambiare ciò che il transformer è: resta senza memoria e probabilistico per sua natura. Lo scaling rende il martello più grande. Non lo trasforma in un cacciavite.

Quando il diario costa più del processo

Si può sempre rispondere che basta ricostruire lo stato esternamente, nel file system o tramite strumenti esterni. È vero. È quello che stiamo facendo tutti: io con il mio diario in file .md, le aziende con i loro context layer, gli architetti con sistemi ibridi in cui la parte deterministica e quella probabilistica si parlano.

In linea di principio funziona. Il problema si vede quando si prova a farlo davvero, non a parlarne o a fare esperimenti di laboratorio. Lo stato esterno non è passivo. Va costruito, mantenuto, validato. E deve essere gestito tramite una macchina probabilistica. La stessa che, ogni volta che legge e scrive in quello stato, può scegliere percorsi diversi a partire dallo stesso input.

L’intersezione tra questi due fattori — stato esterno persistente ed elaborazione probabilistica — fa esplodere la complessità in modi che chi non ci ha lavorato fatica a immaginare. Salgono i costi di costruzione, di manutenzione e di test. E con la riproducibilità è anche peggio: lo stesso flusso, eseguito due volte, può produrre due risultati diversi, e ricostruire il senso di quanto fatto diventa un esercizio non banale.

In molti casi, quando si tirano le somme, l'investimento non si ripaga. L'AI funziona, ma farla funzionare seriamente all'interno di un processo operativo costa più di quanto si potesse ipotizzare.

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

1. Ashish Vaswani et al., “Attention Is All You Need”, NeurIPS 2017, arXiv:1706.03762. ↩

2. Atlan, “Why AI Agents Forget: The Stateless LLM Problem”, 2 aprile 2026, https://atlan.com/know/why-ai-agents-forget/. ↩

3. Matt Calkins, “The Software Industry Will Survive AI”, Wall Street Journal, 26 febbraio 2026. ↩

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Roth lo scrisse nel 1991, dopo la morte del padre Herman. Il libro parla di un anziano con un tumore al cervello, negli ultimi mesi di vita, e del figlio che lo assiste. È un libro sulla cura: sull’intimità brutale e tenera che si crea quando un figlio si ritrova a fare per il padre ciò che il padre ha fatto per lui da bambino.

Roth non idealizza suo padre. Herman è testardo, orgoglioso come sanno esserlo certi uomini della sua generazione, a volte difficile. Ed è questa concretezza a rendere il ritratto commovente, un uomo vero, dipinto da un figlio che lo ama senza abbellirlo.

Leggevo e pensavo a mio padre. Alla sua malattia, agli ultimi mesi. Ogni libro parla di noi se lo incontriamo nel momento giusto. Patrimonio mi ha parlato con una voce che non ho dimenticato.

Il patrimonio non è quello materiale, anche se Roth ci riflette con ironia e affetto. È quello che un padre lascia in un figlio: una maniera di stare al mondo, un’etica, una voce che continua a parlare.

La sua l’ho ancora dentro.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Lo strumento operativo attraverso cui questa attitudine si esprime nel mercato è quel che da qualche tempo si chiama AI-washing: rinominare pratiche, prodotti, ruoli esistenti con il vocabolario dell’onda corrente per intercettare l’attenzione e gli investimenti delle imprese. Nel settembre 2024 la Federal Trade Commission americana ha avviato un’iniziativa di enforcement dedicata, Operation AI Comply, con almeno una dozzina di casi formalmente contestati nel solo 2025. Sotto la punta dell’iceberg regolatorio c’è una pratica legale diffusa che ormai è la grammatica di base del mercato dell’AI.

Al di là delle discussioni legali e amministrative, il fenomeno è diffuso e comune. Prendo due esempi recenti, provenienti da domini diversi.

Primo esempio: HTML al posto di Markdown

L’8 maggio 2026, Thariq Shihipar, ingegnere del team Claude Code di Anthropic, pubblica un articolo intitolato “The Unreasonable Effectiveness of HTML”. La tesi è netta: HTML è il formato giusto per gli output dei modelli AI; Markdown va abbandonato. Il pezzo diventa virale (Simon Willison parla di 750.000 visualizzazioni in 48 ore); Andrej Karpathy lo rilancia pochi giorni dopo. Nel giro di una settimana il dibattito su quale debba essere il formato giusto per gli output di Claude, GPT e Gemini occupa un pezzo significativo della conversazione tecnica del settore.

Gli argomenti a favore di HTML sono noti. HTML può contenere SVG, layout strutturati, interattività JavaScript, navigazione interna, color-coding. Dopo cento righe, Markdown è una parete di testo. Da quando le finestre di contesto si sono allargate a centinaia di migliaia di token, il vincolo che aveva reso Markdown la scelta naturale (la sua efficienza in termini di token) è venuto meno. È il momento, si è detto, di passare a HTML.

Il dibattito affronta un problema errato. Si discute di rendering, cioè di come gli output appaiano visivamente al lettore. Il vero problema, che il dibattito sfiora senza nominarlo, è il significato dell’informazione: come si struttura ciò che una macchina probabilistica produce, in modo che umani e altri sistemi possano usarlo, validarlo, trasformarlo, verificarlo. Se non si risolve il problema vero, il resto della discussione è artificioso: si parla di un dettaglio, mentre il bersaglio è altrove.

Markdown è una notazione creata da John Gruber nel 2004 per evitare di dover scrivere HTML a mano. L’ho sempre usato per scrivere documenti in modo facile ed immediato. HTML è una semplificazione di SGML, pensata da Tim Berners-Lee al CERN nel 1991 per la pubblicazione di documenti sul web. Entrambi sono linguaggi per il publishing; entrambi sono privi della capacità di rappresentare la semantica del contenuto. Sostituire Markdown con HTML non risolve il vero problema. Sposta la discussione un metro più in là.

I “razzi per andare sulla Luna” esistono e sono stati studiati da decenni. Alcuni esempi, non esaustivi (con una piccola memoria personale).

• Nel 2000, insieme ad alcuni colleghi del Cefriel e del Politecnico, sviluppammo un sistema per attribuire una semantica agli oggetti sul web. Pubblicammo i risultati alla International Conference on Software Engineering (ICSE) del 2000 a Limerick (Irlanda): “Managing software artifacts on the Web with Labyrinth”.

Software developers are increasingly exploiting the Web as a document management system. However, the Web has some limitations, since it is not aware of the structure and semantics associated to pieces of information (e.g., the fact that a document is a requirement specification) and of the semantics of relationships between pieces of information (e.g., the fact that a requirement specification document may be associated to some design specification document). In the Labyrinth project we enhance the capabilities of the Web as a document management system by means of a semantic model (called schema, in analogy with database schemas), which is associated to Web documents. This model is itself a Web document and can be accessed and navigated through a simple Web browser.

• Nel maggio 2001, Tim Berners-Lee, James Hendler e Ora Lassila pubblicano “The Semantic Web” su Scientific American. Il sottotitolo è programmatico: “A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities”. Il paper ha migliaia di citazioni.

• OWL (Web Ontology Language) diventa una W3C Recommendation il 10 febbraio 2004. OWL 2 nel 2009. È il linguaggio standard per rappresentare formalmente ontologie, classi, relazioni, vincoli. Lo usano in biomedicina, nella finanza e nelle agenzie governative da vent’anni.

• Il 16 maggio 2012 Google lancia il proprio Knowledge Graph. Lo slogan di Amit Singhal è “things, not strings”: cose, non stringhe. Al lancio: 500 milioni di entità, 3,5 miliardi di fatti. È il motore semantico alla base della ricerca su Google da quattordici anni.

• Palantir Foundry, lanciata nel 2016, costruisce il proprio Ontology Layer, una rappresentazione semantica delle entità di business del cliente (clienti, ordini, transazioni, impianti), utilizzando metodi formali per definire azioni, automazioni e regole. È il cuore di Foundry, Gotham, AIP.

• Amazon Web Services usa TLA+, il formalismo creato da Leslie Lamport, dal 2011 per verificare la correttezza di S3, DynamoDB e Aurora. Il caso è documentato nel paper “How Amazon Web Services Uses Formal Methods”, pubblicato sulle Communications of the ACM nel 2015.

Nessuna di queste (o altre) tecnologie compare nel dibattito tra HTML e Markdown. Posso provare a immaginare il perché. Markdown e HTML sono semplici e familiari, utilizzabili in pochi minuti con uno strumento di GenAI e immediatamente visibili come artefatti. La rappresentazione semantica formale richiede rigore, modellazione e conoscenza del dominio e i suoi risultati non producono “wow” in una demo. VC, analisti, stampa di settore pagano un premio per il prodotto che fa demo veloci. Le aziende si adeguano.

Secondo esempio: il Forward Deployed Engineer

Andreessen Horowitz, una delle più grandi società di venture capital della Silicon Valley, ha pubblicato nel 2025 un articolo intitolato “Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups”. Joe Schmidt, autore del pezzo, lo definisce “il lavoro più caldo nelle startup”. Indeed e Financial Times, in un’analisi indipendente, hanno rilevato un aumento dell’800% delle offerte di lavoro per Forward Deployed Engineer (FDE) tra gennaio e settembre 2025. La retribuzione totale di un FDE in un AI lab oscilla tra 250.000 e 400.000 dollari l’anno. Il profilo richiesto è quello di un CTO di startup.

Qual è il lavoro di un Forward Deployed Engineer? Eccolo nelle parole di Salesforce, che nell'aprile 2026 ha lanciato un Forward Deployed Engineering Partner Network con l'obiettivo di raggiungere 1.000 FDE in rete con i partner del proprio ecosistema: “code, consult, and translate agentic AI into working solutions, often while sitting side by side with the customer”. Tradotto: scrivere codice, fare consulenza, tradurre l’AI in soluzioni funzionanti, lavorando fisicamente a fianco del cliente.

Faccio anche qui un esercizio storico.

• Nel 1956, IBM ha già un consolidato Field Engineering: tecnici che si recano dal cliente per installare e mantenere mainframe come l'IBM 704 (introdotto nel 1954). Il ruolo del Customer Engineer era stato formalizzato da Tom Watson già nei primi anni Quaranta. Nel 1964, con il lancio del System/360, nasce un ruolo correlato e più specializzato, il Systems Engineer, dedicato al software e alle applicazioni aziendali. Nel 1975, IBM formalizza i Data Processing Support Services (DPSS), la forma istituzionale del lavoro embedded.

• Negli anni Ottanta e Novanta, i grandi della consulenza, Andersen Consulting in testa, mettono i propri ingegneri-consulenti nelle aziende clienti per implementare i sistemi ERP, come SAP e Oracle. Andersen diventerà Accenture, che oggi conta circa 780.000 dipendenti.

• Tra il 1996 e il 1999, il bug del millennio (Y2K) genera un’esplosiva domanda di tecnici esperti di COBOL e di mainframe. Infosys, Wipro, TCS, HCL costruiscono il modello del body shopping indiano: ingegneri spediti presso il cliente, prezzo basato sul tempo, scala industriale.

• Nel 1999, Kent Beck pubblica Extreme Programming Explained. Una delle dodici pratiche fondative di XP è l’on-site customer: il cliente fisicamente presente nello stesso spazio degli sviluppatori, perché il valore di avere domini complessi vicino agli ingegneri è troppo grande per affidarlo a documenti scritti.

• All'inizio degli anni Duemiladieci, Palantir codifica il ruolo di Forward Deployed Software Engineer (chiamato anche "Delta"): nel 2009 ne aveva già 120 schierati su JPMorgan Chase. È il padre diretto di ciò che oggi chiamiamo "Forward Deployed Engineer”.

• Nel 2025 OpenAI, Anthropic, Databricks, Cohere, Ramp, Rippling, Intercom e Salesforce adottano FDE su larga scala, presentandolo come una nuova categoria di lavoro.

L’obiezione facile è che oggi un FDE costa quattrocentomila dollari l’anno e ha responsabilità da CTO, quindi non è assimilabile a un body shopper indiano da quarantamila dollari. È un’obiezione corretta ma debole. Il ciclo storico delle figure embedded è documentato e ricorrente: nascono in alto, scalano, diventano servizi standard. L’IBM Field/Systems Engineer del 1965 era una figura d’élite; nel 2010 IBM Global Services aveva già spostato in offshoring buona parte del lavoro. Andersen Consulting, nel 1985, si misurava con McKinsey; Accenture nel 2020 contava 506.000 dipendenti, nel 2024 ne contava 774.000 e nel 2025 oltre 779.000.

Il caso più puro lo offre Salesforce. Nel 2005, su consiglio di Steve Jobs, Marc Benioff lancia AppExchange, il primo marketplace strutturato per i partner consulenti di un’azienda SaaS. Da allora i Salesforce Consulting Partners sono cresciuti fino a costituire un'industria multimiliardaria. Tier formalizzati di partnership, una lunga coda di partner regionali. In Italia c’è, ad esempio, Atlantic Technologies (vicina di casa di Cefriel a Milano), oggi parte del gruppo Engineering, partner di Salesforce dal 2005, premiata da Salesforce come Consulting Implementation Partner of the Year nel 2024 e nel 2025. Negli stessi mesi in cui Atlantic riceveva il premio per aver implementato Salesforce presso le aziende clienti, Salesforce annunciava il proprio Forward Deployed Engineering Partner Network come se fosse una nuova categoria professionale. Sotto un altro nome, è lo stesso lavoro che la stessa azienda affida ai partner da vent’anni.

Salesforce è soltanto l’esempio più visibile di un pattern industriale che vale per l’intera coda dei vendor che vendono soluzioni “AI-powered” o “agentic AI” come fossero nuove categorie di prodotto. VC, analisti, stampa di settore pagano un premio per l’etichetta nuova. Le aziende si adeguano.

Memoria

Qoelet, al primo capitolo, ha una seconda frase che si cita meno spesso della prima (Qoelet 1, 11): “Nessun ricordo resta degli antichi, ma neppure di coloro che saranno si conserverà memoria presso quelli che verranno in seguito.”

La perdita di memoria storica precede la ripetizione e la rende possibile. La sostituzione di Markdown con HTML viene presentata come una svolta, perché si ignorano anni di Semantic Web e di Knowledge Representation. Il Forward Deployed Engineer viene presentato come un ruolo nuovo perché si ignorano settant’anni di consulenza tecnica embedded. La memoria non viene nemmeno cercata.

Qoelet aveva ragione, e forse aveva ragione anche di più di quanto immaginasse.

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il like ha reso visibile, misurabile e monetizzabile qualcosa che esisteva da molto prima: la tendenza a dare più peso all’immagine che ai fatti, alle parole che alle prove, all’apparenza che alla sostanza. I social media sono la forma più recente di un meccanismo antico. Questa epoca è la conseguenza di una sostituzione che abbiamo accettato da tempo, spesso senza accorgercene.

Ci cibiamo di parole

Abbiamo imparato a trattare la parola come un fatto. Chi usa il tono giusto, le metafore appropriate, il vocabolario dell’autorevolezza ha già metà della partita vinta. Basta che le parole suonino come se ci fosse qualcosa di concreto; l’importante è che siano suadenti, capaci di catturare l’immaginario, le speranze, i sogni e i bisogni delle persone. Anche se poi ci si accorge che accade proprio quanto evocato da un film e da un romanzo di qualche decennio fa: “sotto il vestito, niente”.

In politica, l’annuncio ha sostituito la realizzazione da così tanto tempo che nessuno sembra più notare la differenza. In azienda, il piano strategico presentato con le slide giuste raccoglie applausi prima ancora che qualcuno verifichi se regge al contatto con la realtà. Nelle relazioni personali e professionali, le dichiarazioni di stima, di vicinanza, di solidarietà vengono scambiate per comportamenti sinceri.

Il problema è che abbiamo smesso di pretendere i fatti come prova. Abbiamo abbassato l’asticella fino al punto in cui la parola, anche quando è vaga, anche quando è contraddittoria, anche quando è stata smentita cento volte, mantiene un peso che i fatti faticano a scalfire. Ci cibiamo di parole e le trattiamo come nutrimento. Spesso non sono altro che il nulla.

Inauguriamo, non manteniamo

Il primato dell’immagine si manifesta con la massima chiarezza nell’inaugurazione. Il taglio del nastro, la foto di rito, il discorso celebrativo, l’articolo sul giornale. Tutti presenti, tutti entusiasti, tutti pronti a rivendicare una parte del merito.

Poi vengono gli anni, il lavoro ordinario, ripetitivo, invisibile che tiene in piedi ciò che è stato costruito. Nessuno fotografa un’ispezione. Nessuno scrive un comunicato stampa per dire che i cavi sono stati verificati, che le fondamenta reggono, che il sistema funziona ancora perché qualcuno ci ha lavorato in silenzio. La manutenzione non produce immagine, non si presta alla celebrazione, non genera applausi. Di conseguenza viene rinviata, tagliata, sacrificata quando servono risorse da spostare su qualcosa che si vede, che si inaugura, che si annuncia.

Questo vale per le infrastrutture fisiche, ma vale anche per le organizzazioni, le istituzioni, qualsiasi sistema complesso. Costruire è visibile, mantenere è invisibile. In un’epoca che misura il valore in base al consenso, l’invisibile non rientra nella contabilità del successo.

Premiamo l’apparenza, non la competizione

Il merito ha senso quando c’è una prova, dove si compete, dove esistono alternative e il risultato viene confrontato con uno standard esterno. Là dove non c’è confronto, il merito perde la misura.

Molte opere presentate come conquiste sono state realizzate con fondi pubblici, senza concorrenza e senza una valutazione delle alternative. La narrazione celebrativa fa il resto. Nessuno ha potuto valutare se quel progetto fosse il migliore possibile con quelle risorse, perché non c’era nessun altro che si candidasse. Il successo coincide con la dichiarazione di intenti. Il termine “merito” si applica per inerzia.

Il minimo, in questi casi, dovrebbe essere non sprecare. Spesso non è vero nemmeno quello. Eppure il linguaggio del merito e della capacità accompagna l’opera in ogni passaggio: dall’annuncio iniziale alla narrazione retrospettiva. Si raccolgono applausi per qualcosa che non è mai stato messo alla prova.

Curiamo le relazioni, non la lealtà

La stessa logica permea le relazioni umane. Siamo diventati abili a curarle nella forma: presenti agli eventi giusti, “di moda”, puntuali nei messaggi di auguri, visibili nelle espressioni pubbliche di solidarietà. Il networking è diventato una competenza professionale riconosciuta, qualcosa che si insegna e si certifica.

La lealtà è altra cosa. Si misura quando essere presenti e testimoniare costa: quando difendere qualcuno significa esporsi, quando mantenere una promessa è scomodo, quando essere onesti richiede di dire cose che l’altro non vuole sentire. La lealtà si manifesta nei momenti in cui sarebbe più conveniente fare altrimenti.

Accade troppo spesso che persone che curano con attenzione l’immagine di una relazione spariscano o si trovino dall’altra parte proprio nel momento in cui quella relazione richiede qualcosa di concreto. Raramente è ipocrisia consapevole. È il risultato di una cultura che ha insegnato a dare valore alla forma, alle parole, ai gesti pubblici dei legami, ai piccoli interessi più che ai comportamenti su cui quei legami si reggono o crollano.

Quando abbiamo deciso che bastava apparire?

Mi chiedo quando tutto questo è divenuto un fatto acclarato e accettato. Non c’è stato un momento preciso, né una scelta collettiva consapevole. Uno scivolamento graduale, silenzioso, come l’erosione di un argine che nessuno osserva finché non crolla e le acque sommergono gli spazi circostanti.

Quando abbiamo deciso che un annuncio vale quanto una realizzazione, che una dichiarazione di intenti sostituisce i comportamenti, che l’immagine di una relazione equivale alla relazione?

Quello che osservo è che premiamo le parole senza i fatti, le inaugurazioni senza la manutenzione, le conquiste senza la competizione, le relazioni senza la lealtà. Il like è solo il modo più recente ed efficiente che abbiamo trovato per farlo.

La domanda rimane aperta, come tutte quelle a cui spesso preferiamo non rispondere.

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Their Satanic Majesties Request è del dicembre 1967, pubblicato pochi mesi dopo Sgt. Pepper’s. All’epoca, la critica lo trattò male: copia, deriva psichedelica, errore. Anche la band se ne è quasi dissociata.

Ascoltandolo emergono mellotron, sitar, frammenti orchestrali; “She’s a Rainbow” entra come una ninna-nanna; “2000 Light Years from Home” è molto diversa dal blues. Una band che, per un solo disco, prova a essere qualcun altro. Non sempre riesce e questo lo rende interessante.

Quarantaquattro minuti di un’estraneità che oggi suona molto meno strana di quanto sembrasse allora.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Nel 2021, l’Italia ricevette un’assegnazione PNRR per un valore senza pari nella storia degli interventi straordinari nel nostro Paese: 194,4 miliardi di euro, cui si aggiunsero 30,6 miliardi del Piano Nazionale Complementare (poi ridotti a 27,5 miliardi nelle successive rimodulazioni). Circa 220 miliardi in cinque anni. Una cifra che avrebbe dovuto, almeno secondo le intenzioni dichiarate, “riparare i danni economici della pandemia e costruire un’Italia nuova”.

Siamo nel 2026. I soldi sono in gran parte stati assegnati, in parte già erogati, in parte ancora da spendere nella corsa contro il tempo (scadenza 30 giugno 2026) per il completamento materiale dei progetti, con rendicontazione finale entro il 31 agosto. Il dibattito politico è dominato da una domanda: si riuscirà a “spendere tutti i fondi”? Come se l’obiettivo fosse la spesa, non la trasformazione. È un male diffuso: quante volte si sente dire, anche nelle imprese, “Dobbiamo spendere per non perdere i soldi a budget”?

Nel 2021, quando il piano era ancora in fase di definizione, scrissi che il PNRR rischiava di ripetere gli errori del passato. Nel 2024, scrissi che, nella sua impostazione, era “semplicemente disastroso” come strumento per finanziare ricerca e innovazione — non stabile, non focalizzato, non finalizzato, non competitivo. Non mi piace avere ragione in questo modo.

La narrazione dell’austerità

“Non ci sono i soldi.” È la frase che sento ripetere più spesso quando si parla di università, ricerca, infrastrutture digitali, formazione professionale, innovazione e sviluppo economico (e non solo). La narrazione è diventata così radicata da fungere da chiusura di ogni discussione: si vorrebbe fare di più, ma i vincoli di bilancio non lo consentono.

Il problema è che questa narrazione non regge all’esame dei fatti.

L’Italia non è solo il paese che ha ricevuto la quota in valore assoluto più elevata del PNRR, ma è anche il paese che, storicamente, spende i fondi strutturali europei in ritardo e con bassa qualità progettuale — a metà del ciclo 2014–2020 aveva utilizzato meno del 40%, uno dei tassi più bassi dell’UE. I miliardi che, a vario titolo, abbiamo speso per iniziative opinabili avrebbero potuto finanziare la trasformazione del Mezzogiorno, la modernizzazione della PA, il risanamento degli edifici scolastici, il rafforzamento della ricerca e dell’innovazione o interventi sul dissesto idrogeologico. I fondi c’erano; gli investimenti strutturali non si sono visti se non raramente e in modo estemporaneo, o per le intuizioni del singolo amministratore e non per una volontà politica coesa e solida nel tempo.

Quello che si è visto è la (ri)distribuzione. Il Superbonus 110% — una misura introdotta con logiche in parte sovrapponibili a quelle del PNRR — ha assorbito oltre 120 miliardi, quattro volte la stima iniziale di 35 miliardi. Prevalentemente per ristrutturazioni edilizie private. Non una politica di trasformazione strutturale per lo sviluppo del Paese, bensì una politica volta alla raccolta del consenso. Un trasferimento di risorse enormi, con un effetto sul PIL a breve termine e quasi nessun impatto sulla produttività, sull’innovazione e sulla competitività futura del Paese.

La scelta che non viene nominata

La logica politica è comprensibile, anche se non giustificabile. I cicli elettorali sono brevi; i risultati degli investimenti strutturali sono lunghi; il consenso si costruisce sul tangibile e sull’immediato. Investire seriamente nella ricerca universitaria, per esempio, produce effetti in dieci anni, non in dieci mesi. Riformare la PA digitalmente richiede anni e anni di lavoro ostinato, di change management, di resistenze da superare. Quello che genera consenso immediato è il bonus, il sussidio, l’emergenza affrontata con uno stanziamento straordinario, il titolo di giornale che recita “stanziati X miliardi per Y”. Non importa poi come vengano spesi.

Il problema non è l’austerità

La narrazione dell’austerità — con il suo corollario della “cattiva Europa” che imporrebbe vincoli “insensati” — riemerge ogni volta che si vuole giustificare una scelta politica che, in realtà, ha altri driver. Gli economisti discutono ancora se in Italia vi sia davvero stata l’austerità e in che misura. Ma la funzione retorica di quella narrazione è chiara: spostare l’attenzione dalle scelte allocative ai vincoli — veri o presunti — entro i quali sarebbero state compiute.

L’alibi dell’austerità non spiega il Superbonus. Non spiega i fondi europei rimandati al mittente o spesi senza criteri. Non spiega il PNRR senza una strategia industriale coerente. Non spiega vent’anni di promesse sulla digitalizzazione della PA. Non spiega perché la quota del PIL destinata alla ricerca e allo sviluppo sia tanto bassa (l'Italia investe l'1,33% del PIL, contro una media UE del 2,2% e OCSE del 2,8%): non è una questione di risorse disponibili, ma di priorità politica.

Altri paesi hanno gestito fondi analoghi con una qualità progettuale superiore. Non era una questione di volumi: era una questione di scelte.

Risorse straordinarie, scopi straordinari

C’è un secondo errore, più sottile della scelta distributiva, che ho analizzato nei post dedicati al PNRR su questa pubblicazione poche settimane fa — Le strutture nate con il PNRR cercano una exit strategy e Un piano straordinario per spese ordinarie, entrambi di aprile. Anche quando si decide di investire, non basta farlo, bisogna farlo bene: le risorse straordinarie devono servire scopi straordinari.

Una risorsa una tantum di proporzioni eccezionali ha senso quando finanzia qualcosa che la spesa ordinaria non potrebbe acquistare: un’infrastruttura di ricerca da decine di milioni, un cluster di supercalcolo, una riforma strutturale della pubblica amministrazione. Cose che, una volta costruite, restano. Quando invece le risorse straordinarie servono ad amplificare temporaneamente attività che il sistema ordinario finanzia già — borse di dottorato, contratti a termine, bandi secondo le modalità di sempre ma con dieci volte i soldi — il risultato è un rigonfiamento che si sgonfia appena finiscono i fondi. Tra il 2025 e il 2026, oltre 35.000 contratti precari nel sistema universitario sono in scadenza; il piano di stabilizzazione del MUR ne copre meno di duemila.

Questa è la patologia specifica del PNRR italiano, oltre la scelta distributiva: l’assenza di una riflessione sulla sostenibilità nel tempo e sulla finalizzazione delle risorse straordinarie. Un piano davvero straordinario avrebbe scelto poche cose, le avrebbe rese permanenti e avrebbe lasciato che il sistema rispondesse al resto con i suoi strumenti ordinari. Invece si è amplificato l’ordinario su scala straordinaria. Le infrastrutture fisiche restano — è un guadagno reale. Ma migliaia di persone formate con fondi pubblici restano senza sbocco. Le Fondazioni Hub stanno cercando un’exit strategy. Il bilancio strutturale del Paese è esattamente quello di prima.

Cosa cambierebbe se cambiassimo la domanda

Dovremmo smettere di chiederci “dove trovare i soldi” e cominciare a chiederci “come spendiamo quelli che abbiamo”. Cambierebbe il modo in cui valutiamo i governi — non sulla capacità di reperire risorse, ma sulla qualità della loro allocazione. Cambierebbe persino il modo in cui pensiamo all’università e alla ricerca: non come a spese da contenere, ma come investimenti il cui rendimento si misura in decenni.

Richiederebbe anche una cultura politica disposta a rinunciare al consenso di breve periodo. A spiegare ai cittadini che i soldi del PNRR non sono aiuti a fondo perduto da riscuotere, ma un debito che verrà restituito — e che il problema non è incassare la rata, ma trasformare davvero il Paese.

Non so se questa cultura sia disponibile. Non vedo molti segnali.

Torniamo al PNRR

La scadenza di giugno 2026 si avvicina. Il dibattito ruota attorno alla corsa per “prendere i soldi”. Non sulla qualità degli investimenti; non su ciò che rimarrà di questo piano tra dieci anni; non su quante imprese avranno davvero aumentato la produttività, quante PA avranno davvero cambiato i loro processi, quanta ricerca si sarà trasformata in innovazione.

Fonti

• Cifra PNRR (194,4 mld) e Piano Nazionale Complementare (30,6 mld originari, poi ridotti a 27,5): Camera dei Deputati — PNRR; Italia Domani — Quadro finanziario PNRR.

• Scadenze PNRR (30 giugno 2026 per il completamento materiale, 31 agosto per la rendicontazione finale): Openpnrr — Scadenze.

• Confronto storico con interventi straordinari precedenti (Cassa per il Mezzogiorno, Piano Marshall): Wikipedia — Cassa del Mezzogiorno; Corte dei Conti — Riformare l’intervento straordinario.

• Tassi di assorbimento dei fondi strutturali UE nel ciclo 2014–2020 (sotto il 40% a metà ciclo): OCPI Cattolica — Fondi strutturali.

• Costo Superbonus 110% (oltre 120 miliardi, contro una stima iniziale di 35): OCPI Cattolica — Effetti del Superbonus.

• Quota PIL Italia in R&S (1,33%) e confronto con media UE (2,2%) e OCSE (2,8%): ISTAT — Ricerca e sviluppo in Italia; Eurostat — EU R&D spending; OCPI Cattolica — Divario R&S Italia-OCSE.

• Sostenibilità delle strutture PNRR e finalizzazione delle risorse straordinarie: Le strutture nate con il PNRR cercano una exit strategy (A bassa voce, aprile 2026); Un piano straordinario per spese ordinarie (A bassa voce, aprile 2026).

• Dato 35.000 contratti precari in scadenza nel sistema universitario 2025–2026: Associazione Dottorandi e Dottori di Ricerca Italiani (ADI), analisi sul reclutamento universitario, gennaio 2026 — citata in Un piano straordinario per spese ordinarie (A bassa voce).

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Hesse lo scrisse durante la seconda guerra mondiale e fu pubblicato nel 1943. È la sua opera più lunga e ambiziosa. Racconta di un futuro lontano, in una provincia chiamata Castalia, dove un’élite intellettuale vive separata dal mondo, in una sorta di monastero laico del sapere. Al centro c’è il Giuoco delle Perle di Vetro: una disciplina che sintetizza matematica, musica, storia e filosofia in un linguaggio formale di suprema eleganza.

Josef Knecht ne è il Magister Ludi — il maestro del Giuoco, il grado più alto di Castalia. Al culmine della sua carriera, Knecht scrive una lettera alla Direzione e se ne va: lascia tutto perché sente che Castalia si è chiusa in sé stessa, lontana dalla vita vera. Si rende conto che un’eccellenza coltivata lontano dal mondo rischia di risultare sterile. Vuole tornare tra gli uomini, insegnare a un ragazzo, vivere la vita delle persone. Morirà in un lago di montagna, gelido, cercando di tenere il passo con il giovane Tito, che si è tuffato all’alba.

Spero di non apparire troppo presuntuoso se dico che quando rileggo la vita di Knecht e, soprattutto, quello che scrive nella sua lettera prima di lasciare Castalia, rivivo, nel mio piccolo, le mie esperienze ed emozioni di questi anni.

In quella lettera con cui annuncia le sue dimissioni, c’è un particolare che non dimentico mai. Hesse inserisce un passaggio che porto con me da decenni:

"Vigliacco chi si sottrae alle fatiche, ai sacrifici e ai pericoli che il suo popolo deve affrontare, ma non meno vigliacco e traditore chi vien meno ai princìpi della vita spirituale per amore di interessi materiali, chi, per esempio, è disposto a lasciare ai potenti la decisione su quanto faccia due per due. Sacrificare il senso della verità, l'onestà intellettuale, l'osservanza delle leggi e dei metodi dello spirito a qualunque altro credo, anche a quello patriottico, è tradimento..."

Sembra una difesa della scienza contro il potere. Invece, è soprattutto l’affermazione di un valore umano e professionale, l’impegno nella ricerca e nella testimonianza della verità, il culto dell’onestà intellettuale, anche quando dispiace, anche a costo di perdere qualcosa, anche quando chi ti sta davanti preferirebbe sentire altro.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Analizzare vuol dire comprendere un programma già scritto, seguirne la logica, riconoscere gli errori. Sintetizzare significa partire da un problema e costruire la soluzione: scrivere il programma, non solo leggerlo.

Sono due capacità diverse e la sintesi non deriva automaticamente dall’analisi. Uno studente può capire perfettamente il codice che mostro alla lavagna e non riuscire a scriverne uno analogo da solo. È un’esperienza comune a chiunque insegni programmazione. Ed è, a ben pensarci, il segnale di qualcosa di più profondo e di valenza generale: sapere non equivale a saper fare.

Costruire e riconoscere chiedono cose diverse

Scrivere un programma vuol dire tenere insieme molte cose contemporaneamente: cosa devi fare, come strutturarlo, quali casi limite gestire, quali errori il compilatore segnala. Tutto va deciso esplicitamente: ogni scelta sintattica, ogni struttura di controllo, ogni gestione di un errore.

Verificare il codice generato da un LLM, o quello scritto da chiunque altro (un docente alla lavagna, un collega, un libro di testo), è un’operazione di analisi. Si scorre, si riconosce il pattern, si dà un giudizio di plausibilità. Il codice sembra corretto, la struttura è familiare, il risultato appare ragionevole. Spesso ci si ferma lì.

Il fenomeno è preesistente, ma l’AI lo amplifica di un ordine di grandezza: la situazione in cui qualcun altro scrive il codice e io mi limito a leggerlo passa da caso particolare a modalità di lavoro principale, presente in qualsiasi momento, su qualunque problema.

C’è una tendenza naturale a risparmiare sforzo. Quando ci viene offerta una strada più breve, una risposta già confezionata, un output da approvare anziché da costruire, la prendiamo volentieri. L’AI ci offre questa strada ogni giorno.

Quello che vedo cambiare

Negli ultimi due anni vedo una tendenza a sottovalutare il ruolo della sintesi. Nelle università il problema può essere contenuto: lo studente che usa l’AI per tutto il semestre deve comunque dimostrare di saper risolvere gli esercizi all’appello d’esame (almeno nel mio caso), e questo è un presidio utile. Nel lavoro quel presidio non c’è. Si vede il codice, sembra ragionevole, si procede. I problemi emergono quando l’AI non è disponibile, quando il problema è nuovo, quando serve davvero costruire qualcosa da zero. O quando si presentano errori che costringono a entrare nel merito delle scelte effettuate.

Chi scrive il codice accumula comprensione in modo diverso da chi lo legge. Fa scelte, sbaglia, torna indietro, ricostruisce. Questo processo, faticoso, a tratti frustrante, è esattamente il meccanismo con cui le competenze si sedimentano. È il tipo di apprendimento che resiste nel tempo.

Chi invece usa l’AI per generare e si limita a verificare l’output può capire ciò che vede. Spesso capisce anche abbastanza bene. Ma quella comprensione non si trasforma in capacità produttiva, perché non ha mai dovuto costruire nulla.

Il punto non è che usare l’AI sia sbagliato. È che usarla per la produzione, riservandosi solo il ruolo di revisore, rischia di generare un profilo cognitivo sbilanciato: molta analisi, poca sintesi.

La perdita che non si vede

Il paradosso è che questa perdita è silenziosa.

Uno studente o un professionista che si affida all’AI per produrre non percepisce immediatamente la regressione. I risultati arrivano, il codice funziona, il lavoro avanza. L’effetto emerge solo dove l’AI non arriva: davanti a un problema davvero nuovo, a un vincolo che gli strumenti non hanno mai visto, alla necessità di costruire da zero senza appoggi.

È lo stesso fenomeno che si osserva con la navigazione GPS: ci si orienta benissimo finché si segue la freccia, ma si scopre di aver perso il senso dello spazio e dell’orientamento quando il segnale manca.

E i dati empirici lo confermano. Studenti che imparano con ChatGPT, a 45 giorni di distanza, ricordano significativamente meno. Lo stesso pattern emerge nei task di programmazione: chi delega all'AI accumula meno competenza, anche quando l'obiettivo è imparare.

Una domanda che resta aperta

Non ho una risposta semplice. Né penso che la risposta sia “non usate l’AI”.

Credo che gli studenti debbano imparare a scrivere il codice da soli. Non per feticismo del passato, né per diffidenza verso gli strumenti. Ma perché capire non basta e la capacità di costruire va protetta, anche quando ogni giorno ci viene offerta una scorciatoia.

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Vi ricordate la stagione in cui il digitale terrestre avrebbe dovuto risolvere anche il problema della connessione a Internet? Non parlo della transizione dalla TV analogica a quella digitale. Quella era necessaria e, in sé, sensata. Parlo del momento in cui, anziché investire seriamente in banda larga, si pensò di usare il decoder del digitale terrestre come gateway per accedere alla rete. La piattaforma MHP, il canale di ritorno, i servizi interattivi via televisore. Una soluzione elegante sulla carta che utilizzava un’infrastruttura già finanziata.

Il digitale terrestre era nato con uno scopo preciso: trasmettere segnali in una sola direzione, dalla torre all’antenna di casa. Adattarlo a una comunicazione bidirezionale, che è la natura essenziale di Internet, richiedeva di piegarne il funzionamento in modo innaturale, ricorrendo a una serie di workaround. I risultati furono quelli prevedibili: lentezza, instabilità, adozione marginale. Non perché la tecnologia fosse scadente nel suo ambito naturale (era ottima per ciò per cui era stata progettata), ma perché nessuna quantità di adattatori compensa un’incompatibilità di fondo tra ciò che una tecnologia sa fare e ciò che le si chiede di fare.

Quella storia mi torna in mente ogni volta che partecipo a una riunione in cui si parla di “usare l’AI” per automatizzare un processo aziendale. Riconosco la stessa struttura mentale: la pressione a usare ciò che è disponibile, la difficoltà di fermarsi a capire se sia lo strumento giusto e la tendenza a scoprire i limiti solo dopo aver già investito. Ovviamente, il mio è soprattutto un confronto di costume che non intende indicare una stretta analogia tra due situazioni diverse, ma evidenziare un atteggiamento culturale, un vizio di postura che spesso ci penalizza.

La pressione del momento

Ogni settimana un annuncio. Ogni convegno ha una roadmap. Ogni consiglio di amministrazione ha una nuova voce di budget.

È indubbio che l’AI sia importante. E, ovviamente, lo è molto più del digitale terrestre, con dinamiche e risvolti ben più articolati e profondi. Tuttavia, la fretta di fare ha superato, in molti contesti, la comprensione del senso di ciò che si intende fare. Abbiamo davvero capito il problema che vogliamo risolvere? Ci siamo fermati a studiare? Abbiamo guardato sotto il cofano dell’auto?

Cosa c’è sotto il cofano

Ho già esplorato questo tema in un post precedente (Quando il computer indovina e quando calcola), ma vale la pena riprenderlo con occhi più operativi.

Permettetemi tre osservazioni limitando i tecnicismi (i tecnici perdonino le semplificazioni).

La prima. A differenza di un database che risponde sempre allo stesso modo alla stessa query, un sistema di AI generativa non cerca la risposta più probabile in assoluto (farlo produrrebbe output rigidi e qualitativamente inferiori), ma campiona tra le opzioni più plausibili. Quella variabilità è strutturale: la risposta può variare. Esiste un parametro tecnico, la cosiddetta “temperatura”, che si può impostare per ridurre tale variabilità. Ma i ricercatori della Penn State e di Comcast AI Technologies hanno mostrato che lo stesso prompt, fornito dieci volte nelle stesse condizioni (temperatura minima, sistema identico), produce risultati diversi nel 15% dei casi, con differenze di accuratezza fino al 70% tra il risultato migliore e quello peggiore. Non è un bug risolvibile con una patch perché è una conseguenza delle scelte architetturali con cui i sistemi AI vengono tipicamente costruiti e messi in esercizio.

La seconda. Uno studio condotto su 758 consulenti di una delle più grandi società di consulenza strategica al mondo ha misurato con precisione dove l’AI funziona e dove no. Il risultato è controintuitivo: la frontiera non separa i task facili da quelli difficili. Separa quelli che si adattano alla natura probabilistica del sistema da quelli che richiedono precisione deterministica, in modo irregolare e non prevedibile a priori. Lo stesso sistema che supera brillantemente un problema di strategia complessa può fallire su un problema a risposta univoca che richiede ragionamento esplicito anziché il riconoscimento di pattern. In pratica, il sistema eccelleva nel caso di analisi qualitativa di scenari, sintesi di informazioni, interpretazione di testi complessi. Al contrario, inciampava nel ragionamento quantitativo preciso, nella verifica dei calcoli e nei compiti a risposta univoca. Chi ha misurato ha rilevato un +40% di qualità nei compiti in cui il sistema eccelle e un +19% di errori in quelli in cui inciampa. Il problema per chi deve decidere è che non è semplice sapere, in anticipo, in quale categoria cade il proprio processo specifico.

La terza. Un concetto che vale la pena tenere a mente. Andrej Karpathy, uno dei ricercatori che ha definito il settore, già responsabile dell’autopilot di Tesla per cinque anni, ha descritto così la sfida di costruire sistemi AI affidabili (podcast con Dwarkesh Patel, YouTube):

“It’s a march of nines. Every single nine is the same amount of work. When you get a demo and something works 90% of the time, that’s just the first nine. Then you need the second nine, a third nine, a fourth nine, a fifth nine. While I was at Tesla for five years or so, we went through maybe three nines or two nines. There are still more nines to go.”

Il punto è sottile ma cruciale: la distanza tra un sistema affidabile al 90% e uno affidabile al 99% richiede lo stesso sforzo di quella tra il 99% e il 99,9%. Ogni nine è equidistante per quanto riguarda il lavoro. Raggiungere il 99% di affidabilità per ogni singola operazione è già un traguardo straordinariamente difficile, non un punto di partenza scontato. E anche il 98% è già un risultato ambizioso in contesti reali.

E ora aggiungiamo la seconda dimensione del problema. Un processo aziendale è una catena di operazioni: approvazione delle pratiche, gestione degli ordini, riconciliazione dei dati, flussi di compliance: decine di passaggi in sequenza, ciascuno con la propria probabilità di errore. Assumendo che ogni passo sia indipendente dagli altri, la probabilità che l’intera catena vada a buon fine è il prodotto delle probabilità di ciascun passo. E si tratta già di un caso ottimistico: se gli errori non sono indipendenti, se un errore in un passo aumenta la probabilità di errore nel passo successivo, come spesso accade nei processi reali, il risultato peggiora. Gli stessi articoli che trattano del “march of nines” fanno un esempio numerico: un processo di dieci passi, ciascuno affidabile al 98%, ha una probabilità di successo end-to-end dell’82%. Già questo dovrebbe far riflettere. Ma quel calcolo presuppone due condizioni favorevoli: che il 98% per singolo passo sia raggiungibile (Karpathy ci ha appena detto quanto costa) e che il processo si esaurisca in dieci operazioni. Nei processi reali entrambe le assunzioni sono ottimistiche. Lascio a voi il calcolo dei casi in cui non lo siano. Dato un problema, è accettabile che in una percentuale significativa di casi il risultato sia errato?

La domanda che manca nelle riunioni

Quando si discute di AI in un’azienda, si parla quasi sempre di ciò che il sistema può fare. Si parla raramente di quale tipo di processo si intende automatizzare.

Eppure è la domanda che cambia tutto.

Un processo sostanzialmente deterministico (riconciliazione contabile, validazione della conformità normativa, routing delle richieste secondo regole fisse) ha un output verificabile, regole esplicite e nessuna ambiguità fondamentale. Un sistema classico lo gestisce in modo affidabile, a costi contenuti e verificabile. Introdurre l’AI generativa in quel processo aggiunge variabilità dove non ce n’è bisogno, costi di verifica che prima non esistevano e una maggiore complessità architetturale.

Un processo che richieda di classificare una richiesta scritta in linguaggio libero, riassumere documenti eterogenei e gestire una conversazione non strutturata con un cliente presenta un’ambiguità di fondo: è qui che il sistema AI offre un vantaggio reale che un sistema classico non può replicare.

La maggior parte dei processi aziendali reali è ibrida: una parte deterministica, una parte probabilistica. La risposta giusta in quei casi è un’architettura che usa ciascun tipo di tecnologia per la parte che le compete. È ciò che le organizzazioni tecnologicamente più mature stanno costruendo. Salesforce ha appena annunciato una ristrutturazione della propria piattaforma esattamente in questi termini: un nucleo deterministico su cui montare componenti di AI per le parti che richiedono intelligenza linguistica. La loro stessa documentazione tecnica recita: “Gli agenti AI sono probabilistici, non deterministici — non si comportano allo stesso modo ogni volta.”

Quella frase è una buona bussola.

Trenta secondi prima di partire

Il senso di questi commenti non è negare l’importanza degli investimenti in AI, bensì sostenere che non è ragionevole investire senza aver prima risposto a qualche domanda di fondo: com’è fatto il sistema? Dove funziona e dove no? Qual è il tipo di processo su cui lo applico? Quali sono i costi quando le cose vanno storte? Dal punto di vista comportamentale e di costume, assomiglia pericolosamente alla corsa al digitale terrestre.

Forse vale la pena rallentare 30 secondi, fermarsi e capire. E capire, in questo caso, ha un contenuto preciso: il processo che voglio automatizzare è deterministico o probabilistico? Richiede garanzie di correttezza o tollera la variabilità? Quanto è lunga la catena di passi? Cosa succede quando uno va storto? Se la risposta indica un processo deterministico, un sistema classico farà meglio il lavoro a costi inferiori. Se si indica un processo probabilistico, allora l’AI ha senso — ma l’architettura e i guardrail diventano la vera domanda.

Non è filosofia: è la checklist che separa un'implementazione sensata da un digitale terrestre con più zeri. Quella storia ebbe anche le sue cause di economia politica. Con l'AI, quella scusa non esiste.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Lo comprai quando uscì, nel 1988. Avrebbero dovuto essere sei lezioni, sei parole chiave per la letteratura del futuro: leggerezza, rapidità, esattezza, visibilità, molteplicità, coerenza. Cinque le scrisse; della sesta restò solo il titolo. Non arrivò mai a tenerle. Morì nell’85, tre anni prima che il libro vedesse la luce.

La prima lezione, la leggerezza, è quella che ho sempre trovato più bella. Calvino cerca in letteratura ciò che il peso del mondo tende a toglierle: la capacità di stare sulle cose senza affondare, di trattare la realtà con un tocco lieve senza smettere di vederla.

E poi, nel mezzo di questo ragionamento sulla leggerezza come valore letterario, compare il software:

“Il software non potrebbe esercitare i poteri della sua leggerezza se non mediante la pesantezza del hardware; ma è il software che comanda, che agisce sul mondo esterno e sulle macchine.”

Scritto nel 1985. Quando “software” era ancora una parola che quasi nessun lettore di letteratura avrebbe saputo definire.

Ho passato decenni a lavorare sul software, a insegnarlo, a pensarci, a discutere di ciò che lo rende difficile e di ciò che lo rende bello. Non ho mai trovato una sintesi più elegante di questa: la leggerezza che comanda, che agisce sul mondo, ma che ha bisogno della pesantezza per esistere.

Vale la pena rileggerlo. Lo farò.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Da un po’ di tempo uso Claude per aiutarmi nelle attività di ricerca e di scrittura. Per farlo, ho creato alcune skill, connessioni e procedure che mi piace condividere con voi, così da scambiarci esperienze e suggerimenti.

Base di conoscenza

Per scrivere qualsiasi cosa, sfrutto un corpus di documenti che ho accumulato in anni.

• Reader e Readwise raccolgono le fonti che leggo: articoli, podcast, passaggi di libri, tweet salvati e note personali (c’è un connettore MCP per collegare Reader/Readwise a Claude). È il mio sistema di lettura attiva — quello che leggo finisce lì, con i passaggi marcati/taggati e le annotazioni che ho lasciato nel tempo. Quando scrivo su un tema, cerco innanzitutto lì.

• Poi c’è l’archivio dei miei testi. Ho trasferito in una cartella strutturata circa seimila post scritti su Medium e prima ancora sul mio blog Wordpress dal 2005 a oggi — vent’anni di scrittura su digitale, innovazione, management, università, tecnologia. A questi si aggiunge l’archivio completo di tutto ciò che ho pubblicato su questo Substack. Li navigo per capire come ho affrontato un tema in passato, quali posizioni ho difeso, dove le mie opinioni sono cambiate. Inoltre, accedo ad articoli, brief ed altro materiale che ho prodotto nel tempo.

• Infine, documenti e presentazioni: archivi di slide, articoli e documenti creati in anni di lezioni, convegni, progetti con le imprese.

Contesto operativo

Sul fronte dei lavori in corso, ho organizzato tutto sfruttando le logiche di Claude e semplici cartelle nel file system. C’è un progetto per la gestione editoriale di questo Substack, con il tracker dei post, le bozze in lavorazione e le metriche storiche; uno per gli articoli accademici e professionali — quelli che scrivo per le riviste — ognuno con la propria struttura di sviluppo; e uno per il libro in corso di scrittura, con i capitoli, le note e la pipeline di redazione.

E poi le attività di supporto: il log giornaliero (che Claude mi genera automaticamente in base a ciò che abbiamo fatto), le note di riunione, i brief tematici che nascono durante la consulenza, gli studi e le ricerche formali prodotti per clienti o istituzioni. Sono materiali vivi che entrano nel processo di scrittura quando il tema lo richiede.

Pipeline di produzione

Per ogni lavoro che inizio — un post, un articolo per una rivista, un capitolo di un libro — comincio con una specifica scritta. La scrivo per me, non per lo strumento.

Per un post Substack, è un testo di pochi paragrafi: la tesi centrale, l’aggancio narrativo, la sequenza delle sezioni e le fonti che ho in mente. Per un articolo accademico è un file Markdown denominato contents.md: contiene la mappa degli argomenti principali, i dati da citare, il filo che collega le sezioni, le posizioni da difendere e quelle da smentire. Un artefatto vivo, che cambia man mano che il ragionamento si affina.

William Zinsser, in On Writing Well, osserva che la scrittura confusa è quasi sempre il sintomo di un pensiero confuso — non il contrario. La spec è l’operazione che impone chiarezza prima di aprire l’editor.

Quando penso di essere arrivato a una specifica ragionevolmente precisa, l’AI ha materiale su cui lavorare: può amplificarlo, cercare fonti, effettuare analisi controfattuali e fact-check. E io posso valutarne il contributo perché so qual è l’ipotesi che voglio esplorare appoggiandomi anche ai riferimenti e ai materiali selezionati.

Skill per ogni passaggio

Quel che ho imparato lavorando su tipi di testo molto diversi — un post meditativo da ottocento parole, un paper accademico da quattromila, un capitolo di libro — è che ogni formato richiede skill diverse. Non solo di lunghezza: di struttura dell’argomento, di tono, di rapporto con le fonti, di come si gestisce la revisione. Magari partendo dalle stesse idee di fondo, lo stesso contents.md.

Per questo ho costruito skill specializzate: una per i post argomentativi e meditativi di Substack, una per la rubrica musicale settimanale, una per quella dedicata ai libri, una per gli articoli accademici e professionali e una per i capitoli del libro, con la relativa pipeline di compilazione nel formato finale. Ognuna conosce le regole del proprio formato, il “mio” stile e i pattern da evitare. Infine, ho creato una skill per il fact-checking e un’altra per generare presentazioni in Markdown, che poi passo a Deckset, un’app che legge i file Markdown e produce slide semplici ma efficaci.

Il risultato è che posso passare da un post Substack a un articolo IEEE a un capitolo senza dovermi ogni volta riorientare — il contesto è già incorporato nello strumento.

Le idee vengono inserite in un sistema di gestione dei task (Todoist, connesso tramite MCP) con una descrizione minima. Quella nota è il punto di partenza della spec. La spec diventa bozza. La bozza passa alla revisione e al fact-check. Quando è pronta, va su Substack oppure si consolida nel documento di destinazione.

Uno strumento per stimolare il pensiero

Quando ho una tesi, chiedo di individuare i punti deboli, le obiezioni che un lettore critico potrebbe sollevare e le evidenze che potrebbero smentirla. Quando scrivo testi lunghi, uso lo strumento per generare bozze a partire dal filo logico che gli ho fornito, per verificare che le affermazioni fatte in un punto non contraddicano quelle di un altro, che la terminologia sia coerente e che la chiusura risponda all’aggancio iniziale. Quando pubblico dati o percentuali, procedo a una verifica sistematica delle fonti primarie.

Per chi lavora su temi complessi — ricerca, innovazione, università, trasformazione digitale — la qualità del pensiero è il risultato chiave. Avere un sistema che svolge i compiti di supporto libera spazio per lavorare sulla qualità del pensiero. La struttura e il metodo di lavoro sono ciò che rende la creatività affidabile.

P.S.: Ho disabilitato l’uso dei miei dati per l’addestramento e uso una licenza che attesta la proprietà di quanto prodotto.

Questo post è stato scritto con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Honey from a winter stone è uscito nel 2025. È più di un album di jazz. C’è qualcosa di cameristico, qualcosa di elettronico, una voce che improvvisa senza sembrare fuori posto. Quello che mi ha colpito è l’eclettismo — la capacità di stare in generi diversi al tempo stesso, con naturalezza. Non capita spesso.

Il titolo, Miele da una pietra d’inverno, esprime bellezza da dove non te la aspetti.

Da sentire anche il suo ultimo album con Bill Frisell e Herlin Riley.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Rispondo interpretando la parola “sviluppare” in senso generale e non limitata alla sola “produzione di software”. Credo che il tema sollevato da Gianluca richieda implicitamente tale generalizzazione.

Il mondo di Karpathy (e i suoi limiti)

Nel 2017, Andrej Karpathy pubblicò un saggio intitolato “Software 2.0”: le reti neurali stanno diventando un nuovo modo di scrivere software. Invece di istruire esplicitamente la macchina con regole e condizioni, l’alleni sui dati. Il vibe coding — termine che Karpathy ha contribuito a diffondere — porta il paradigma un passo oltre: non alleni più il modello, gli parli. Descrivi in linguaggio naturale: il modello genera il codice; tu supervisioni e iteri. Nell’orizzonte di Karpathy, gli agenti scrivono, testano e deployano in autonomia mentre l’umano orchestra dall’esterno.

In questo mondo — ricercatori AI, startup tech-first, sviluppatori di strumenti per sviluppatori — la pressione competitiva per l’adozione dell’AI è reale perché la velocità è un fattore determinante. Ma vale la pena fermarsi sui dati. Uno studio del METR, pubblicato a luglio 2025, ha misurato l'effetto degli strumenti AI su un campione di sviluppatori esperti che lavoravano sui propri repository open source: mentre questi credevano di lavorare il 20% più velocemente, i test oggettivi mostravano che erano il 19% più lenti. I dati di GitClear mostrano che l'adozione dell'AI ha più che raddoppiato il tasso di riscrittura del codice entro due settimane rispetto alla baseline del 2021, con un calo marcato in diverse misure di qualità — dal riuso del codice alla proliferazione dei duplicati. E chi ha provato ad applicare il vibe coding a qualcosa di più ambizioso di un prototipo conosce bene il problema che Ben Yoskovitz ha sintetizzato in un titolo: “Vibe Coding Without System Design is a Trap”. Quindi la velocità è importante, ma la persona ha un ruolo centrale nel garantire la qualità.

La risposta dipende dal settore, non dalla tecnologia

Peraltro, anche solo restando nel perimetro dello sviluppo software, il panorama è in realtà eterogeneo. Il software di sistema e gli strumenti per applicazioni di ricerca — compilatori, runtime, librerie di ML, firmware — sono il territorio naturale del paradigma Karpathy: alta densità di competenze tecniche, importanza della velocità.

Le applicazioni di business sono un pianeta a parte: ERP, CRM, sistemi gestionali, supply chain. Logiche di business stratificate in decenni di modifiche, regole fiscali che cambiano ogni anno, integrazioni con sistemi che nessuno ricorda più come funzionano. Qui, il codice generato da un LLM può essere sintatticamente corretto ma semanticamente sbagliato in modi che si manifestano solo mesi dopo, in produzione, durante un audit. E, in molti casi, il problema non è nemmeno scrivere codice, ma configurare e personalizzare le piattaforme. La criticità sta nel raccogliere e analizzare le informazioni necessarie per guidare questi processi.

Quando poi si esce dallo sviluppo software, la situazione cambia ancora più radicalmente. Il lavoro professionale — avvocati, medici, commercialisti — ha una relazione con la precisione e la responsabilità che non è negoziabile: un'allucinazione di un LLM in una parcella fiscale o in una cartella clinica non è un bug da correggere, ma un danno.

In ciascuno di questi settori, la domanda di Gianluca ha una risposta diversa. In alcuni casi la pressione per l’adozione è già intensa. In altri casi, i vincoli esistenti rallentano l’integrazione o ne limitano l’impatto non per inerzia culturale, ma per ragioni strutturali e di responsabilità del tutto legittime.

La risposta a una domanda che cambia forma

Allora: sarà antieconomico “sviluppare” senza AI?

Nel mondo di Karpathy — software di ricerca, strumenti per sviluppatori, startup tecnologiche — la pressione esiste già ed è destinata ad aumentare. Il differenziale di velocità tra chi usa strumenti AI e chi non li usa è reale in certi contesti, anche se più contenuto di quanto i titoli suggeriscano e da mediare tenendo conto della qualità finale. Chi sviluppa in quel territorio e ignora gli strumenti disponibili si troverà a giustificare tempi e costi che i suoi interlocutori non capiranno più.

Nelle applicazioni di business la risposta cambia forma. L’AI entra come strumento che valorizza il lavoro di chi già capisce il sistema: nell’analisi dei requisiti, nella documentazione, nel testing, nel refactoring guidato di codice legacy. Capire il sistema — la storia delle scelte fatte, i compromessi accettati, le dipendenze invisibili — rimane un lavoro umano che, ad oggi, nessun LLM esegue autonomamente per osmosi. Peraltro, sono fattori che riguardano tutti gli sviluppi e, quindi, l’osservazione ha riflessi anche sugli altri settori.

La consulenza vive di giudizio, lettura del contesto e fiducia costruita nel tempo: l'AI può accelerare la raccolta e l'analisi delle informazioni, ma il valore che il cliente paga non è l'informazione, bensì l'interpretazione di chi conosce la sua storia.

Non ho dati per dimostrarlo — ho un argomento strutturale ed epistemico, con tutti i limiti e i vantaggi che questo tipo di argomentazione comporta.

Coda

La domanda di Gianluca merita una risposta onesta: sì, in certi contesti sviluppare senza AI credo che diventerà antieconomico. Ma quei contesti non sono il mondo — sono una parte di esso, per ora la più visibile nel dibattito, perché è la parte che lo produce. E le dinamiche non sono così chiare e nette da permettere affermazioni univoche che chiudano ogni discorso.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Fonti:

• Karpathy, “Software 2.0”, Medium, 2017.

• Karpathy, “Power to the people: How LLMs flip the script on technology diffusion”, apr 2025.

• METR/arXiv, “Measuring the Impact of Early–2025 AI on Experienced Open-Source Developer Productivity”, lug 2025.

• GitClear, “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality”, 2022–2025.

• Yoskovitz, “Vibe Coding Without System Design is a Trap”, Focused Chaos, gen 2026.

• Post abassavoce.it: “Perché non possiamo lasciare che le macchine pensino al nostro posto”, gen 2026.

• Post abassavoce.it: “Claude Code e lo sviluppo di software”, apr 2026.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Qualche giorno fa ho letto un articolo di Vivek Trivedy, product lead di LangChain, intitolato “The Anatomy of an Agent Harness.” È un pezzo tecnico, scritto per chi costruisce agenti AI in produzione, ma la questione che solleva è più generale: cosa serve, oltre al modello, per fare qualcosa di utile con un LLM?

L’argomentazione di Trivedy ha una struttura precisa e mi ha convinto a scrivere questo post.

L’equazione

Il punto di partenza è un’equazione semplice: Agent = Model + Harness. Il modello è la componente probabilistica — il LLM che genera testo. L’harness è tutto il resto: l’infrastruttura che avvolge il modello e lo rende capace di svolgere un’attività utile in un contesto reale. Trivedy elenca i componenti dell’harness in modo sistematico: system prompt, tool e MCP (Model Context Protocol, connettori verso servizi esterni), logica di orchestrazione, gestione della memoria, filesystem, sandbox di esecuzione, meccanismi di verifica, hook e middleware.

Ogni elemento di questa lista ha un corrispondente tra i concetti dell’ingegneria del software classica.

I system prompt sono una forma di specifica del comportamento: definiscono il contratto d’uso del modello in un contesto dato, con una struttura che richiama le precondizioni e i requisiti di interfaccia. Gli strumenti e gli MCP sono interfacce verso servizi esterni — la stessa architettura a componenti e connettori che SE studia da decenni. La logica di orchestrazione rimanda alla gestione del flusso e dello stato delle operazioni: workflow management e process modeling. La memoria è la gestione del contesto tra le sessioni — persistent state management. E chi prova a farlo in modo serio scopre rapidamente che un file JSON o Markdown non basta: servono database relazionali, indici, query efficienti, garanzie di coerenza e di resilienza. Le tecnologie sviluppate in decenni di ingegneria dei dati per gestire grandi quantità di informazioni in modo affidabile tornano a essere esattamente ciò di cui si ha bisogno. I meccanismi di verifica sono il test e la validazione, applicati a un componente con output non deterministico. Hook e middleware sono i pattern classici dell’architettura a livelli.

Considerazioni analoghe provengono da voci diverse del panorama tecnico. Birgitta Böckeler, Distinguished Engineer presso Thoughtworks, ha pubblicato su martinfowler.com un articolo intitolato “Harness engineering for coding agent users” che usa la stessa equazione e inquadra l’harness engineering come una disciplina emergente. Anthropic, nel suo documento “Building Effective Agents,” descrive gli stessi componenti infrastrutturali come prerequisiti per qualsiasi agente che funzioni in produzione.

Cosa non è cambiato

Nel 2023, quando i grandi modelli linguistici di nuova generazione sono diventati accessibili su larga scala, si è sottovalutato sistematicamente l'impatto sulla complessità dell'architettura. La tesi prevalente era che il modello — capendo il linguaggio naturale — avrebbe assorbito la complessità sistemica: non devi più progettare l'architettura, gestire lo stato né integrare i componenti. Basta descrivere l'obiettivo.

Due anni dopo, chiunque abbia provato a costruire un agente in produzione sa com’è andata. Per task semplici e isolati, la tesi regge. Per qualsiasi cosa più articolata — flussi multi-step, integrazione con sistemi esterni, coerenza tra le sessioni, gestione degli errori — la complessità sistemica riemerge. E quando ritorna, porta con sé le stesse domande che l’ingegneria del software ha sempre affrontato: come progetti il sistema, come gestisci lo stato, come verifichi che funzioni, come lo mantieni nel tempo.

La complessità si è spostata: dai moduli ai prompt, dalle interfacce ai tool, dai test unitari agli evaluation set. Il problema rimane concettualmente e sostanzialmente lo stesso — costruire sistemi che si comportano come previsto in condizioni che non avevi previsto — e richiede la stessa disciplina.

Le domande che sono nuove

Questo non significa che l’AI non ponga nuovi problemi. Ne pone due che l’ingegneria del software classica non ha ancora risolto in modo soddisfacente.

La prima riguarda la specifica. Come si specifica una componente il cui comportamento è probabilistico? Le triple di Hoare — {precondizione} operazione {postcondizione} — descrivono contratti deterministici: dato questo input in queste condizioni, otterrai questo output. Un LLM produce distribuzioni di output, non valori singoli. Puoi specificare che il sistema “di solito risponde bene” o che “supera l’80% dei casi di test”, ma la struttura formale sottostante è diversa. Esistono lavori sulla logica probabilistica di Hoare e sui contratti stocastici, ma il problema rimane aperto sul piano operativo: come si scrive un contratto per un componente non deterministico che sia utile a chi lo integra?

La seconda riguarda il test. Come si testa un componente il cui spazio di input è illimitato? I test tradizionali ragionano per casi: l’input A produce l’output B. Con un LLM, lo spazio degli input è infinito e l’output varia. Gli evaluation harness che si usano oggi — set di prompt campionati, giudici LLM, metriche aggregate — sono strumenti empirici più che metodologie formali. Funzionano, ma non offrono le garanzie che un test unitario classico offre nel proprio ambito. Questa è una lacuna metodologica reale, non una limitazione pratica passeggera.

Va detto che problemi analoghi sono stati affrontati in altri domini — sistemi di controllo stocastici, simulazioni — ma senza produrre soluzioni trasferibili alla pratica ingegneristica ordinaria. La novità non è nel problema in sé, ma nella sua scala e nella sua pervasività.

Il cerchio che si chiude

Torno all’articolo di Trivedy. Quello che ha scritto è, in effetti, lo schema di un manuale d’ingegneria per questo tipo di sistemi. Ogni sezione dell’harness che descrive è una risposta a un problema che SE ha già nominato, qualificato e studiato: specifica, integrazione, stato, verifica, manutenzione. Le risposte cambiano perché il componente centrale — il modello — è diverso da qualsiasi componente che SE abbia mai gestito. Ma le domande sono le stesse.

Leggendolo, mi è tornata in mente una conversazione del 1996 con un collega. Stavamo discutendo di architetture software, e io sostenevo che stessimo rifacendo, a livello architetturale, le stesse considerazioni metodologiche che David Parnas aveva formulato sulla modularizzazione negli anni Settanta. “Stiamo girando in tondo e pestando l’acqua nel mortaio”, dissi.

Aveva ragione allora e vale ancora oggi.

L'harness che Trivedy descrive è un giro della spirale a un livello di complessità più elevato, non una ripetizione di ciò che SE ha già fatto: componenti probabilistici, spazi di input illimitati, comportamenti che non puoi enumerare in anticipo. Le stesse domande di trent’anni fa — come specifichi, come testi, come mantieni — tornano in una forma che richiede risposte nuove.

Quello era il problema dell’ingegneria del software quando ho iniziato. Lo è ancora, solo più in alto sulla spirale.

• Fonti: Vivek Trivedy, “The Anatomy of an Agent Harness,” LangChain blog

• Birgitta Böckeler, “Harness engineering for coding agent users,” martinfowler.com

• Anthropic, “Building Effective Agents,” anthropic.com

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Ho cominciato a leggerlo. Sono a metà e probabilmente tornerò a parlarne. Ma già il titolo ha fatto il suo lavoro: mi ha costretto a fermarmi su una domanda che di solito diamo per scontata.

What do you really stand for?

È una domanda che vale certamente sia per le persone sia per le organizzazioni. E, nella mia esperienza, è anche una di quelle domande a cui è più difficile rispondere con onestà perché spesso non vogliamo ammettere la distanza tra ciò che diciamo e ciò che facciamo.

Il libro è uno strumento, uno stimolo a avviare una riflessione. La domanda, però, possiamo farcela anche senza, con schiettezza e onestà intellettuale.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

A me capita. E ogni volta segue una sequenza prevedibile: prima la sorpresa, come se non riuscissi ancora ad accettare quanto è accaduto; poi l’irritazione, una forma di risposta immediata, quasi difensiva; poi la delusione — quella più lenta, più profonda, quella che rimane.

Il “sì che in realtà vuol dire no” è un’immagine che descrive un comportamento diverso da quello che provoca errori o cambiamenti di opinione. Parlo di qualcos’altro, di una distanza tra le parole e i fatti che sembra essere diventata normale, tollerata, quasi invisibile. Una distanza che, col tempo, erode la fiducia, la possibilità di appoggiarti davvero a chi ti sta vicino — in una relazione, in un progetto, in un’amicizia.

Quando mi accorgo di essere caduto io stesso in questo errore, sento un malessere che non riesco a scacciare: devo trovare un modo per rimediare.

Pensando a questo, mi sono tornate in mente alcune righe del Vangelo di Matteo.

La parabola

Matteo, capitolo 21, versetti 28–31. Gesù sta parlando nel Tempio, davanti ai capi dei sacerdoti che gli hanno appena chiesto con quale autorità agisce. La risposta è, come spesso accade, una domanda — e una storia brevissima.

Un uomo aveva due figli. Rivoltosi al primo disse: “Figlio, và oggi a lavorare nella vigna”. Ed egli rispose: “Non ne ho voglia”. Ma poi si pentì e vi andò. Rivoltosi al secondo disse lo stesso. Ed egli rispose: “Sì, padre”. Ma non vi andò. Chi dei due ha compiuto la volontà del padre?

I presenti rispondono senza esitare: il primo. Quello che aveva detto no.

È una di quelle domande la cui risposta sembra ovvia — finché non ti fermi un secondo per sentire cosa stai davvero dicendo: il figlio “giusto” è quello scortese, quello che ha risposto male, quello che ha deluso il padre nell’immediato. Non quello compiacente, non quello che ha detto la cosa giusta al momento giusto.

Il “sì” del secondo figlio non era costato nulla. Era la risposta più semplice, quella che chiude la conversazione senza conflitti, che lascia il padre soddisfatto per il momento, quella che “crea il clima positivo”. Il “no” del primo era scomodo, forse doloroso, certamente sincero. Era reale. E dopo il no — qualcosa aveva ceduto o maturato: il figlio cambiò idea ed andò.

Gesù non spiega, lascia che la storia faccia il suo lavoro.

Il “sì” che non costa niente

Il secondo figlio non è un bugiardo patologico. Non è nemmeno cattivo. È qualcuno che gestisce il momento. Dire “sì, padre” è la risposta più semplice: chiude la conversazione, evita il conflitto, lascia tutti soddisfatti, per adesso. Il problema — il lavoro nella vigna — viene rimandato, diluito, dimenticato. Non c’è un momento preciso in cui decide di non andarci: semplicemente, non ci va. La promessa era il fine, non il mezzo.

Questo schema lo conosciamo. Lo vediamo nelle relazioni più prossime: chi dice “sì, certo, ci penso” e poi non ci pensa; chi promette di esserci e poi non si fa trovare; chi, in faccia, è d’accordo con tutto e poi agisce come se la conversazione non fosse mai avvenuta. Non è necessariamente malafede. Spesso è qualcosa di più sottile: l’abitudine a dare la risposta che l’altro si aspetta, perché è più comoda, perché evita attriti, perché, nel momento presente, tutto fila liscio.

Ho scritto di recente dei sepolcri imbiancati — dell’ipocrisia come facciata pubblica, della distanza tra ciò che si mostra e ciò che si è davvero. Questa parabola tocca qualcosa di più vicino al nostro io: non la grande ipocrisia delle istituzioni o della vita pubblica, ma quella silenziosa dei rapporti quotidiani. Non il politico che proclama valori che non pratica, ma il figlio, l’amico, il collega: siamo noi.

Il figlio scomodo

Il primo figlio è il personaggio scomodo della storia. Dice no al padre, in faccia, senza ammorbidire. Non è una risposta gradevole. Se fossimo lì, probabilmente lo troveremmo maleducato, forse ingrato.

Eppure è lui che va nella vigna.

Qualcosa — il racconto non dice che cosa, e forse è questo il punto — lo spinge a rivedere la sua risposta. Non si è impegnato con le parole: si è impegnato con i fatti. E quella forma di pentimento silenzioso, quel tornare sui propri passi senza che nessuno lo sappia, ha più peso di tutti i “sì” del fratello messi insieme.

C’è una parola per questa qualità: schiettezza. Non è semplicemente l’opposto dell’ipocrisia. È una forma attiva di rispetto — verso chi ti sta davanti e verso te stesso. Chi è schietto non dice la cosa giusta per compiacere: dice quello che pensa, anche quando è scomodo, anche quando delude nell’immediato. E poi fa quello che ha detto — oppure la ridiscute apertamente, senza reticenze e in modo coerente. Va nella vigna.

Nelle relazioni che contano — quelle in cui ci si appoggia davvero, in cui si chiede qualcosa di importante — la schiettezza è il fondamento. Preferiamo istintivamente chi, nell'immediato, ci dice sempre di sì: è più piacevole, meno faticoso. Ma chi ci dice sì e non fa è una presenza che, col tempo, si svuota. Chi ci dice no, o ci dice “non sono sicuro”, o “ci devo pensare” — e poi mantiene — è quello su cui si costruisce qualcosa di reale.

Il primo figlio è scomodo. Ma è affidabile. E alla fine, è quello che il padre cercava.

Quello che succede nella vigna

Il padre della parabola non chiede ai figli di essere perfetti. Non chiede che siano d’accordo, che non abbiano resistenze, che non attraversino momenti di rifiuto. Chiede una cosa concreta: che qualcuno vada nella vigna.

Non è deluso da chi ha detto di no. È tradito da chi ha detto di sì.

Quella sequenza che descrivevo all’inizio — sorpresa, irritazione, delusione — non nasce dall’aspettarsi troppo dalle persone. Nasce da qualcosa di più semplice: dalla distanza tra una parola data e ciò che succede dopo. È quella distanza che erode. Non il no detto chiaramente, non il cambiamento di idea comunicato apertamente — ma il sì che non diventa mai niente.

La fiducia nelle relazioni non si misura dalle intenzioni dichiarate. Si misura su ciò che succede nella vigna — su chi ci va davvero, anche dopo aver detto di non voler andarci.

Il padre lo sa. In fondo, lo sappiamo anche noi.

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

• Frank Zappa – chitarra, voce

• George Duke – tastiere, voce

• Napoleon Murphy Brock – sassofono tenore, voce

• Tom Fowler – basso

• Bruce Fowler – trombone

• Ruth Underwood – percussioni

• Ralph Humphrey e Chester Thompson – batteria

L’album contiene il medley “Echidna’s Arf (Of You)” / “Don’t You Ever Wash That Thing?”, che è diventato uno dei momenti più iconici del live di Zappa. La sinergia tra i due batteristi Humphrey e Thompson, insieme alle percussioni virtuosistiche di Ruth Underwood, creò una sezione ritmica di rara densità e complessità.

Certamente, un riferimento di quegli anni rimane anche Zappa in New York, con tanti pezzi unici e un altro gruppo di musicisti incredibili:

• Frank Zappa – chitarra solista, voce, direttore

• Ray White – chitarra ritmica, voce

• Eddie Jobson – tastiere, violino, voce

• Patrick O’Hearn – basso, voce

• Terry Bozzio – batteria, voce

• Ruth Underwood – percussioni, sintetizzatore

• Dave Samuels – timpani, vibrafono

• Randy Brecker – tromba

• Mike Brecker – sax tenore, flauto

• Lou Marini – sax alto, flauto

• Ronnie Cuber – sax baritono, clarinetto

• Tom Malone – trombone, tromba, ottavino

• Don Pardo – “narrazione sofisticata”

E sono solo due dei molti grandi album nella discografia di Zappa…

Disclaimer: questo post è stato realizzato con il supporto di GenAi.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

In The Seven Lamps of Architecture, John Ruskin scrisse una frase che non è invecchiata:

When we build, let us think that we build forever. Let it not be for present delight, nor present use alone; let it be such work as our descendants will thank us for.

Qualche giorno fa ho letto un articolo di James Lucas che parte da questa citazione per ragionare sull’architettura romana.

Beauty is truth

What We Build Reveals Who We Are

In The Seven Lamps of Architecture, John Ruskin wrote…

Read more

a month ago · 103 likes · 10 comments · James Lucas

La tesi è semplice e diretta: ciò che una civiltà costruisce è la cosa più onesta che abbia mai detto su se stessa. I Romani costruivano pensando all’eternità — non per retorica, ma per scelta tecnica e filosofica. Il calcestruzzo del Pantheon contiene piccoli depositi di calce viva che, quando si forma una crepa, vengono fratturati da essa: l’acqua che penetra reagisce con i frammenti esposti, creando una soluzione ricca di calcio che si ricristallizza sigillando la frattura dall’interno. Il materiale si autoripara. È stato progettato per farlo. Il cemento moderno comincia a degradarsi nel giro di decenni; il calcestruzzo romano diventa più resistente con il tempo.

Lucas chiude con una frase che mi è rimasta in testa: “Meaning, it turns out, is the most durable material of all.”

Ho continuato a pensarci, non in riferimento all’architettura, ma alla nostra vita quotidiana e professionale.

Quello che costruiamo dice chi siamo

Ogni manager lascia qualcosa dietro di sé. Non nel senso celebrativo della legacy — quella parola che si usa nei discorsi di commiato e poi svanisce insieme ai buffet aziendali. Nel senso concreto e materiale: quando esci da un’organizzazione, cos’è rimasto come tuo contributo? Le persone che hai guidato sono più capaci di quando le hai incontrate, o sono esattamente dove le hai lasciate? La struttura che hai gestito funziona meglio di prima o nulla è cambiato o, peggio, si sono fatti passi indietro? I risultati sono solidi o basati su espedienti per nascondere problemi strutturali? Sono domande che raramente ci poniamo esplicitamente. Ma le risposte sono lì, leggibili da chiunque venga dopo di noi, purché sia dotato di senso critico e di onestà intellettuale.

Da anni uso mentalmente una semplice griglia per leggere ciò che i manager lasciano dietro di sé. Uso tre categorie: chi crea valore, chi lo estrae, chi lo distrugge.

Creare valore

Creare valore significa costruire qualcosa che regge e si sviluppa anche dopo di te.

Non è una questione di grandezza. Non si tratta di fondare aziende o di trasformare mercati — anche se può includere entrambe le attività. Si tratta di un orientamento verso il tempo lungo, verso ciò che continua quando non ci sei più. È quello che Simon Sinek chiama “gioco infinito” — non ottimizzare per vincere la partita in corso, ma costruire le condizioni perché il gioco possa continuare, anche senza di te, anche dopo di te. Un manager che crea valore lascia un’organizzazione più robusta rispetto a quella che ha ereditato. Lascia persone cresciute, capaci di fare cose che prima non sapevano fare. Lascia processi che funzionano anche sotto pressione. Lascia una cultura che sa autoripararsi — come il calcestruzzo romano — senza bisogno di interventi continui dall’alto.

Questo tipo di costruzione è quasi sempre invisibile nel suo accadere. Non genera titoli, non produce annunci, non si misura in trimestri. Si vede solo retrospettivamente, quando chi viene dopo trova qualcosa di solido su cui appoggiarsi — o, al contrario, trova macerie e si chiede come sia stato possibile giungere a quella situazione.

Chi crea valore non è un eroe o un genio, ma semplicemente un professionista serio, testimone di un modo di stare nel ruolo che tiene conto del fatto che esso, prima o poi, avrà un termine.

Estrarre valore

Estrarre valore significa lasciare dietro di te meno di quanto hai trovato.

Estrarre valore — nel senso in cui uso il termine — non è la stessa cosa della giusta remunerazione o della legittima distribuzione delle risorse. È qualcosa di più specifico: usare l’organizzazione come fonte da sfruttare, privilegiando il proprio tornaconto o la propria carriera rispetto alla salute della struttura. È insipienza, a volte. È egoismo, più spesso.

Un segnale di questo atteggiamento è quando una persona vive la permanenza in un ruolo come strumento per il passaggio successivo: la promozione, l’incarico più importante, la prossima opportunità. Invece di svolgere bene il lavoro attuale, sfrutta il ruolo per cercare quello futuro.

Le tracce di questo modo di stare nel ruolo possono essere visibili o invisibili. A volte in modo evidente: risorse finanziarie svuotate, persone chiave che se ne vanno, strutture indebolite. A volte, in modo meno visibile, quello che resta non è rotto, ma è fragile — un’organizzazione che funziona finché qualcosa non la mette alla prova.

Distruggere valore

Distruggere valore significa lasciare macerie invece di fondamenta.

La distruzione di valore viene raramente dalla malevolenza — i casi di frode deliberata esistono, ma costituiscono una categoria a sé. Viene dalla miopia, dall'incapacità di vedere le conseguenze a lungo termine delle proprie scelte, dall'egocentrismo sordo, dall'insipienza, dall'assenza di competenze, dagli incentivi sbagliati, dalla furbizia stupida che mira a risultati a breve con costi trasferiti nel futuro. Viene dall'incapacità di distinguere tra la propria permanenza nel ruolo e la salute dell'organizzazione — una confusione che, se protratta nel tempo, porta le due cose a divergere fino al punto di rottura.

Lucas descrive i costruttori moderni che hanno realizzato edifici brutti e inospitali non perché volessero farlo, ma perché operavano all'interno di un sistema che premiava altro. La bruttezza non era un obiettivo: era una conseguenza. Allo stesso modo, un manager che distrugge valore difficilmente si percepisce come tale. Pensa di essere sotto pressione, costretto dalle circostanze, fedele agli obiettivi assegnatigli.

La domanda che conta

Detto questo, ho una convinzione: il problema principale non è riconoscere il valore del processo di creazione. Tutti lo riconoscono, almeno in astratto. Nei convegni, nei libri di management, nelle interviste ai CEO, il linguaggio della costruzione è onnipresente. Si parla di cultura aziendale, di sviluppo delle persone, di sostenibilità, di impatto di lungo periodo.

Il problema è sviluppare quell’etica del lavoro e quella professionalità per cui alle parole seguono i fatti: “walk your talk”, direbbero gli anglosassoni.

Quando i cicli di valutazione si accorciano, quando la pressione è sul trimestre, quando la carriera avanza più velocemente con risultati visibili nel breve che con investimenti i cui frutti matureranno quando sarai già altrove — costruire richiede una scelta attiva, consapevole e spesso controcorrente.

La maggior parte dei manager non sceglie cinicamente di estrarre né tantomeno di distruggere: si adatta, opera dentro i vincoli che trova, ottimizza per le metriche che vengono misurate, costruisce dove può e lascia andare dove la pressione è troppa. Il risultato, aggregato su molte persone e molte organizzazioni, è un sistema che genera meno di quanto potrebbe — non perché qualcuno abbia deciso che fosse meglio così, ma perché nessuno ha attivamente deciso il contrario.

La domanda che mi sembra utile fare — a se stessi, più che agli altri — non è che tipo di manager sei, ma in quale sistema operi e quanto ne sei consapevole? L'autoconsapevolezza non risolve i vincoli strutturali, ma è il prerequisito per non scambiarli per leggi naturali. Dopo viene la scelta — e quella scelta include anche la responsabilità di mettere in discussione le strutture in cui si opera, non solo di adattarsi ad esse.

Cosa resta

Torno a Ruskin e a Lucas.

“What a civilization builds is the most honest thing it ever says about itself.”

Vale per le civiltà. Vale anche per chi guida un’organizzazione, anche piccola, anche per un periodo limitato. Quello che costruiamo — o non costruiamo — è la cosa più onesta che diciamo su come abbiamo pensato il nostro ruolo, su quale orizzonte temporale abbiamo tenuto in mente, su cosa abbiamo considerato importante quando nessuno ci guardava.

Il Pantheon è ancora in piedi dopo duemila anni. Boston City Hall — inaugurato nel 1969, demolito di fatto nella coscienza collettiva molto prima — è diventato il simbolo di ciò che succede quando si costruisce senza pensare a chi dovrà viverci dentro.

La differenza non era solo nel carattere dei costruttori. Era anche nel sistema che li circondava — nelle aspettative, negli incentivi, nei criteri con cui venivano giudicati. Questo non assolve l'individuo. Ma ricorda che la scelta di costruire bene include anche quella di contribuire a sistemi che rendano possibile farlo.

Quando usciamo da un’organizzazione, lasciamo qualcosa. La domanda non è se lasciamo o meno una traccia — quella è inevitabile. La domanda è di che tipo?

Disclaimer: questo post è stato realizzato con il supporto di Claude.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it