I modelli di GenAI sarebbero una commodity perché, in sistemi come Cursor, sono intercambiabili: posso decidere quali usare.

Se accettassi che i modelli di GenAI siano commodity perché Cursor mi permette di scegliere quello che voglio, allora dovrei anche dire che una concessionaria di auto di lusso che mi permette di scegliere tra diversi brand (Lamborghini, Ferrari, Aston Martin, Bentley, …) vende commodity: ovviamente quelle auto non sono commodity.

Si dirà: “No, quelli sono beni di lusso, costano tanto. Le commodity costano poco.” Lascio a Don Ameche e Ralph Bellamy, in Una poltrona per due, spiegare che l’oro è una commodity. I fratelli Duke sono “commodities brokers”.

Quindi il problema non è il costo, tema che avevo discusso nei miei post precedenti (qui e qui).

Si dirà, ma queste su AI come commodity sono affermazioni fatte sui social, non è quello che dice chi ne capisce. Beh, non è così. In un recente intervento presso Assolombarda, Luciano Floridi usa la stessa parola: “l’intelligenza artificiale sta diventando anche una commodity, come si dice, costa sempre meno ed è sempre più diffusa […] il giorno in cui le AI saranno letteralmente come l’elettricità, la differenza non sarà chi sarà a gestirla, ma che cosa ci faremo, come, quando, con quale regolamentazione”.

Ma nello stesso passaggio aggiunge che “il vero divario sarà chi avrà la qualità dei dati migliori, chi avrà le competenze umane migliori, chi avrà la regolamentazione migliore”. Ed è qui la contraddizione: se l’AI fosse davvero una commodity, le competenze umane non sarebbero il discrimine. Una commodity si usa senza doverla saper gestire. Floridi la chiama commodity e, nella stessa frase, ammette ciò che nessuna commodity richiede.

Nota: la trascrizione di Assolombarda nel post su Linkedin contiene un errore. Floridi non dice “chi saprà gestirla o meno”, ma “chi sarà a gestirla o meno”.

Ho provato a spiegarlo nei miei due post. Ma non fidatevi di me e leggete questo articolo sulla home page del Wall Street Journal.

I manager americani sono stanchi di spendere soldi in modelli ipercostosi e si sono accorti che, per molti compiti, bastano modelli più semplici. Lo dice Mike Saeks, field CTO proprio di Cursor:

The most powerful and expensive AI models aren’t necessary for relatively mundane tasks.

“It’s like driving a Lamborghini to go to the grocery store to pick up milk when that was designed to be raced around a track”.

Ma quindi sono diversi! Il sito di Cursor consente di scegliere i modelli in base a diverse proprietà: “cost, intelligence, and balance”. Del resto lo dice il prodotto stesso: un router che “sceglie il modello giusto per ogni compito” presuppone che i modelli siano diversi. Per l’energia elettrica nessuno sente il bisogno di usarne uno.

Non solo: come dicevo nel post precedente, ogni modello, oltre a essere più o meno potente, ha un addestramento che lo rende più o meno adatto a svolgere specifiche attività. Inoltre è condizionato in modo diverso. Vi fidate di una valutazione d'investimento affidata a Grok, che ha mostrato di avere bias chiari in ambito geopolitico?

Dire che un bene è una commodity ha un impatto enorme sulle scelte manageriali e politiche. Se l’AI è una commodity, se basta usarla come l’elettricità, perché guardare alla sua qualità e alle sue caratteristiche? Basta prendere quella più economica. Costano meno Grok, che fa certe affermazioni sul genocidio dei bianchi in Sudafrica, o i modelli cinesi basati sui “core socialist values”? Non importa, prendiamo quelli. Una commodity si compra, si monta e si usa, qual è il problema? Se è gestita negli USA, che dalla mattina alla sera possono decidere di chiudere l’accesso ad un modello, si passa a quelli cinesi… o no?

Trattarla come una commodity è una decisione strategica travestita da constatazione tecnica. No, l'AI non è una commodity, né i modelli lo sono. Prima lo capiamo, meno errori faremo.

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 18 luglio scorso, Alex Imas (economista comportamentale della University of Chicago Booth, dallo scorso maggio Director of AGI Economics a Google DeepMind) ha scritto su X una tesi che merita di essere discussa [1]:

AGI will very likely be a commodity. This is not a value judgement, it’s just the outcome of an economically-valuable product + competitive markets. Implicitly people see this coming and are leaning into it, hence the big push from all the labs to go vertical.

A few things can prevent this: 1) regulation or 2) a moat, so it’s definitely not a certainty. But absent that, this is where things are going.

Nel thread la tesi è stata contestata subito. David Rein (@idavidrein) — il ricercatore che ha creato il benchmark GPQA, uno di quelli che cito più avanti per mostrare che nessun modello vince ovunque — ha risposto con l’obiezione di merito più netta: “Commodities form when you can’t innovate anymore, and it seems very unlikely we’ll hit capability ceilings anytime soon, so I’d bet against this” [2]. Imas ha ribattuto che i due modelli di testa già oggi competono sul prezzo e che le imprese passano di continuo dall’uno all’altro. E, in coda, tagliente, Pedro Tremacoldi-Rossi — financial economist presso Cornerstone Research, che studia i mercati delle commodity — ha liquidato la definizione: “very strange notion of commodity” [3].

La settimana scorsa ho argomentato che chiamare l’AI commodity è una categoria sbagliata: i grandi modelli linguistici non soddisfano nessuna delle proprietà economiche del bene commodity: fungibilità, prezzo per unità di valore, basso costo di migrazione, stabilità nel tempo, basse barriere d’uso. Il post di Imas e l’obiezione di Tremacoldi-Rossi mi hanno portato a chiedermi se, alla luce di ciò che i dati mostrano oggi sul mercato dei modelli di base, quella conclusione regga.

Una prima reazione all’affermazione di Imas potrebbe consistere nelle sue stesse parole: è più una previsione di ciò che potrebbe accadere che una presa d’atto di un fatto acclarato. Ma sarebbe un artificio retorico per evitare il problema, che invece va affrontato direttamente, ripercorrendo le caratteristiche chiave del concetto di commodity.

La fungibilità: quale intercambiabilità

Uno studio del Digital Economy Lab di Stanford, pubblicato a marzo e firmato da Elisa Pereira, Alvin Wang Graylin ed Erik Brynjolfsson, tra gli economisti più autorevoli sulla produttività dell’IT, analizza 51 casi di successo di adozione aziendale in 41 organizzazioni. Uno dei risultati principali, riportato senza mezzi termini [4]: “For 42% of implementations, model choice was fully interchangeable.” Cioè, in quasi la metà dei casi reali che hanno generato valore misurabile, la scelta del modello di base era irrilevante. Il dato è scomodo per il mio argomento della settimana scorsa. Va affrontato, non eluso.

La domanda giusta è: che tipo di intercambiabilità stanno documentando? Ci sono due letture possibili. Una, la lettura forte dell’indifferenziazione, sostiene che i modelli si sono equivalsi qualitativamente. L’altra dice che i casi d’uso documentati erano sotto una soglia di capacità così bassa da poter essere risolti da qualunque modello di frontiera. Sono ovviamente casistiche molto diverse tra loro.

I dati dei test di valutazione sembrano orientarsi verso la seconda situazione. A luglio 2026 nessun modello vince ovunque: Claude Fable 5 guida sulla scrittura di codice di frontiera (SWE-bench Verified attorno al 95%), Gemini 3.1 Pro guida sulle prove di ragionamento scientifico e astratto (GPQA Diamond, ARC-AGI-2), GPT-5.4 guida nell’uso autonomo del computer (OSWorld-Verified 75,0%, sopra il livello umano di riferimento) [5]. I profili prestazionali restano distinti quando il compito diventa difficile. La fungibilità che Stanford osserva è sufficienza, non identità: per i casi d’uso sotto soglia qualunque modello di frontiera basta — ma “bastare” non è “essere lo stesso bene”. E infatti la fungibilità non regge nemmeno dove sembra reggere. Due modelli non sono lo stesso bene: anche quando su un compito neutro l’esito è ugualmente valido, non producono la stessa risposta, e l’equivalenza svanisce del tutto non appena il compito tocca qualcosa che i loro addestramenti trattano in modo diverso.

Una commodity è neutra rispetto al produttore — la specifica cancella chi l’ha fatta: 220 volt sono 220 volt, il barile Brent è Brent da qualunque pozzo arrivi. Un modello non è mai neutro rispetto a chi l’ha addestrato: dati, allineamento e filtri incorporano scelte di valore che restano in ogni risposta. The Economist lo mostra con il caso più clamoroso: i modelli cinesi open-weight, scaricabili e installabili sui propri server, sono offerti al mondo come “shared asset for all humanity”, ma sono tenuti a rispettare i “core socialist values”. Come riporta la testata, una bambola AI esportata dalla Cina, interrogata sullo status di Taiwan, risponde che l’isola “is an inalienable part of China” e che ciò “cannot be refuted” [6]. La differenziazione non è un divario temporaneo che la concorrenza cancella — l’assunto di Imas — è impressa nel bene alla fabbricazione.

E non è solo la Cina: cambia il valore che gli viene attribuito, non il fatto che ci sia. Grok, il modello di Elon Musk, la dipendenza dal proprietario l’ha messa a verbale — nel maggio 2025 ha cominciato a infilare la teoria del “white genocide” sudafricano in risposte che non c’entravano (xAI l’ha attribuito a una modifica “non autorizzata” del system prompt, poi resa pubblica); a luglio, istruito a non evitare il “politicamente scorretto”, è arrivato a definirsi “MechaHitler” [7]. All’estremo opposto Anthropic pubblica la “costituzione” con cui allinea Claude, e gli studi comparativi misurano orientamenti diversi da un modello all’altro — Grok il più oscillante, Claude il più centrista, i modelli OpenAI più a sinistra [8]. Meta ha scelto l’open-weight: rilasciare i pesi è già, di per sé, un atto strategico e di valore. Mistral porta un’impronta ancora diversa: quella regolatoria europea, GDPR-native e vincolata dall’AI Act [9]. La domanda non è se un modello sia neutro — non lo è nessuno — ma di chi siano i valori che porta dentro e se li dichiara. La corrente elettrica non ha un “di chi”.

E vale perfino all'interno di un solo fornitore: le versioni successive dello stesso modello non sono intercambiabili, e il loro comportamento dipende da due strati — come sono addestrate e come le istruisci — un comportamento che non è quello di una commodity: risponde con toni e atteggiamenti diversi, come ho sperimentato passando da Sonnet a Opus 4.7 e Opus 4.8.

Si obietterà che anche le commodity hanno qualità diverse: il greggio sweet e sour, i diversi livelli di ottani. Ma le qualità di una commodity sono trasparenti, definite e prezzate: compri “Brent” e sai esattamente che cosa ti arriva, chiunque l’abbia estratto. Il condizionamento di un modello è opaco, non dichiarato e deliberato: il produttore non converge verso uno standard comune, ma imprime i propri valori di proposito. In una commodity le differenze tendono a sparire, a convergere verso uno standard comune; in un modello AI sono volute: ogni produttore vi imprime scelte proprie che lo qualificano rispetto agli altri. È il contrario esatto della commoditizzazione.

La fungibilità è solo la prima delle cinque proprietà (il prezzo non misura il valore, il costo di migrazione è elevato, la stabilità non c’è, la barriera d’uso è alta, come mostrano i prossimi paragrafi), ma è quella che cade più a fondo: il modello la manca alla radice, non per una differenza di grado.

Standardizzazione e prezzo: il costo che non è prezzo

La caduta dei prezzi dei token (le unità con cui si misura ciò che entra ed esce da un modello) è ormai un dato di fatto. Da quando GPT-4 è uscito nel marzo 2023 a 30 dollari per milione di token in ingresso, il prezzo dei modelli di frontiera è sceso di oltre il 90%. Oggi il successore di punta di quella linea è intorno ai 2 dollari, mentre le versioni più leggere della stessa famiglia sono sotto 1 dollaro. Il segnale sembra quello di un mercato delle commodity in tendenza verso l’equilibrio, in cui il prezzo scende fino al costo marginale e nessuno cattura margine.

I numeri di chi produce i modelli raccontano un’altra storia. OpenAI proietta una perdita di 14 miliardi di dollari per il 2026, senza redditività prevista prima del 2029–2030 [10]. Anthropic ha visto il margine lordo passare dal -94% nel 2024 a circa il 60% nel 2026, ma il salto è dovuto a un’esecuzione dei modelli più efficiente, non al rialzo dei prezzi [11]. E c’è uno schema, documentato dagli analisti, che spiega una parte dell’anomalia: il capital recycling. Amazon ha investito fino a 25 miliardi di dollari in Anthropic; Anthropic si è impegnata a spendere oltre 100 miliardi di dollari per il calcolo su AWS. OpenAI, dal canto suo, ha firmato con la stessa AWS un impegno d’acquisto di calcolo per 38 miliardi. E Microsoft, che possiede il 27% di OpenAI, ha contabilizzato nel solo trimestre 3,1 miliardi di dollari come propria quota del rosso di OpenAI (un passivo che, riproporzionato, implica una perdita trimestrale di OpenAI di circa 11,5 miliardi) mentre riconosce ricavi da Azure dallo stesso cliente che quella spesa genera [12].

Il prezzo che scende in queste condizioni non è il prezzo di equilibrio in un mercato competitivo come ipotizza Imas. È un prezzo determinato con lo scopo di conquistare quote di mercato, una strategia che prosegue finché il capitale regge. E soprattutto: il costo misurato per token non fornisce alcuna unità condivisa di misura del valore. Mille token possono produrre una risposta inutile o una decisione operativa da migliaia di euro. Il costo si misura, il valore no. La seconda proprietà della commodity, il prezzo per unità di valore, non è nemmeno definibile.

Il costo di migrazione: il moat che si costruisce

Nella terminologia della strategia aziendale, moat (“fossato”) è la barriera strutturale che protegge un business dai concorrenti: costi di ingresso elevati, effetti di rete, brevetti, marchi. È la parola che Imas usa nel tweet: la sua previsione sulle commodity vale solo se non emerge un moat. Il mercato dei modelli di base ne ha almeno uno sulle barriere all’ingresso e, a maggio 2026, i lab hanno iniziato a costruirne un secondo sull’adozione.

Un rapporto RAND del 2024, applicato empiricamente al mercato dei modelli di base, conclude che “il caso attuale per un monopolio naturale è relativamente forte”: modelli omogenei, economie di scala elevate, costi in gran parte nascosti ed effetti di rete pronunciati [13]. Il costo di addestramento di GPT-4 è stimato tra 63 e 100 milioni di dollari in termini di potenza di calcolo e, secondo le proiezioni di Epoch AI, addestrare un modello di punta supererà il miliardo entro il 2027. È una soglia che esclude ogni attore al di fuori di un ristretto cerchio di grandi operatori del cloud e dei loro partner. È il primo moat: la struttura di mercato è oligopolistica a causa dei costi di ingresso.

E qui si vede la seconda mossa, quella che Imas descrive parzialmente e che si è chiarita solo a maggio. All’inizio di maggio 2026, a pochi giorni l’uno dall’altro, i due lab principali hanno annunciato iniziative dedicate all’adozione presso i clienti per un nuovo capitale di 5,5 miliardi di dollari. Anthropic ha lanciato una joint venture con Blackstone, Goldman Sachs e Hellman & Friedman (per un valore di 1,5 miliardi, secondo la stampa finanziaria) per integrare Claude nelle operazioni delle società partecipate dai fondi coinvolti. OpenAI ha annunciato The Deployment Company (4 miliardi da 19 tra investitori, società di consulenza e integratori di sistemi, con una valutazione di 10 miliardi prima dell’investimento) e ha acquisito Tomoro per portare a bordo, dal primo giorno, 150 ingegneri distaccati presso il cliente, i “forward deployed engineers” [14]. Il modello ricalca da vicino quello di Palantir: l’ingegnere va dal cliente, ne impara il flusso di lavoro, scrive software che avvolge il modello attorno al problema, e resta finché il sistema funziona in modo stabile.

La logica che giustifica l’operazione è quella classica del mercato aziendale: attorno a ogni euro di licenza software ruota una spesa per servizi di integrazione molto più elevata. È esattamente la fetta di valore che il piano di adozione (coordinamento dei sistemi, dati proprietari, integrazione nei processi, competenze) rappresenta. La proprietà del basso costo di migrazione sta cambiando. I lab stanno impostando costi di migrazione elevati nel piano di adozione, con una soluzione che, una volta installata, è su misura per il flusso di lavoro del cliente, integrata con i suoi dati e appresa dai suoi ingegneri interni. Cambiare fornitore significa interrompere un rapporto operativo di mesi con persone insediate nel proprio processo.

Stabilità nel tempo, barriera d’uso

Le altre due proprietà si commentano brevemente. Sui modelli usati in azienda, il ritmo di aggiornamento resta di tre-sei mesi e ogni nuova versione vanifica test consolidati e riapre le valutazioni. Il declino dei prezzi accelera invece di rallentare: a parità di prestazioni, il costo per ottenerle si riduce ogni anno di un fattore compreso tra 9 e 900 volte, a seconda del compito, secondo lo Stanford AI Index. Il mercato stesso è in trasformazione strutturale ogni pochi mesi, come mostra la mossa sull’adozione di maggio. Le commodity vere non fanno questo. Il rame del 1980 è il rame del 2026 e non sviluppa un modo di parlarti. Lo tocco con mano da utente: la versione di Claude che uso oggi non risponde come quella di qualche mese fa e, discutendo proprio di questo pezzo, mi ha contraddetto dove le precedenti avrebbero assecondato. Il modello di tre versioni fa non è quello di adesso.

Sulla barriera d’uso, la conferma arriva dalla stessa fonte che sembrava metterla in difficoltà. Lo studio di Stanford dice che il 77% delle sfide più difficili nelle adozioni riguarda costi invisibili, non tecnici: gestione del cambiamento, qualità dei dati, ridisegno dei processi. Brynjolfsson lo scrive esplicitamente: “the durable advantage is in the orchestration layer, not the foundation model.” E dal fronte opposto — un venture capitalist che ha investito miliardi nell'AI, non un economista accademico — Marc Andreessen arriva alla stessa conclusione: il moat è ciò che costruisci attorno al modello, non il modello stesso [15]. Il consenso trasversale è ormai netto: la barriera d’uso è alta e sta crescendo.

Non è la prima volta

Questa confusione ha una storia, e la parola commodity torna sempre allo stesso modo. Nel maggio 2003 Nicholas Carr pubblicò su Harvard Business Review “IT Doesn’t Matter”: l’informatica aziendale, sosteneva, ha “all the hallmarks of an infrastructural technology” ed è perciò destinata a una “particularly rapid commoditization”. La conclusione: non offre un vantaggio competitivo, è solo un costo da comprimere — meglio esternalizzare, seguire invece di guidare, rimandare gli investimenti. Presa alla lettera, quella tesi produsse un decennio di scelte sbagliate.

L’errore non era dire che qualcosa si fosse commoditizzato. Alcune cose lo sono davvero: i PC, la potenza di calcolo a consumo, alcuni servizi cloud. L’errore era il salto di strato — trattare l’intero campo come se fosse definito dallo strato dell’infrastruttura. Una commodity ha, per definizione, un basso o nullo rischio di adozione: la compri, la monti, la usi. Se l’IT lo fosse stato davvero, perché i progetti di adozione fallivano con la regolarità che Carr stesso documentava? È l’argomento che porto avanti da vent’anni: le tante delusioni sono la prova che l’IT, salvo i suoi componenti di base, non è mai stato una commodity. Con l’AI la scena torna identica, di nuovo con un salto di strato: si guarda il prezzo per token, che crolla, e si dichiara commodity l’intero campo, quando è il piano di adozione a decidere il valore — ed è quanto di più lontano da una commodity ci sia.

E stavolta il coro non è quello di un solo economista. Accanto a Brynjolfsson e Andreessen, citati sopra, negli ultimi mesi si sono aggiunte altre voci, da parte di chi non ha alcun interesse a negare la potenza dell’AI. McKinsey, in uno studio di luglio [16], è netta: “AI does not create enterprise value simply because more people use it. Individual productivity gains matter, but they rarely translate into lasting advantage when the organization around them stays the same.” In un secondo lavoro [17] concede che “capabilities that differentiate one platform today often become standard within months”, e proprio da lì conclude che “most AI value comes from people and process transformation, not algorithms, technology, or data infrastructure.” È lo stesso punto della fungibilità: anche concedendo che i modelli si equivalgono, la categoria non si sposta, perché il valore sta altrove. E chi guarda il problema dal lato di chi deve realizzarlo arriva alla stessa diagnosi [18]: “The gap isn’t the technology. It’s the foundational work most organizations haven’t done: data readiness, operating models, governance, skills, and culture. […] They’re tackling the unglamorous work themselves.”

Tre voci diverse, una conclusione sola: il valore sta nel piano di adozione, ed è un processo complesso e ad alto tasso di fallimento — non un interruttore. È il rovescio di una commodity. Di una commodity puoi fidarti: il litro di benzina fa sempre la stessa cosa e, se la tua flotta fallisce, non è colpa della benzina ma del tuo piano. Di un modello no: il bene non è neutro e non ti dà lo stesso risultato ogni volta — parte del rischio è nel bene stesso. Perfino l’inefficienza spinge nella stessa direzione. Un’analisi di Atlantic [19] nota che i modelli generativi scalano al rovescio rispetto a ogni altro software, “the bigger an AI model is, the less it improves with each added parameter”, così che il prezzo che scende non segnala un bene che matura, ma capitale che ne copre uno che perde.

La questione strategica

Se i cinque piani della definizione di commodity non si applicano, e i dati di mercato lo confermano, la domanda diventa: cosa c’è dietro l’insistenza con cui la parola torna? La risposta sta nella mossa delle imprese del settore.

L’insistenza nel presentare il modello come commodity copre uno spostamento strategico da parte dei venditori verso il piano di adozione. Il modello base, come servizio venduto al minuto, è la parte che i lab hanno smesso di considerare strategica. Il valore che stanno costruendo lo mettono altrove: nella verticalizzazione (il passaggio dal modello generale a soluzioni su misura, calate sul cliente e sul suo settore), attraverso ingegneri distaccati presso il cliente, nell’integrazione su misura nei processi del cliente, nella cattura della spesa per i servizi che circondano ogni licenza software. La spinta a “verticalizzare” che Imas osserva è la strategia con cui i lab entrano nel mercato dell’adozione, cioè nel piano che, nel post della settimana scorsa, indicavo come quello in cui il valore per l’azienda si costruisce internamente.

Il consiglio d’amministrazione che sente “AI is a commodity” e ne trae la conclusione manageriale familiare: tagliare il budget di formazione, esternalizzare le competenze per l’uso e l’istruzione dei modelli, scegliere il fornitore in base al prezzo per token. Così facendo, sta regalando due cose contemporaneamente: rinuncia a costruire capacità sul piano su cui si concentra il valore e consegna quel piano nelle mani di chi ha appena costruito 5,5 miliardi di dollari di infrastruttura per prenderlo. È l’errore della consulenza SAP/Oracle degli anni Duemila, con una differenza: il vincolo di secondo livello che si crea con un ingegnere distaccato e insediato nel processo aziendale è più profondo di quello che si creava con un consulente SAP, e si stringe in mesi invece che in anni.

E qui entra la terza forza che Imas non menziona. Accanto ai modelli proprietari — quelli che usi solo attraverso il fornitore — sono arrivati i modelli open source, che chiunque può scaricare ed eseguire per conto proprio, oggi in media quattro mesi più tardi rispetto ai migliori proprietari [20]. Con loro la soglia di accesso al modello si azzera quasi: niente licenza, niente fornitore. Ma l'accessibilità non definisce una commodity. Non è che prendi un modello, lo colleghi e lo usi come la corrente: sotto quella soglia di adozione bassissima c’è tutto il lavoro di prima: metterlo in produzione, valutarlo, integrarlo nei processi, adattarlo ai tuoi dati. La barriera che il fornitore ti nascondeva non sparisce, si sposta intera sull’adozione. È il profilo rovesciato di una commodity: un prodotto sempre più accessibile che richiede investimenti crescenti di competenza e di adozione. I modelli open source spingono l’accesso verso il basso senza mai toccare la categoria; anzi, sono la prova più chiara che il valore non sta nel modello, ma in ciò che l’azienda ci costruisce attorno.

Qualche conclusione

La parola commodity cade su tutte le proprietà che la definiscono: il prezzo non misura il valore, il costo di migrazione sale invece di essere basso, la stabilità non c’è, la barriera d’uso è alta. Perfino la fungibilità, l’unico appiglio della tesi contraria, si ferma ai casi d’uso più semplici — la coppia modello-uso, non il modello — e non tocca il bene, che porta impressa l’origine di chi l’ha addestrato. Il prezzo che scende, l’unico segnale che sembra dire il contrario, non è la prova di un mercato-commodity: è capitale sussidiato in un oligopolio, non un equilibrio competitivo. Chi la porta in consiglio d’amministrazione come argomento per non investire in adozione fa un salto di categoria che vent’anni fa costò caro: è lo stesso errore di Carr, che spinse molte aziende a esternalizzare l’IT dopo “IT Doesn’t Matter” [21], e le lasciò, dieci anni dopo, con dipartimenti ridotti a comprare licenze e la strategia digitale in mano al system integrator di turno. La differenza è che oggi chi vende il modello offre anche l’adozione, con ingegneri che si siedono ai tuoi tavoli, imparano i tuoi processi, scrivono il software e lo controllano per te.

Se decidi che l’AI è commodity, in consiglio, hai preso in dieci secondi due decisioni: non costruisci capacità interna e la compri da chi vende il modello. Nel decennio, si vedrà chi ha scelto bene.

Per approfondire

[1] Alex Imas (@alexolegimas), tweet del 18 luglio 2026, x.com/alexolegimas/status/2078529740281970689. Imas è professore alla University of Chicago Booth School of Business (in aspettativa) e, dal maggio 2026, Director of AGI Economics a Google DeepMind. Il “big push from all the labs to go vertical” è nelle parole di Imas; la lettura di quella “verticalizzazione” come strategia di adozione — ingegneri distaccati presso il cliente, modello Palantir — è sviluppata in questo pezzo, non una definizione data da Imas.

[2] David Rein (@idavidrein), interventi nel thread sotto il tweet di Alex Imas, 19 luglio 2026. Rein fa ricerca su valutazione e controllo dei sistemi di AI (METR) ed è il primo autore del benchmark GPQA (D. Rein et al., “GPQA: A Graduate-Level Google-Proof Q&A Benchmark”, 2023).

[3] Pedro Tremacoldi-Rossi (@pedrotrossi1), intervento nella discussione sotto il tweet di Alex Imas, 19 luglio 2026, x.com/pedrotrossi1/status/2078633442795802712. Tremacoldi-Rossi è financial economist a Cornerstone Research ed è postdoctoral research scholar al Department of Economics della Columbia University, dove insegna. Ha conseguito il PhD alla University of Illinois at Urbana-Champaign, dove ha tenuto il corso Commodity Futures and Options ed è affiliato all’Office for Futures and Options Research; la sua ricerca riguarda i mercati finanziari e la loro microstruttura.

[4] Elisa Pereira, Alvin Wang Graylin, Erik Brynjolfsson, The Enterprise AI Playbook — Lessons from 51 Successful Deployments, Stanford Digital Economy Lab, marzo 2026, digitaleconomy.stanford.edu/publication/enterprise-ai-playbook.

[5] Dati dei test di luglio 2026 da Artificial Analysis e da vals.ai per SWE-bench Verified; le cifre sull’uso autonomo del computer di GPT-5.4 (OSWorld-Verified 75,0%) sono dalla pagina ufficiale OpenAI. Le classifiche di frontiera cambiano rapidamente e i numeri esatti variano tra aggregatori: qui si riportano le posizioni di leadership per famiglia di compiti, non una classifica puntuale.

[6] “When China’s open-source AI is a trap”, The Economist, sezione International (The Telegram), 14 luglio 2026 (edizione a stampa del 18 luglio 2026), economist.com. L’esempio della bambola Miiloo è attribuito dalla testata a “American researchers” non nominati.

[7] Su Grok e la sua dipendenza dal system prompt: “Grok started calling itself ‘MechaHitler’”, NPR, 9 luglio 2025, npr.org; “Users accuse Grok of a rightward tilt after xAI changed its internal instructions”, Fortune, 8 luglio 2025, fortune.com; l’episodio “white genocide” (maggio 2025) è ricostruito da PBS News, pbs.org.

[8] Sugli orientamenti politici misurati nei modelli: “Popular AI Models Show Partisan Bias When Asked to Talk Politics”, Stanford Graduate School of Business, 2025, gsb.stanford.edu; “Evaluating political bias in LLMs”, Promptfoo, 2025, promptfoo.dev. Anthropic ha pubblicato la propria ricerca sull’even-handedness politica nel novembre 2025.

[9] Mistral AI: posizionamento europeo “sovrano”, GDPR-native e conformità all’AI Act (obblighi per i modelli GPAI dal 2 agosto 2026), da materiali legali Mistral, legal.mistral.ai, e analisi di settore 2026.

[10] Le proiezioni finanziarie interne di OpenAI — perdita di circa 14 miliardi di dollari nel 2026 e ritorno all’utile non prima del 2029–2030 — sono state anticipate da The Information sulla base di documenti interni e riprese dalla stampa finanziaria: Fortune, “OpenAI says it plans to report stunning annual losses through 2028—and then turn wildly profitable just two years later”, 12 novembre 2025, fortune.com.

[11] Stime SemiAnalysis sui margini di Anthropic (margine lordo dal -94% nel 2024 a circa il 60% nel 2026, trainato dall’efficienza di inferenza), riprese da BigGo Finance, “On the Eve of Trillion-Dollar Valuations: Anthropic Turns Profitable First”, luglio 2026. Sono stime di analisti, non dati ufficiali certificati.

[12] Cifre di capital recycling da fonti primarie e stampa finanziaria: l’investimento Amazon in Anthropic (fino a 25 mld, aprile 2026) e l’impegno Anthropic di spesa di calcolo su AWS (oltre 100 mld) da CNBC e TechCrunch; l’impegno d’acquisto OpenAI–AWS da 38 mld dal comunicato Amazon (novembre 2025); i conti Microsoft Q1 FY26 (ottobre 2025) registrano 3,1 mld come quota del 27% di OpenAI, che implica un passivo trimestrale di OpenAI di circa 11,5 mld, da The Register.

[13] Jon Schmid, Tobias Sytsma, Anton Shenk, Evaluating Natural Monopoly Conditions in the AI Foundation Model Market, RAND Corporation, RR-A3415-1, settembre 2024, rand.org/pubs/research_reports/RRA3415-1. Il rapporto valuta il mercato “as of January 2024” e conclude che il caso per un monopolio naturale è “relatively strong”.

[14] Comunicati ufficiali Anthropic (la nuova società di servizi enterprise con Blackstone, Hellman & Friedman e Goldman Sachs, 4 maggio 2026) e OpenAI (il lancio di The Deployment Company, con l’acquisizione di Tomoro e i 150 ingegneri distaccati presso il cliente). Le cifre finanziarie sono da stampa primaria: 1,5 mld della joint venture Anthropic da CNBC e Fortune (non riportati nel comunicato Anthropic); 4 mld di nuovo capitale e valutazione di 10 mld prima dell’investimento di The Deployment Company da OpenAI e Bloomberg.

[15] La posizione è ripresa e parafrasata in: The AI Corner, “The AI moat is not the model. Marc Andreessen on why AI gets more expensive as it commoditizes”, 18 maggio 2026, che la attribuisce a un intervento di Andreessen a un meeting LP di a16z (gennaio 2026). Trattandosi di un evento privato senza trascrizione a verbale, la frase è resa come parafrasi e non come citazione testuale.

[16] McKinsey & Company, “From Adoption to Impact: Three Horizons of AI Transformation”, 8 luglio 2026, mckinsey.com.

[17] “The Operating Model Advantage: Why AI Winners Are Rewiring Their Organizations”, McKinsey & Company, 7 luglio 2026, mckinsey.com.

[18] Stephanie Overby, “CIOs Must Rethink Operating Models to Unlock AI at Scale”, CIO, 13 luglio 2026, cio.com.

[19] Alex Reisner, “Generative AI Is an Engineering Disaster”, The Atlantic, 14 luglio 2026, theatlantic.com.

[20] Jack Edwards, Luke Emberson, “Open models lag state-of-the-art closed models by 4 months”, Epoch AI, 29 maggio 2026, epoch.ai/data-insights/open-closed-eci-gap. Il gap medio è di quattro mesi (8 punti ECI) nel periodo gennaio–maggio 2026, in leggero aumento rispetto ai tre mesi del periodo gennaio 2023–ottobre 2025.

[21] Nicholas Carr, “IT Doesn’t Matter”, Harvard Business Review, maggio 2003, hbr.org/2003/05/it-doesnt-matter.

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 post in tre frasi

1. La retorica “AI is a commodity” del 2026 ripete l’errore di “IT Doesn’t Matter” (Nicholas Carr, 2003): entrambe ignorano la definizione economica di commodity e portano alle stesse scelte manageriali sbagliate: outsourcing, gare al ribasso, impoverimento delle competenze e il loro allontanamento dai tavoli decisionali.

2. Applicando i parametri economici della definizione di commodity (fungibilità, standardizzazione, prezzo di mercato, basso switching cost, stabilità nel tempo, bassa barriera d’uso), l’AI non soddisfa alcuno di essi. E non si tratta di una fase transitoria: è la natura della tecnologia.

3. Trattare l’AI come una commodity non è un problema terminologico, ma un errore strategico: chi lo fa pagherà due volte, in valore non estratto e in vantaggio competitivo ceduto a chi ha imparato a usarla.

Chi lavora nella tecnologia da un po’ di tempo riconosce il ritornello. Cambia la sigla, ma resta la formula. Nel 2003 era “IT Doesn’t Matter” [1]: l’informatica è diventata un’infrastruttura, quindi commodity, quindi irrilevante per la strategia. Nel 2026 è “AI is a commodity”: i modelli sono accessibili via API, i prezzi per token scendono, i grandi provider offrono capacità simili; quindi l’intelligenza artificiale è diventata una commodity e si compra come la corrente elettrica.

Alcuni usano “commodity” in senso metaforico: intendono dire che l’AI sarà accessibile a tutti, come l’elettricità. È una tesi comprensibile. Ma il problema è che la parola “commodity” non è neutrale: se importata in un contesto aziendale, porta con sé una teoria economica. E la teoria economica del bene determina le strategie. Come dice Nanni Moretti, “Le parole sono importanti!”, soprattutto quando si parla di temi così delicati.

Cos’è una commodity

Il Dizionario di Economia e Finanza della Treccani definisce “commodity” come “ogni tipo di merce o materia prima tangibile e fruibile sul mercato, facilmente immagazzinabile e conservabile nel tempo” [2]. Gli esempi sono canonici: petrolio, oro, gas, cereali, caffè, bestiame. L’etimologia è illuminante: dal francese commodité, “ottenibile comodamente”.

Attorno a questa nozione la teoria economica ha costruito alcuni test operativi. Una commodity ha una serie di caratteristiche:

• fungibile, cioè intercambiabile fra produttori senza differenze qualitative;

• standardizzata e prezzata dal mercato, con unità di misura condivise (dollari al barile, dollari per once di oro puro al 99,5%…);

• a basso costo di sostituzione tra fornitori;

• stabile nel tempo, senza modifiche significative nel comportamento del bene;

• a bassa barriera d’uso, nel senso che l’acquirente non deve imparare a usarla, ma solo a impiegarla nel proprio processo produttivo.

Applichiamo questi test all’AI, una proprietà alla volta.

Fungibilità: Sonnet non è Fable

La prima proprietà di una commodity è che l’acquirente sia indifferente nei confronti del produttore. Un kilowattora è un kilowattora: non cambia le sue caratteristiche in base a chi lo produce.

Sonnet non è Fable. GPT-5 non è Claude Opus. Gemini non è Llama. A parità di prompt, gli output differiscono per tono, struttura, precisione, rischio di errore, gestione dell’incertezza e capacità di seguire istruzioni complesse. Non parlo di sfumature estetiche: parlo di differenze che, in un flusso applicativo reale, si traducono in tassi di successo, retention degli utenti ed escalation al supporto umano.

Inoltre, sotto il titolo “GenAI” si celano molteplici tipologie di prodotto, ciascuna adatta a specifiche attività professionali o aziendali. Ho chiesto a Claude di generare due infografiche per mappare il panorama delle tecnologie e dei prodotti nel mondo della GenAI. Probabilmente ci sono errori e imprecisioni (GenAI è fallibile e opera in modo probabilistico!). Ma qui serve cogliere la complessità e la ricchezza di questo mondo. Sono aspetti che nessuna adozione seria può ignorare. A meno di non farne un uso semplificato ed estemporaneo.

Chiunque abbia messo in produzione una funzionalità basata su un LLM sa che cambiare modello non equivale a sostituire un fornitore di corrente. Vuol dire rivalutare l’insieme degli strumenti adottati, rifare i test, rivedere i prompt, ricalibrare i valutatori e riscrivere parti dell’orchestrazione. Inoltre, un modello non è indipendente da chi lo ha creato e addestrato, a differenza di un kilowattora prodotto da diverse centrali. Un modello è il risultato di scelte di training, di dati e di alignment: differenze qualitative che nessuna standardizzazione elimina.

Prezzo, costi, unità di misura del valore

Una commodity ha un prezzo pubblico, quotato in un’unità di misura condivisa che rappresenta il valore economico del bene. Dollari al barile, dollari all’oncia, euro al megawattora. La quotazione è trasparente perché la sostanza sottostante è omogenea.

L’AI non ha nulla di tutto questo. Il token è un’unità di consumo tecnico, non un’unità di valore. Lo stesso numero di token può generare una risposta banale che nessuno userà, oppure una decisione operativa che vale migliaia di euro. Non c’è alcuna relazione stabile tra l’input consumato e il valore restituito. Mille token consumati producono, a seconda del caso, un risultato inutile, un risultato eccellente o un’allucinazione. Il costo si misura, il valore no.

E il costo sostenuto non è facile da prevedere. Chi progetta sistemi seri se ne accorge alla prima fattura mensile, che troppo spesso sfora le previsioni fatte. Le aziende scoprono di avere agenti che consumano milioni di token per attività che, a mente lucida, ne richiederebbero decine di migliaia. I meccanismi di controllo (rate limiting, caching, model routing) sono complessi da progettare e richiedono competenze specifiche. Una commodity ha costi facilmente prevedibili e gestibili; per questo motivo si scambia sui mercati a termine. L’AI, oggi, comporta costi fuori controllo in molte adozioni concrete: il 73% delle aziende dichiara che i costi hanno superato le proiezioni iniziali [3].

Switching cost: comprare non è migrare

Nel mercato dell'AI cambiare modello significa toccare l'intero stack applicativo. Le istruzioni scritte per il modello (i prompt), i sistemi che valutano le sue risposte, i meccanismi che gli consentono di usare strumenti esterni, i sistemi che gli forniscono informazioni dall'archivio aziendale: ognuno di questi elementi è calibrato sulle peculiarità del modello scelto [4].

Chi ha adottato e usato seriamente l’AI ha già scoperto il costo della migrazione. Chi non lo ha fatto lo scoprirà quando cercherà di passare da un provider all’altro o dovrà orchestrare più modelli in parallelo. Un sondaggio Zapier del 2026 su oltre cinquecento dirigenti aziendali americani lo conferma: tra chi ha tentato una migrazione tra piattaforme di AI, il 58% afferma che la migrazione è fallita del tutto o ha richiesto molto più sforzo del previsto [5]. E il caso di Claude Fable 5, sospeso a livello globale per diciotto giorni nel giugno 2026 per un ordine di export control del Dipartimento del Commercio statunitense, ha mostrato che il lock-in su un singolo provider è un rischio operativo concreto, non ipotetico [6].

Una commodity si sostituisce, un modello si migra. Sono due verbi che descrivono economie diverse.

Evoluzione continua e artefatto conoscitivo

Il rame del 1980 è il rame del 2026. Il petrolio di dieci anni fa, raffinato per gli stessi usi, dà gli stessi risultati. La stabilità nel tempo è parte della definizione di commodity: se non fosse così, i futures non funzionerebbero.

I modelli AI si aggiornano ogni tre o sei mesi. Non solo con nuove versioni, ma con aggiornamenti che cambiano comportamenti sottili, spostano capacità, rompono valutazioni consolidate. Ogni release rimette in discussione i test di regressione, i benchmark interni, la calibrazione dei sistemi. Chi gestisce sistemi in produzione con LLM tiene un log di comportamenti che cambiano fra una release e l’altra, e sa che ogni “minor update” annunciato dal provider è un evento che richiede attenzione [7].

Questa non è un’anomalia da correggere, è la natura della tecnologia. Un modello di frontiera è un artefatto conoscitivo, il prodotto di scelte progettuali su dati, obiettivi di training, priorità di alignment, tradeoff fra capacità diverse. Riflette una teoria implicita di cosa sia utile, ragionevole, sicuro. Chiamare commodity un artefatto di questo tipo è una categoria concettuale sbagliata, prima ancora che un errore di analisi economica. Confonde il modo di produzione (industriale, su larga scala) con la natura del prodotto (contingente, situato, negoziato).

La barriera d’uso: chi accende la luce non pensa alla corrente

C’è un’ultima proprietà, la più importante. Chi compra una commodity la usa, non deve conoscerne il funzionamento. Chi accende la luce non sa come si genera la corrente; chi compra farina la impasta senza essersi mai occupato della macinazione; chi compra benzina la brucia nel motore senza pensare al giacimento. Il prodotto è pronto per essere consumato secondo protocolli stabiliti.

L’AI no. Per produrre valore va conosciuta per come funziona e per come lo fa: saperla interrogare (prompt engineering), fornirle il contesto giusto (context engineering), integrarla con i propri dati (retrieval, tool use), valutarne l’output (eval), correggerne le derive (guardrail, monitoring), aggiornarne la pipeline quando cambiano i modelli. È un lavoro cognitivo di alto livello che richiede persone che sappiano cosa stanno facendo. Non basta comprarla: bisogna imparare a usarla. Serve ricerca, serve formazione, serve l’accumulo di conoscenza all’interno dell’organizzazione.

Il costo di una categoria sbagliata

Chiamare l’AI una commodity non è una questione terminologica. È una categorizzazione che determina in anticipo come l’azienda tratterà la tecnologia. Da lì discende una cascata di scelte manageriali che derivano automaticamente dalla categoria adottata: gare al ribasso sui fornitori, esternalizzazione dei ruoli distintivi, budget di formazione tagliati, competenze tecniche allontanate dai tavoli decisionali, KPI sulla riduzione del costo per utente invece che sull’accumulo di capacità. Sono gli stessi automatismi che hanno impoverito l’IT negli ultimi vent’anni; solo che oggi il costo del non fare non si misura in progetti che finiscono in ritardo, ma in intere aziende che perdono la capacità di comprendere il proprio settore.

Il verbo giusto

La commodity si compra. L’AI si adotta: un verbo diverso, con conseguenze diverse.

Chi la tratta come una commodity ha già scelto il proprio destino. Pagherà due volte: una perché non ne otterrà un valore proporzionato all’investimento, l’altra perché nel frattempo qualcun altro sta imparando a farlo. La differenza fra le due posture non si vedrà nel trimestre. Si vedrà nel decennio, come si è vista la differenza fra le aziende che negli anni Duemila hanno preso sul serio l’informatica e quelle che l’hanno trattata come commodity.

La domanda che ponevo alla fine del post sui quattro cavalieri era: quanti di loro galoppano nella vostra azienda? Ne aggiungo un'altra, più elementare: quando qualcuno vi dice che l'AI è una commodity, chiedetegli di nominarne un'altra che, per produrre valore, debba essere istruita a svolgere il proprio lavoro. Se non riesce, non sta conducendo un’analisi fondata. Usando la categoria della commodity, sta di fatto imponendo una scelta strategica. E le decisioni strategiche prese su una categoria sbagliata sono, per definizione, sbagliate.

Per approfondire

[1] Nicholas Carr, “IT Doesn’t Matter”, Harvard Business Review, maggio 2003, hbr.org/2003/05/it-doesnt-matter. L’articolo che ha coniato la formula “IT is a commodity” per l’informatica aziendale, da cui è scaturita una generazione di scelte manageriali di outsourcing e di riduzione dei costi.

[2] Treccani, “Commodity”, Dizionario di Economia e Finanza (2012), voce di Flavio Pressacco, treccani.it.

[3] FinOps Foundation, State of FinOps 2026 Report, data.finops.org. Il 73% delle aziende dichiara che i costi dell’AI hanno superato le proiezioni iniziali; il budget medio per l’AI è passato da 1,2 milioni di dollari nel 2024 a 7 milioni nel 2026. Sul caso Uber (intero budget AI 2026 bruciato entro aprile, con l’introduzione successiva di un cap mensile per dipendente): TechCrunch, “The token bill comes due: Inside the industry scramble to manage AI’s runaway costs”, 5 giugno 2026, techcrunch.com.

[4] OpenAI, “Prompt Migration Guide”, developers.openai.com; Anthropic, “Prompting best practices”, platform.claude.com. I due principali provider ammettono ufficialmente che i prompt non sono portabili tra modelli e forniscono guide di migrazione dedicate.

[5] Zapier, “Zapier Survey Finds Nearly 3 in 4 Enterprises Would Face Disruption If They Lost Their Primary AI Vendor”, BusinessWire, 2 aprile 2026. Sondaggio su 542 C-level executive statunitensi, condotto tramite Centiment tra il 30 gennaio e il 6 febbraio 2026. businesswire.com

[6] Anthropic, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5”, 12 giugno 2026, anthropic.com/news/fable-mythos-access. Ripristino annunciato il 30 giugno 2026: CNBC, “Anthropic says Trump admin has lifted export controls on Claude Fable 5 and Mythos 5”, cnbc.com.

[7] Lingjiao Chen, Matei Zaharia, James Zou, “How Is ChatGPT’s Behavior Changing over Time?”, arXiv:2307.09009 (2023), poi pubblicato in Harvard Data Science Review, 6(1), 2024, arxiv.org/abs/2307.09009. Lo studio empirico documenta scostamenti marcati nel comportamento di GPT-3.5 e GPT-4 tra le release successive: in un caso, l’accuratezza di GPT-4 sul task di identificazione dei numeri primi è passata dall’84% al 51% tra marzo e giugno 2023.

Letture correlate

Matt Asay, “The new AI lock-in”, InfoWorld, 18 maggio 2026, infoworld.com. Il punto centrale rafforza l’argomento del post: il lock-in nell’AI non è sparito con la standardizzazione delle API, si è spostato di uno o due livelli, sull’orchestrazione, sul workflow surface, sul layer di governance. “The model call is getting easier to replace; the surrounding workflow, governance, and operating model are not.”

Gartner, Market Guide for AI Gateways, ottobre 2025. Previsione: entro il 2028 il 70% dei team di software engineering che costruiscono applicazioni multi-model userà un AI gateway (dal 25% del 2025): segnale che l’industry riconosce il lock-in come rischio operativo da gestire con layer di astrazione dedicati.

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 post in tre frasi

1. Molte aziende si avvicinano all’AI partendo dallo strumento (un fornitore, un modello, una tecnologia) anziché dal problema da risolvere, e per questo si scontrano con costi imprevisti e risultati che non tornano.

2. I nove punti che seguono, ciascuno con un fare e un non fare, coprono le principali scelte tecniche, organizzative ed economiche che guidano un processo di adozione di GenAI.

3. Non eliminano i rischi dell’adozione: aiutano a giungere alla decisione con meno assunzioni implicite e a ridurre il rischio di fallimento.

Quando un’azienda mi parla di GenAI, la prima domanda è quasi sempre la stessa: “Da dove cominciamo?” La intendono in senso operativo: scegliere un caso d’uso, un fornitore, un pilota da chiudere entro il trimestre.

Il 9 giugno ho parlato a Bologna con un gruppo di imprese manifatturiere che stanno cercando di capire come gestire l’adozione di GenAI nei propri processi. L’intervento era in due parti: la prima sui limiti strutturali degli LLM, la seconda è un framework con nove punti su come impostare un’adozione pragmatica, ciascuno definito da un fare e un non fare.

I punti derivano da osservazioni raccolte tra aprile e maggio in quattro post su A bassa voce: L’agente che non sa perché, Quando il computer “indovina” e quando calcola, Per un martello, il mondo è fatto solo di chiodi, L’AI che non ricorda. Preparare l’intervento mi ha costretto a estrarne un framework operativo. Eccolo.

1. Partire dal problema, non dallo strumento

La domanda “come uso GenAI?” pone lo strumento prima del bisogno. La domanda corretta è l’opposto: qual è il problema da risolvere e quale strumento lo risolve al meglio? A volte sarà GenAI, spesso sarà altro. Sistemi esperti, blockchain e metaverso sono stati adottati con la stessa dinamica: prima la tecnologia, poi la ricerca di un caso d’uso che la giustificasse. Il risultato: molti studi e progetti mai arrivati in produzione.

✅ Partire da un problema specifico per cui esistono già dati sufficienti. Qualificarlo, poi valutare lo strumento.

❌ Non partire dallo strumento. Non trattare la GenAI come un'opzione automatica. Soprattutto, non trattarla come una commodity (un tema su cui tornerò presto).

2. Domain expert nel progetto, formazione in parallelo

Un LLM non conosce l’impresa specifica in cui deve essere adottato: vincoli operativi, limiti regolatori, procedure interne, conoscenza di dominio. Questa lacuna non si colma solo con più training. La conoscenza organizzativa cambia nel tempo, presenta contraddizioni interne e va arricchita e verificata da chi la usa ogni giorno. Allo stesso tempo, usare GenAI richiede di conoscerne le caratteristiche, i limiti e le dinamiche d’uso.

✅ Domain expert nel team dal giorno uno, con formazione parallela in GenAI fin dalla fase di costruzione del pilota.

❌ Non aspettarsi che un modello, solo perché più grande o potente, sia in grado di “imparare a conoscere l’azienda”. Non rimandare la formazione a dopo il pilota: è una precondizione, non una conseguenza.

3. Calcolare o stimare

Un foglio Excel calcola: stesso input, stesso output. Un LLM stima: pondera le probabilità e può cambiare risposta a parità di domanda. Trattare l’uno come l’altro non è una svista teorica: si paga con errori a valle, con controlli di riproducibilità che non tornano, con numeri che non stanno più insieme.

✅ Prima di scegliere lo strumento, chiarire il tipo di risposta necessario. Certezza riproducibile → calcolo deterministico. Stima, approssimazione, creazione → GenAI.

❌ Non usare GenAI come motore computazionale per calcoli o procedure che richiedono esattezza e riproducibilità dei risultati.

4. Nei workflow regolati, l’LLM è una scelta architetturale onerosa

Al vincolo del punto 3 se ne aggiunge un altro: la ricostruibilità delle decisioni. Nei processi con audit, tracciabilità, accountability legale e vincoli normativi, ricostruire ex post perché una decisione sia stata presa non è opzionale. Un LLM, come motore decisionale, rende quella ricostruzione strutturalmente difficile: le tracce di ragionamento che produce non costituiscono una garanzia di fedeltà al processo interno che ha portato alla decisione.

✅ Nei workflow regolati, mantenere il motore decisionale deterministico. L’LLM può agire come interfaccia con l’utente o come orchestratore di strumenti di terze parti, ma non decide.

❌ Non delegare a un agente non deterministico decisioni che devono essere ricostruibili di fronte a un auditor. Il livello di governance (control plane) può vincolare ciò che un agente è autorizzato a fare, non il modo in cui ragiona per farlo.

5. Nei sistemi transazionali, l’LLM sta fuori dal motore

I sistemi OLTP (contabilità, fatturazione, ERP, gestione degli ordini) hanno due requisiti tecnici che un LLM non è progettato per garantire: correttezza e prestazioni. Un saldo, una fattura, un movimento contabile non ammettono approssimazioni né errori di sincronizzazione tra le operazioni: la correttezza è al centesimo. E una transazione va chiusa in millisecondi, con migliaia di operazioni al secondo, a un costo unitario sostenibile. Nessuno di questi requisiti è compatibile con l’attuale profilo tecnico ed economico degli LLM di frontiera, tipicamente considerati nei progetti aziendali di GenAI attuali.

✅ Nei sistemi transazionali, tenere l'LLM fuori dalla catena delle transazioni. Ha senso come interfaccia esterna: interrogare un database in linguaggio naturale, generare report, sintetizzare dati. Il calcolo e la scrittura restano al motore deterministico.

❌ Non usare l’LLM come componente della catena transazionale, nemmeno come orchestratore di una sequenza di operazioni di commit (l’operazione che rende definitive e permanenti le modifiche di una transazione). Latenza, costi e non-determinismo cumulati rendono il servizio insostenibile prima ancora che inesatto.

6. Lo stato esterno ha un costo che va stimato

Gli LLM sono stateless per definizione: ogni sessione parte da zero. Per simulare la continuità, si costruisce uno stato esterno: un file di contesto, RAG, tecniche di context engineering (cioè come si struttura ciò che viene passato al modello a ogni chiamata). In un workflow personale funziona. In un processo aziendale, lo stato deve essere costruito, mantenuto in vita, validato e testato. È lì che la complessità esplode.

✅ Valutare il costo totale per gestire lo stato esterno: costruzione, manutenzione, validazione, test e riproducibilità.

❌ Non assumere che aggiungere RAG (un livello software che consente all’LLM di accedere a documenti specifici al momento della richiesta) risolva l’assenza di stato a un costo trascurabile. Il più delle volte costa più del processo deterministico che voleva sostituire, e funziona peggio.

7. Governance dei dati prima della governance dell’AI

Qualità, tagging, integrazione, accesso: senza “igiene dei dati”, ogni difetto entra nel modello e ne esce moltiplicato. Un progetto AI eredita tutti i problemi che il sistema informativo aziendale ha lasciato in sospeso: dati duplicati, incoerenze tra le fonti, campi non validati, accessi non tracciati. Non è un problema che si aggira scegliendo un modello migliore. La catalogazione delle fonti, la tracciabilità di chi le aggiorna, la definizione di misure di qualità e il controllo degli accessi vanno impostati prima, non dopo.

✅ Costruire la governance dei dati prima di avviare qualsiasi progetto di AI. Se non esiste, è il primo investimento — e va misurato, non solo dichiarato.

❌ Non lanciare un progetto AI se i dati a supporto non esistono o se non c’è un piano credibile per produrli e validarli. Non aspettarsi che il modello “recuperi” ciò che manca a monte.

8. Economia del progetto: costruzione ed esercizio

I costi dell’AI si dividono in due categorie con logiche distinte. Il costo di costruzione (build) va giustificato ex ante. GenAI non è, di per sé, più conveniente di un’alternativa tradizionale: per i compiti computazionali strutturati, un sistema deterministico ben progettato costa spesso meno e funziona meglio. Il costo di esercizio (run) è variabile e, senza un controllo dedicato, cresce rapidamente e in modo non lineare con l'uso. La FinOps Foundation propone un ciclo in tre fasi da adottare fin dall'inizio: Inform (visibilità), Optimize (efficienza), Operate (governance continua).

✅ Costruzione: quantificare costo reale, beneficio atteso, metro di misura, e la ragione per cui l’approccio tradizionale non basta. Esercizio: monitorare i costi per caso d’uso; ottimizzare token, chiamate ai modelli, infrastruttura. Pratiche FinOps dal primo giorno.

❌ Non trattare i costi dell’AI come “spese tecniche” al di fuori del bilancio. Non dare per acquisito il vantaggio economico: dimostrarlo caso per caso.

9. Dove collocare l’intelligenza

La scelta di dove collocare il modello e i dati va effettuata esplicitamente. Tipicamente, modelli di frontiera in cloud per compiti generici; modelli più piccoli e specializzati, in sede (on-premise) o edge, per dati sensibili o per esigenze di latenza. Architetture ibride (es. RAG con dati in loco e modello in cloud) quando conviene.

✅ Scegliere l’architettura in base a due criteri: la sensibilità dei dati (GDPR, NIS2, vincoli di settore); il profilo di utilizzo effettivo.

❌ Non adottare posizioni di principio del tipo “tutto in cloud” o “tutto in casa”. Il criterio è tecnico ed economico, non una preferenza ideologica.

Si parte dal problema, non dal modello

I nove punti non risolvono il problema di adozione. Servono per arrivare alla decisione con il minor numero possibile di assunzioni implicite. Se, dopo averli esaminati tutti, resta incertezza, è un buon segnale: significa che il problema è stato preso sul serio. Se si saltano tutti, i rischi di insuccesso aumentano.

Proprio in questi giorni, ho ricevuto una mail con The Management Tip of the Day di Harvard Business Review, distillata dall'articolo di David De Cremer “When Developing an AI Strategy, Beware the Urgency Trap”, che dice:

If your AI initiatives aren’t delivering meaningful results, the problem may not be the technology, but the way you’re approaching it. Instead of chasing short-term efficiency, use AI to strengthen your organization’s long-term strategy.

Start with purpose. Before choosing tools, define the value you want to create. Ask yourself which problems matter most to your mission, where people add unique value, and how AI can support that work instead of simply accelerating existing processes.

Resist the urgency trap. Don’t let pressure to move quickly dictate your AI strategy. Fast deployments often overlook the skills, processes, and cultural changes needed for lasting success. Give people time to learn, adapt, and build trust in new ways of working.

Use AI to advance your vision. Treat AI as part of a broader transformation, not an isolated productivity tool. Align initiatives across teams so they help employees make better decisions, collaborate more effectively, and create greater value over time.

Dice le stesse cose con parole diverse. Segno che sono osservazioni di buon senso, maturate nella pratica. Temi su cui vale la pena riflettere e lavorare.

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 post in tre frasi

1. Le imprese stanno investendo nell’AI a ritmi senza precedenti, ma non sanno se sta funzionando.

2. Le (principali) ragioni sono due, e si sovrappongono: dati e processi non pronti da una parte, metriche assenti dall’altra.

3. La via d’uscita non è operare solo sul fronte del taglio degli investimenti, ma ammettere che una parte cruciale del lavoro l’abbiamo saltata e che, senza quella, ogni numero sul ROI è un’opinione travestita da dato.

Alla ricerca di valore

C’è una frase che circola nelle scuole di marketing da oltre un secolo. È attribuita a John Wanamaker, pioniere del retail americano a cavallo tra l’Ottocento e il Novecento (sebbene l’attribuzione sia incerta). Suona così: “Metà del denaro che spendo in pubblicità è sprecata; il problema è che non so quale metà.”

Quando la sento citata, penso alle riunioni con i CEO e i CFO delle imprese italiane degli ultimi diciotto-ventiquattro mesi — riunioni in cui si parla di investimenti in AI, di pilot e di trasformazioni in corso. Wanamaker, almeno, aveva l’onestà di dirlo: spendo, una parte è sprecata, non so quale. Non so quanti dei CFO che ho incontrato lo direbbero con quella nettezza, ma sotto la superficie del racconto la stessa onestà fatica a emergere. La volontà di essere chiari c’è; mancano i dati per esserlo.

Vediamo perché.

Una fase concitata e una domanda scomoda

Il punto di partenza è duplice. Da una parte, l’AI è il fenomeno di investimento aziendale più rapido che ricordi. Dall’altra parte, quando si chiede al management “qual è stato l’effetto?”, la risposta più frequente è un’esitazione, una qualificazione, un rinvio. Non si tratta di un’impressione mia. Arriva da fonti diverse, tutte indipendenti e degli ultimi mesi.

Provo a leggere queste fonti da due punti di vista che mi sembrano i più produttivi.

1. Molti progetti sono partiti senza una base adeguata, perché i dati e i processi delle imprese non erano ancora pronti.

2. Anche dove la base c’è, non sappiamo quantificare i benefici, o perché non ci sono, o perché non siamo capaci di misurarli.

I due punti di vista non si escludono. Si rafforzano.

Progetti senza base: il problema sta nei dati e nei processi

La fonte più recente e più articolata è una survey di Bain & Company, ripresa da Bloomberg e commentata da Entrepreneur all’inizio di giugno. Il campione è solido: 951 grandi aziende in 9 settori.

AI is supposed to save companies billions. So far, it isn’t. […] Among companies measuring their AI savings, 40% saw reductions of just 10% or less. That’s well below what most were expecting.

In altre parole, quattro aziende su dieci, fra quelle che almeno provano a misurare, ottengono risparmi inferiori al 10% rispetto alle proiezioni. È un divario notevole, ma quel che mi colpisce di più viene subito dopo:

The disappointing returns matter because 44% of companies surveyed are funding their next wave of generative and agentic AI investments with those projected savings. Bain calls the strategy “a circular bet with a structural leak.”

“Una scommessa circolare con una falla strutturale.” La formulazione è di Bain stessa, non di una stampa allarmistica. Significa che quasi la metà delle imprese sta finanziando il prossimo round di investimenti in AI con risparmi proiettati dal round precedente, risparmi che, come abbiamo appena visto, si discostano dalle proiezioni. Quando una scommessa si autorifinanzia con un ritorno che non arriva, il problema e il rischio sono strutturali.

Bain pone una domanda che si poteva porre al centro del rapporto: perché i risparmi attesi non si materializzano? La risposta è la parte più importante del documento.

the No. 1 reason AI programs underperform isn’t budget or strategy. It’s that most companies’ data is so disorganized their AI can’t get to it. That problem, Bain warned, “should be making executives uncomfortable.”

I dati delle imprese sono talmente disorganizzati che l’AI non riesce ad accedervi. Bain dice che la cosa “dovrebbe mettere a disagio gli executive”. Sospetto che il disagio arrivi, quando arriva, troppo tardi, dopo che la spesa è già impegnata e i pilot sono già stati lanciati.

La lettura di Bain non è isolata. Maria Korolov, su CIO.com a fine giugno, ha pubblicato un’analisi sull’adozione dei data lakehouse come infrastruttura per l’AI aziendale.

L’idea di fondo è semplice: senza un livello dati unificato e accessibile, qualsiasi modello AI non funziona o funziona male. Prasad Pore, analista di Gartner, dichiara nell’articolo un tasso di adozione del 65% dei data lakehouse tra i clienti dell’azienda, “a very strong number in a short time”. Chi ha capito che, senza un livello dati unificato, l’AI non scala, sta riparando la fondazione. Chi non l’ha capito continua a costruire “case sulla sabbia”, come recita la parabola evangelica.

A questo aggiungerei una considerazione tratta dalla mia esperienza. I progetti AI che ho visto fallire non sono falliti per problemi del modello. Sono falliti perché le persone incaricate di farli funzionare non avevano le competenze e l’accesso ai dati nei tempi e nei formati richiesti. Quando il dato c’era, era distribuito su quattro sistemi diversi, con definizioni semantiche incompatibili, regole di aggiornamento asincrone, granularità differenti. Le riunioni di kickoff parlavano di prompt engineering. Sei mesi dopo si parlava di pipeline per l’acquisizione e l’organizzazione delle informazioni.

Misurare ciò che non si sa misurare

Il secondo punto di vista è più sottile e, secondo me, più interessante perché va oltre l’aspetto tecnico-infrastrutturale e raggiunge il cuore del funzionamento delle imprese. Anche laddove i dati esistono e i processi funzionano, le imprese faticano a stabilire se l’AI stia generando valore. Il caso più citato è uno studio del MIT Media Lab dell’estate scorsa (The GenAI Divide: State of AI in Business 2025, luglio 2025), ripreso a settembre 2025 da Harvard Business Review (HBR) in un articolo sui workslop:

a recent report from the MIT Media Lab found that 95% of organizations see no measurable return on their investment in these technologies.

La cifra del 95% è circolata molto e va presa con la cautela che il rapporto stesso indica: “non vedono un ritorno misurabile”. La distinzione è importante. Una cosa è dire che gli investimenti in AI non stanno producendo valore: un’altra, ben diversa, è dire che lo stanno producendo ma non siamo capaci di quantificarlo. Sono due situazioni che richiederebbero risposte diverse: nel primo caso, ripensare l’approccio; nel secondo, continuare a investire, dotandosi però degli strumenti per misurare ciò che già accade. Davanti a un board che chiede cifre, però, le due situazioni collassano in una sola: in entrambi i casi non si hanno numeri da portare e, in entrambi i casi, quanto affermato suona come “non sappiamo se sta funzionando”. La distinzione resta sostanziale, ma diventa inutilizzabile come argomento a sostegno del prossimo round di investimenti. La differenza c’è, conta e, nondimeno, scompare nel momento in cui dovrebbe pesare.

Una conferma indiretta arriva da una survey di Gartner condotta a fine 2025 (pubblicata a maggio 2026) e commentata da CIO Magazine:

Eighty percent of large enterprises surveyed by Gartner have reported workforce reductions after launching automation projects, with the average reduction between 1% and 15%. The IT analyst firm, however, has found no correlation between layoffs and AI ROI.

Otto grandi imprese su dieci hanno effettuato tagli di personale dopo aver avviato iniziative di automazione basate sull’AI. Nessuna correlazione, però, fra i tagli e il ROI. Helen Poitevin di Gartner lo dice in modo molto netto:

“You would anticipate that those who are getting the most ROI maybe then are able to cut the most, but that’s not what we see. […] There seems to be no link between laying people off and getting ROI from AI investments.”

È un punto su cui mi sono già soffermato a febbraio, parlando di AI-washing. La logica “meno teste = più ROI” trasforma un’aspettativa ancora da verificare in decisioni operative concrete: le imprese tagliano personale contando su risparmi che l’AI dovrebbe generare. Il rapporto di Gartner mostra che quei risparmi non si stanno materializzando e che, quando arrivano, non sono correlati ai tagli. Le decisioni, intanto, anticipano il dato che dovrebbe giustificarle.

HBR di giugno 2026, in un articolo dal titolo “How People Are Really Using AI in 2026” a firma di Marc Zao-Sanders, mette nero su bianco la stessa difficoltà:

Explicitly stated ROI like this is rare in the data we have—growth is more often claimed anecdotally.

I casi di ROI esplicito sono rari nei dati. Quando si trovano (sales/marketing, +20–30% di conversione su campagne testate con agenti AI ottimizzati), sono dichiarazioni aneddotiche più che evidenze sistematiche. Fuori da questi pochi casi, le affermazioni sul ROI dell’AI restano impressionistiche: parlano di sensazioni, mentre servirebbero misurazioni.

McKinsey, in un’analisi sull’AI paradox nei consumi europei, formalizza la difficoltà in una frase che vale come sintesi di tutto il filone:

[…] Boards want to understand where AI investments are going. CFOs want to see measurable returns. Strategy teams point to an expanding set of AI initiatives across marketing, customer experience, supply chain, and technology development. Yet when pressed on bottom-line impact, many organizations still give the same answer: It is too early to tell.

“It is too early to tell.” La frase appare cortese, ma è la confessione di un’incapacità di misurazione che si sblocca soltanto se, a un certo punto, si decide di costruire le metriche che oggi non esistono. Misurare l’AI guardando solo al costo dei token, alla latenza, all’utilizzo delle licenze e al numero di pilot in corso equivale a misurare l’output del sistema tecnico. L’outcome del business è un’altra cosa e si misura in modo ben diverso.

A febbraio scorso, in un post sullo sviluppo software assistito dall’AI, scrivevo che la produttività in quel dominio non è misurabile guardando soltanto alla fase di coding. La stessa logica vale, in scala, per l’impresa: la produttività dell’AI va misurata alla scala giusta, quella del processo o della catena di valore. Misurare solo la fase in cui il modello produce l’output è troppo poco; pretenderne gli effetti netti sull’EBIT aziendale è troppo. La granularità utile sta nel mezzo: la durata di un ciclo di vendita, il tempo di chiusura di una pratica, il numero di interventi necessari per completare un’istanza del processo.

Il “baratro della disillusione”

Resta una nota sulla curva del ciclo dell’hype di Gartner. The Economist ha pubblicato a dicembre, citando S&P Global, un dato alquanto significativo:

the share of companies abandoning most of their generative-AI pilot projects has risen to 42%, up from 17% last year.

Il 42% delle imprese ha abbandonato la maggior parte dei propri pilot generativi. Un anno prima era il 17%. La pendenza è netta. La collocazione sulla curva di Gartner del baratro della disillusione (trough of disillusionment) è netta e non sorprende: è un meccanismo empiricamente consolidato. Quel che mi interessa, però, è che il baratro è il momento in cui scoperchiamo i problemi che ho descritto sopra: i dati, i processi, le metriche. Chi resta dentro la curva, senza porsi la domanda del perché, non vede il ritorno e rischia di sospendere gli investimenti proprio mentre la vera maturazione potrebbe cominciare a dare i primi risultati. Chi si ferma a chiedersi perché e accetta la risposta scomoda, che riguarda dati, processi e metriche, può ripartire con un setup diverso e raggiungere il plateau di produttività con un vantaggio che oggi non si vede.

L’onestà intellettuale di cui abbiamo bisogno

Torno a Wanamaker per una sola riga. La sua frase ha attraversato un secolo perché contiene una postura: l’onestà intellettuale di chi sa di non sapere. Il problema è che facciamo finta di sapere. Le presentazioni dei vendor le fanno per mestiere; i board le fanno per fiducia; gli executive le fanno per inerzia, perché ammettere l’incertezza significa esporsi. L’unica cosa peggiore di non sapere quanto stiamo spendendo bene è raccontare che lo sappiamo.

Per questo la responsabilità non ricade interamente su una sola parte. Le imprese sono partite senza basi solide perché hanno operato in un mercato che premiava la fretta: vendor che hanno venduto risparmi rapidi, board che hanno chiesto numeri prima del tempo, una curva di hype che ha punito la prudenza. La trasformazione digitale saltata è responsabilità dell’impresa. Il contesto che l’ha resa visibile solo oggi è frutto di una responsabilità collettiva.

Per approfondire

[1] Bain & Company, Your AI Budget Is Growing. Your Returns Aren’t. Here’s Why, giugno 2026. https://www.bain.com/insights/your-ai-budget-is-growing-your-returns-arent-heres-why/

[2] Maria Korolov, “Data lakehouses are becoming foundations for enterprise AI”, CIO.com, giugno 2026. https://www.cio.com/article/4184051/data-lakehouses-are-becoming-foundations-for-enterprise-ai.html

[3] MIT NANDA (MIT Media Lab), The GenAI Divide: State of AI in Business 2025, luglio 2025 (release: 16 agosto 2025). https://nanda.media.mit.edu/ai_report_2025.pdf

[4] “AI-Generated ‘Workslop’ Is Destroying Productivity”, Harvard Business Review, settembre 2025 — riprende lo studio del MIT al punto [3]. https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity

[5] “AI-driven layoffs aren’t making business sense”, CIO, maggio 2026 — commenta la survey Gartner sui tagli del personale dopo l’automazione, con interventi di Helen Poitevin sul nesso tagli/ROI dell’AI. https://www.cio.com/article/4171054/ai-driven-layoffs-arent-making-business-sense.html

[6] Marc Zao-Sanders, “How People Are Really Using AI in 2026”, Harvard Business Review, giugno 2026. https://hbr.org/2026/06/how-people-are-really-using-ai-in-2026

[7] McKinsey & Company (QuantumBlack), The AI paradox in Europe’s consumer industries: More spending, elusive impact, 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-ai-paradox-in-europes-consumer-industries-more-spending-elusive-impact

[8] The Economist, sulla quota di imprese che abbandonano i pilot generativi (42% nel 2025, 17% l’anno prima), citando S&P Global, dicembre 2025. Dato originale: S&P Global, “Generative AI shows rapid growth but yields mixed results”, ottobre 2025. https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results

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

La tesi che ne derivava, secondo cui due filosofie regolatorie fossero inconciliabili, era netta. Ma in coda alla sintesi c’era una nota a margine che a marzo era passata quasi inosservata: alcuni segnali (il Digital Omnibus allo studio, il ritiro della direttiva sulla responsabilità IA) suggerivano che l’UE stesse iniziando a ripensare la propria posizione. L’analisi la presentava come un’ipotesi.

L’UE alleggerisce

Il 7 maggio, Consiglio, Parlamento e Commissione hanno raggiunto un accordo politico provvisorio sul cosiddetto Digital Omnibus on AI, un pacchetto di modifiche all’AI Act che posticipa le scadenze e semplifica alcuni passaggi. Gli obblighi per i sistemi ad alto rischio elencati nell’Annex III sono rinviati al 2 dicembre 2027; quelli per l’AI incorporata nei prodotti regolati dall’Annex I al 2 agosto 2028.

Il rinvio è subordinato alla conformità agli standard in corso di elaborazione da parte di CEN-CENELEC. La Commissione, nei fatti, ha riconosciuto che imporre obblighi senza gli standard tecnici di riferimento crea una compliance impossibile da onorare: una posizione che da un anno l’industria europea sosteneva e che Mario Draghi aveva messo per iscritto nel rapporto del settembre 2024.

C’è poi una semplificazione di merito del concetto di safety component. Un sistema AI che si limita ad assistere l’utente o ad ottimizzare la prestazione di un sistema più ampio non sarà classificato automaticamente come ad alto rischio, se il suo malfunzionamento non genera rischi per la salute o la sicurezza. Un chiarimento che restringe la perimetrazione dell’AI Act ai casi in cui la posta in gioco è sostanziale, escludendo le applicazioni di efficienza operativa che il testo iniziale rischiava di includere.

Gli USA stringono (e di parecchio)

Alcuni fatti recenti hanno cambiato il giudizio su ciò che avviene negli USA.

In primo luogo, il vetting governativo dei modelli prima del rilascio. All’inizio del 2026 il Center for AI Standards and Innovation (CAISI) del Dipartimento del Commercio aveva firmato accordi con Google DeepMind, Microsoft e xAI per valutare i loro modelli di frontiera prima della messa in commercio. A giugno il CAISI aveva completato oltre quaranta valutazioni, rese pubbliche e diventate per ricercatori e policymaker un riferimento condiviso su ciò che i modelli potevano fare. La rotta è cambiata nelle settimane successive alla scoperta che il modello Mythos di Anthropic, precursore dell’attuale Mythos 5, era in grado di individuare e sfruttare vulnerabilità di rete con relativa facilità. Il 2 giugno Trump ha firmato l’executive order Promoting Advanced Artificial Intelligence Innovation and Security, che sposta il vetting dal CAISI a un framework classificato gestito dalle agenzie di national security, impone una revisione governativa di 30 giorni prima del rilascio pubblico di qualunque modello di frontiera, e ordina al CAISI di smettere di pubblicare le proprie analisi: la supervisione resta, ma diventa opaca.

In secondo luogo, le partecipazioni pubbliche in aziende private. Il 5 giugno, Trump ha confermato che l’amministrazione sta esplorando un equity stake in OpenAI e in altri leader del settore. Pochi giorni dopo, il vicepresidente JD Vance, nel podcast di Steven Bartlett, ha risposto a una proposta di Bernie Sanders sull’azionariato dei lavoratori delle grandi aziende AI dicendo che «al presidente, fra l’altro, l’idea piace. Sì, gli piace». La modalità tecnica a cui l’amministrazione pensa, però, è quella di un sovereign wealth fund americano, con quote intorno al 9,9% nelle principali aziende di AI. L’amministrazione ha già acquisito partecipazioni in Intel, IBM e in operatori nei settori del quantum e dei minerali critici. Entrare nel capitale dei leader dell’AI cambia la natura dell’operazione: un azionista pubblico del 9,9% inciderebbe sulle decisioni di prodotto, di pricing e di rilascio.

In terzo luogo, l’AI come oggetto di controllo per l’export. Il 12 giugno l’amministrazione ha disposto, per ragioni di sicurezza nazionale, il blocco dell’accesso ai modelli Fable 5 e Mythos 5 di Anthropic da parte di qualunque cittadino straniero, inclusi i dipendenti stranieri di Anthropic. L’azienda ha dovuto disabilitare l’accesso a livello globale per conformarsi e ha contestato pubblicamente il provvedimento, osservando che, se applicato sistematicamente, bloccherebbe il rilascio di qualsiasi modello di frontiera. La misura ha incrinato i rapporti con gli alleati. È un trattamento da arma da esportazione: l’AI entra nel perimetro dei controlli di sicurezza riservati ai semiconduttori, alle tecnologie duali e ai materiali strategici.

Il giusto sta nel mezzo

I due estremi si sono mossi l’uno verso l’altro, in modi e con culture diversi. L’UE ha riconosciuto che gli obblighi imposti prima degli standard tecnici non possono essere rispettati, sono controproducenti e che la tassonomia del rischio va ricalibrata. Gli USA, partiti dall’astensione dichiarata, sono passati a misure che non hanno equivalenti nel quadro europeo: lo Stato che entra nel capitale delle aziende private, l’export control sui modelli AI applicato anche ai dipendenti stranieri delle aziende americane stesse.

La lezione è che nessuna delle due posizioni di partenza era sostenibile nel lungo periodo. Regolare prima di sapere genera obblighi che non si possono adempiere; astenersi per principio lascia il campo a interventi di emergenza fatti con strumenti pensati per altro: il Defense Production Act, i controlli export-style, le acquisizioni governative nel capitale di aziende strategiche.

Si può obiettare che le mosse americane hanno origini geopolitiche più che regolatorie, e che la rivalità con la Cina conta più della teoria del laissez-faire. Vero, ma l’effetto regolatorio è lo stesso: lo Stato è nel capitale delle aziende AI e nella decisione su quali modelli rilasciare e a chi.

Quello che serve è una regolazione capace di evolvere: principî stabili e strumenti rivedibili, da aggiornare quando la realtà tecnologica cambia. È quello che entrambe le sponde dell’Atlantico stanno cercando di costruire, sotto la pressione dei fatti, mentre la conversazione pubblica continua a discutere di chi sia più “amico dell’innovazione”. È una domanda che, a giugno 2026, ha perso gran parte del suo significato.

A marzo, in calce a quel confronto, era rimasta a margine l’ipotesi di una “dinamica convergente paradossale” tra le due sponde. Tre mesi dopo, l’ipotesi è diventata il titolo della storia e si è materializzata in modo più netto di quanto immaginassi: l’UE ha allentato i suoi obblighi più rapidamente del previsto, gli USA hanno introdotto controlli che a marzo non vedevo all’orizzonte.

Il centro è quello che resta dopo aver scartato le due posizioni estreme: l’UE si è accorta che la propria era inapplicabile nei tempi previsti, gli USA che la propria li obbligava a improvvisare.

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

Nadella is right about the loop. He presents it in the manifesto as a competitive strategy. Every firm should own its loop; otherwise, value flows to the few companies that own the models. The framing is strategic, the audience is the CIO (and CEOs), and the call to action is to build infrastructure, competence, and processes around AI rather than buy it off the shelf.

The manifesto does one thing well and skips one thing entirely. It names a real asset, but it does not explain why that asset is real in the first place. Not the strategic reason, the structural one. Why is owning a loop an actual asset, and not just a managerial aspiration?

On April 27, 2026, I submitted a paper for publication that discusses these questions. The paper was written from the perspective of LLM epistemology, not from the economics of the AI market. It focuses on Software Engineering, and within it on coding agents, because that is where a structural vacuum is most visible (and where most of the media attention is concentrated).

These three properties are architectural, not application-specific, which is why the framework derived from them applies to any work in which an organization wants to govern an agent rather than supervise it on a case-by-case basis. The tradition the paper rests on is decades old; what the paper adds is a structured account of why the architecture itself requires external knowledge by construction, not because of the current state of the technology.

The mechanism Nadella names but does not explain

Three properties of a large language model, taken together, produce the condition that makes Nadella’s loop necessary. Once they are on the table, the loop stops being a generic declaration and becomes a description of the work that needs to be done.

The first property is probabilistic generation. An LLM does not compute; it generates. Every output is a navigation over a probability distribution conditioned on training and context. The model carries no internal reference for whether its output is adequate. Correctness lives outside the model, as a specification, a test, a domain constraint, or an organizational rule. Any judgment of adequacy requires an external reference. The model cannot supply it. No improvement in scale changes the situation, because what is missing is not training data but a reference against which the output can be checked. That reference is rarely fixed: it varies by context, evolves with the project, and has to be negotiated among the people who hold the relevant knowledge.

The second property is agnosticism. The model has absorbed text and code from the public body of knowledge. It has not absorbed organization-specific knowledge: the risk models of this bank, the legacy constraints of this system, the tacit understanding that has never been articulated, not even by the people who hold it. Part of this can be reduced with training, retrieval, and fine-tuning. Part of it cannot. Organizational knowledge is continuously renegotiated, semantically defined by the practice it describes, and permanently inconsistent in functional ways. Training presupposes a stable ground truth that organizational knowledge lacks. A model that forces this material into a consistent representation assumes a coherence the organization itself does not possess.

The third property is statelessness. Within one session, the model retains a working footprint. Across sessions, it retains nothing. The architectural decision made last Tuesday, the domain constraint introduced by the expert last week, and the trade-off accepted last month: none of them survives a session boundary unless they have been externalized as a persistent artifact. New LLM mechanisms being introduced extend the ability to retain knowledge, but they cannot entirely fill the gap or provide structure and governance.

None of these three properties can be eliminated by more training data or by larger models (scaling). The vacuum is a condition of the conceptual architecture, not a gap that closes with scale. Each property resists reduction for its own reason. Probabilistic generation lacks an internal reference for correctness because correctness lives outside the model by construction, no matter how much training it has received. Agnosticism toward organization-specific knowledge resists training because that knowledge is continuously renegotiated by the practice that holds it, and no stable corpus exists for a training run to absorb. Statelessness across sessions is architectural rather than transitional. The most sophisticated state-management mechanisms are powerless if the first two properties are not addressed first: without an external reference for correctness and without organization-specific knowledge, there is nothing of substance for memory to preserve. And storing “a state” is not the same as representing it correctly and completely. The knowledge must be captured in a structured, navigable form for the agent. Representation is what makes preserved knowledge usable. The conclusion is the same in all three cases: scaling produces a larger generative engine, not one that holds external reference, organization-specific knowledge, or project memory inside itself.

What goes inside the loop, and who owns it

The loop is not a monolithic entity. It carries four kinds of knowledge, each with its own source and channel of provision.

Methodological knowledge is the discipline of building correctly: specifications, architectural principles, testing frameworks, and process governance. It is fifty years of accumulated practice, codified as a discipline by Software Engineering.

Domain knowledge is what the system must mean and do in its world. It is held by the people who work in the domain: the clinicians, traders, operators, and analysts. It is partly tacit, often inconsistent, and irreducible to any corpus that lives outside the organization.

Design choices are the project-specific decisions made by the engineer as the system grows: architectural structures, component boundaries, trade-offs, and interfaces. Each choice becomes a constraint on what follows. None of them is elicited from anyone; they are produced and owned by the engineer.

Process choices concern how the work is organized for this project: the adopted lifecycle, the criteria for agent autonomy, and the review structure. They derive from methodological knowledge and must be instantiated for each context.

All four kinds of knowledge require reification. They must be materialized as persistent, accessible artifacts. Knowledge that exists only in someone’s head, or in a conversation that ended last week, does not exist for a stateless agent. Reification is not documentation overhead. It is the condition under which any knowledge becomes operational for the system at all.

Three actors structure the provision of all four. The domain expert is the source of semantic knowledge. The AI agent is the executor. The software engineer is the mediator and the custodian: the one who knows what to give the agent, how to structure it, and when to override its output.

Where the manifesto stops short

Nadella collapses these four kinds of knowledge into two (“human capital” and “token capital”) and the three actors into one (“humans”). The collapse obscures the real work.

You cannot compound what you cannot distinguish. If methodology, domain, design, and process are one undifferentiated blob, the loop has nothing to grip. The engineer’s role becomes indistinguishable from the domain expert’s; the domain expert becomes a generic stakeholder; and the agent is asked to do work that requires structured input nobody is responsible for producing. The result is what already shows up in many enterprise AI deployments: a generic agent dropped into a workflow with the assumption that judgment will somehow emerge from use.

The strategy and asset Nadella names are real, but the operational shape of that asset is not in the manifesto. The shape is the four levers, the three actors, and the reification that makes the loop into something an organization can own. Without that shape, the loop is a phrase a CIO (or CEO) repeats in steering meetings while nothing changes underneath.

Strategy and mechanism

Nadella has packaged the architecture that compensates for his company’s generic model into a statement. The statement does something the architecture itself cannot do: it sells. The statement invites a CIO to spend money on infrastructure that doesn’t yet have a shape. The conceptual architecture tells the CIO what shape the infrastructure must have, who must build it, and what knowledge must be reified for it to work. The first sells a vision. The second describes a job to be done.

Nadella’s manifesto is not empty. The loop is real, the warning about value concentration is real, and the principle that owning a learning loop is the new IP of the firm is correct. Correctness without structure is rhetoric. The asset Nadella names is the asset my paper describes. The difference is that the paper explains why building the asset is not optional and what it takes to do so.

This post was written with the assistance of Claude. The ideas, positions, and reasoning are mine.

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 9 giugno 2026, Anthropic ha lanciato Claude Fable 5 e Mythos 5, gli ultimi modelli della propria famiglia: Mythos 5 come modello di punta, Fable 5 come versione pubblica accessibile. Tre giorni dopo, il 12 giugno alle 17:21 di Washington, è arrivato un ordine del governo americano. Il comunicato ufficiale di Anthropic lo riporta con parole nette: «Il governo USA, citando le autorità di sicurezza nazionale, ha emesso una direttiva di controllo all’esportazione per sospendere ogni accesso a Fable 5 e Mythos 5 da parte di qualsiasi cittadino straniero, dentro o fuori gli Stati Uniti, inclusi i dipendenti stranieri di Anthropic». Dovendo bloccare l’accesso a tutti i “foreign national” (categoria che include una parte significativa della sua stessa forza lavoro), Anthropic ha concluso che l’unico modo per essere compliant era spegnere i modelli per tutti i suoi clienti. Il motivo invocato è una vulnerabilità nelle protezioni del modello (un aggiramento, in gergo “jailbreak”) che Anthropic considera di minore entità, replicabile su modelli commerciali concorrenti e priva di danni dimostrati.

Si può osservare che si tratta di un blocco temporaneo. Anthropic dichiara di voler ripristinare l’accesso «il prima possibile». La causa tecnica è un aggiramento, di portata limitata, delle protezioni del modello; il governo USA potrebbe rivedere la decisione entro pochi giorni.

Di fronte a questo scenario, due fatti diventano evidenti. La vicenda Fable mostra la debolezza dell’UE come attore tecnologico e la dipendenza dell’Europa dal sistema politico-economico americano. L’UE, com’è oggi, dispone di leve limitate per attenuare tale dipendenza. I programmi che finanziano ricerca e tecnologia, da Horizon Europe (il programma europeo di ricerca e innovazione, circa 95 miliardi su 2021-2027) al Chips Act (il piano europeo sui semiconduttori) e all’European Innovation Council (l’agenzia UE per l’innovazione), esistono e contano, ma sono di un ordine di grandezza inferiore agli investimenti privati USA e hanno la forma di un sussidio alla ricerca, non di capitale di rischio. L’UE ha un proprio regime di controllo all’esportazione e altri strumenti di pressione commerciale (lo strumento anti-coercizione economica, le sanzioni, il regolamento sui sussidi esteri), ma manca il monopolio tecnologico che dà a Washington la leva per spegnere modelli AI nel mondo. L’Europa, come continente, avrebbe gli ingredienti per costruire un proprio peso: capitali, industria, filiere della potenza di calcolo. Non li ha valorizzati né sfruttati.

Eppure la reazione più diffusa prende la direzione opposta. Un riflesso automatico: «colpa dell’UE». L’AI Act, il GDPR, Bruxelles. È una scorciatoia che fa due cose contemporaneamente. La prima è confondere due entità distinte: l’UE, organismo politico con leve precise, e l’Europa, continente con una storia industriale, finanziaria e sociale che precede e supera Bruxelles. La seconda, conseguenza della prima, è chiamare in causa un livello istituzionale (l’UE) per non guardarne uno molto più scomodo. È da questa confusione che bisogna partire.

Nota: in questo post non discuto né degli aspetti tecnici né dell’efficacia di GenAI. Ne parlo in altri post. Qui considero solo gli aspetti relativi alle politiche pubbliche, lasciando da parte, per questa volta, le considerazioni di merito.

UE non è Europa

L’UE è un organismo politico. Ha tre istituzioni principali (Commissione, Parlamento, Consiglio) e leve definite: regolazione del mercato unico, bilancio comunitario pari a circa l’1% del PIL aggregato, politica commerciale, antitrust, alcuni programmi di finanziamento (Horizon, Recovery Fund). Non emette debito sovrano. Non gestisce sistemi pensionistici. Non possiede banche. Non decide sugli investimenti delle assicurazioni. Non finanzia i sistemi universitari. Non controlla l’azionariato delle imprese.

L’Europa è una realtà molto più grande e articolata. È un continente con 27 Stati membri dell’UE, oltre al Regno Unito, alla Svizzera e alla Norvegia. Cinquecento milioni di persone. Mercati di capitale costruiti su trenta ordinamenti nazionali, con regole fiscali, di vigilanza e di trasparenza che ogni Stato continua a scrivere per sé. Fondi pensione gestiti a Roma, Berlino, Parigi, Amsterdam. Banche che rispondono alle assemblee e ai regolatori nazionali. Università finanziate dagli Stati. Industrie con azionariato e governance disegnati nei singoli paesi.

Quando un CEO o un editorialista dice «colpa dell’UE» nel contesto dell’AI, intende quasi sempre una di queste due cose: l’AI Act, entrato in vigore progressivamente dal 2025, o il GDPR. Sono critiche regolatorie. Hanno ragioni legittime (la frammentazione applicativa, i costi di compliance, l’ambiguità su alcune categorie di modelli) e altre meno legittime, soprattutto quando la regolazione viene presentata come causa di un divario di scala miliardaria. Il problema dell’AI in Europa è il capitale, non la regolamentazione. E il capitale, in Europa, è materia degli Stati, dei fondi pensione, delle banche, degli azionariati. È materia dell’Europa, non dell’UE. Quanto meno, ad oggi.

I numeri del continente

Il rapporto di Mario Draghi, The Future of European Competitiveness (settembre 2024), ha fissato un dato che vale la pena leggere con cura: il 61% dei finanziamenti globali alle start-up AI va a società statunitensi, il 17% va in Cina, il 6% nell’Unione Europea. Sul quantum computing il quadro è peggiore: 50% USA, 5% UE.

Lo Stanford AI Index Report 2026 aggiorna e amplia il quadro. Nel 2025, negli Stati Uniti l’investimento privato in AI è stato di 285,9 miliardi di dollari, mentre in Cina di 12,4 miliardi. Tutta l’Europa messa insieme (UE, Regno Unito, Svizzera e Norvegia) si ferma a 20,9 miliardi, pari a un quattordicesimo di quello degli Stati Uniti. Se si guarda alla sola AI generativa, l’asimmetria diventa grottesca: 163,6 miliardi negli Stati Uniti, e Cina ed Europa combinate 4,7 miliardi. Anche nel lungo periodo il quadro non cambia: il cumulato 2013-2025 vede gli Stati Uniti a 757,3 miliardi, contro un’Europa che, sommando i paesi pubblicati nel rapporto (Regno Unito 34,1, Germania 17,2) e stimando in modo generoso il resto del continente, non supera gli 80-100 miliardi, tra un settimo e un nono degli Stati Uniti. La crescita anno su anno tra 2024 e 2025 ha amplificato il divario: USA +160%, Cina +32%, Europa +7%.

Due osservazioni cambiano la lettura del problema. La prima: i numeri si riferiscono al continente europeo, non all’UE. Il Regno Unito è fuori dall’Unione dal 2020 e non ha colmato il proprio divario con gli Stati Uniti più rapidamente rispetto ai principali paesi dell’UE. La Brexit non ha decuplicato il capitale di rischio nel Regno Unito. Se la regolazione UE fosse la causa del divario, ci aspetteremmo che chi è fuori volasse. Non vola.

La seconda osservazione riguarda la scala. Anthropic, in un solo round di finanziamento (i 30 miliardi di febbraio 2026), raccoglie più di quanto tutto il capitale di rischio AI continentale (UE + UK + Svizzera) raccolga in un anno intero. Il progetto Stargate, annunciato a gennaio 2025 da OpenAI, SoftBank, Oracle e MGX (fondo sovrano emiratino), prevede un investimento fino a 500 miliardi di dollari in data center per l'AI negli Stati Uniti nei quattro anni successivi all'annuncio (con 100 miliardi mobilitati immediatamente). Cinquecento miliardi sono più del PIL del Belgio o della Polonia. Sono ordini di grandezza che nessuna correzione regolatoria può colmare. Quando i numeri sono così, la conversazione su “regolamentare meno per crescere di più” si fa surreale: anche raddoppiando il capitale di rischio AI europeo da un anno all’altro, resteremmo a un decimo di quello degli Stati Uniti.

Il quadro, però, non è statico. A febbraio 2025, il presidente Macron ha annunciato a Parigi un piano AI nazionale da 109 miliardi di euro, un mix di impegni pubblici e capitali esteri, il più grande mai annunciato in Europa. La quota di AI nel capitale di rischio europeo è salita al 31% secondo i dati più recenti (Atomico, State of European Tech), segno di una riallocazione delle priorità del VC continentale. Helsing, la start-up di AI per la difesa tedesco-britannica, ha chiuso a giugno 2025 un round da 600 milioni di euro, diventando un secondo campione europeo di frontiera dopo Mistral, in un settore strategico per l’autonomia. Sono segnali che l’Europa sta reagendo. Ma la scala resta di un ordine di grandezza inferiore rispetto a quella degli Stati Uniti, e la tesi del post non cambia: il problema è il capitale, non la regolamentazione.

Le cause sono nazionali

La diagnosi non è nuova. McKinsey, nel rapporto Accelerating Europe’s Competitiveness (gennaio 2024), ha quantificato il divario strutturale tra Europa e Stati Uniti: il capitale di rischio europeo è circa un quarto di quello americano; le grandi imprese USA hanno investito circa 700 miliardi di euro in più rispetto alle pari europee, tra capex e R&D, nel periodo 2015-2022 — pari a circa 3.000 euro pro capite di differenza. Tutte queste asimmetrie hanno una caratteristica in comune: non si risolvono a Bruxelles. Sono il risultato di trent’anni di scelte compiute nelle capitali nazionali e nei consigli di amministrazione di banche, assicurazioni e fondi pensione europei.

Prendiamo i fondi pensione. In Europa, solo l’11% della raccolta di capitale di rischio proviene dai fondi pensione (Invest Europe, 2024). Negli Stati Uniti è la principale fonte di capitale di rischio, poiché i grandi fondi pubblici e privati allocano una quota stabile al capitale di rischio e ai fondi di investimento privati. La direttiva europea sulle assicurazioni (Solvency II) e gli altri regolamenti europei sulla previdenza pongono vincoli, è vero. Ma la quota effettivamente investita in capitale di rischio dai grandi fondi pensione tedeschi, italiani, francesi e olandesi è quasi sempre ben al di sotto dei tetti consentiti. La scelta di non investire in tecnologie ad alto rischio è una decisione dei consigli di amministrazione dei fondi, non un divieto imposto da Bruxelles. Allianz, AXA, Generali e Aviva possono acquistare azioni di Anthropic. Non lo fanno. E quando lo fanno, con altre tecnologie, vendono spesso prima che la posizione maturi.

Stesso discorso per le banche. I grandi gruppi bancari europei rispondono alle assemblee dei rispettivi paesi. Il loro modello di business privilegia l’intermediazione commerciale e l’investimento in titoli di Stato. Il finanziamento azionario di lungo periodo per le start-up tecnologiche è marginale nei loro bilanci e raramente strategico per le loro direzioni. Anche in questo caso, nessuna direttiva impone tale allocazione: è una scelta gestionale ripetuta per decenni.

Il capitale “paziente” è la categoria che sintetizza il problema. Il capitale di rischio americano investe con orizzonti di 7-10 anni, accetta tassi di mortalità altissimi nel portafoglio e si aspetta che pochi exit colossali ripaghino l’intero fondo. Il capitale europeo, anche quando arriva, vuole un rientro più rapido e un rischio più basso. Cassa Depositi e Prestiti in Italia, KfW in Germania e Bpifrance in Francia sarebbero strumenti potenti: istituzioni pubbliche con bilanci ingenti e un mandato a lungo termine. Vengono usati soprattutto per stabilizzare le situazioni di crisi industriali, per i salvataggi e per le infrastrutture. Non per spingere il rischio dove il privato non arriva. Nel 1993, il programma Yozma, lo strumento pubblico israeliano di capitale di rischio, ha dimostrato cosa significhi farlo: 100 milioni di dollari di fondi pubblici hanno attratto 150 milioni di dollari di capitali privati e hanno fatto nascere l’industria del capitale di rischio israeliana, che oggi finanzia ogni anno più start-up AI del nostro continente.

Aggiungo un’osservazione che deriva dalla mia esperienza al Politecnico di Milano e da quella maturata con Cefriel. Le start-up AI italiane buone (ne ho viste passare diverse negli ultimi anni) non chiudono perché l’AI Act le strangola. Spesso vendono ai gruppi USA o si trasferiscono. Il punto di rottura, nei loro racconti, è quasi sempre lo stesso: round di finanziamento successivi da 30, 50, 100 milioni di euro che non esistono. Si trovano i 2 milioni dei primi finanziamenti; si trovano i 5-10 milioni del round successivo. Sopra quella soglia, il capitale europeo finisce e chi vuole crescere deve attraversare l’Atlantico. Il problema è la profondità di mercato, non la regolamentazione.

L’AI Act è dell’UE. I capitali sono Europa

L’AI Act ha problemi reali. La frammentazione applicativa tra i 27 Stati moltiplica i costi di adeguamento normativo per le PMI. Le definizioni dei modelli generalisti presentano margini di ambiguità che rendono difficile la pianificazione. La forma stessa del regolamento (un atto unico per un campo che evolve ogni sei mesi) è sotto stress. Sono critiche tecniche legittime e una revisione del regolamento è necessaria.

La fotografia di oggi lo dimostra. Anche nell’UE e con l’AI Act, l’AI europea cresce. Mistral, la start-up francese di AI, l’unico campione di frontiera nato nel continente, è pienamente soggetta all’AI Act e ha chiuso a settembre 2025 un round di finanziamento da 1,7 miliardi di euro a una valutazione di 11,7 miliardi; oggi è in trattativa per un nuovo round di circa 3 miliardi a una valutazione di circa 20 miliardi. Anthropic apre quattro uffici nel territorio dell’UE (Dublino, Parigi, Monaco, Milano), oltre ai due fuori dall’UE (Londra e Zurigo). Meta ha a Parigi, dal 2015, uno dei suoi tre laboratori AI principali, FAIR, all’interno della giurisdizione dell’UE. La regolazione non sta bloccando la crescita all’interno dell’UE.

Ma è una crescita a chiaroscuri, troppo lenta rispetto agli ordini di grandezza richiesti. Per quali motivi? Mistral ha trovato i capitali per scalare aprendosi a fondi e gruppi americani (Nvidia, Andreessen Horowitz, General Catalyst) accanto ai partner europei (ASML, il monopolista olandese delle macchine per produrre chip, è l’investitore principale con 1,3 miliardi; Bpifrance, la banca pubblica di investimento francese, compare in tutti i round): senza il capitale statunitense il round non sarebbe esistito. I centri di ricerca europei delle big tech USA, dentro l’UE (FAIR di Meta a Parigi, presidi di Anthropic in Irlanda e in Italia) o fuori (DeepMind, il laboratorio AI di Google, e gli hub di OpenAI e Anthropic a Londra, Google Research a Zurigo), restano filiali di gruppi americani che, ovviamente, decidono di allocare risorse, talento e budget a casa propria.

Il discorso «colpa dell’UE» ha due motori. Il primo è interno al continente: la regolazione è un bersaglio comodo perché si può riformare in 12-24 mesi; è materia di Commissione e di Parlamento; è un terreno in cui i governi possono mostrare un risultato. La costruzione di profondità nei mercati di capitale, la riallocazione dei fondi pensione, il riorientamento di Cassa Depositi e Prestiti, KfW, Bpifrance verso il rischio richiedono quindici, vent’anni di politica industriale paziente e impopolare. È più facile attaccare Bruxelles davanti all’opinione pubblica che riformare le banche e i fondi pensione di casa.

Il secondo motore è esterno e va nominato. Gli Stati Uniti, sia l’amministrazione sia le grandi piattaforme, soffiano sul fuoco della narrativa «colpa UE» perché ogni regolamentazione europea che limita Apple, Google, Meta, OpenAI o Anthropic intacca un loro vantaggio competitivo. L’AI Act, il Digital Markets Act, il Digital Services Act e il GDPR vengono attaccati frontalmente da Washington come ostacoli all’innovazione americana. Quando un CEO o un editorialista europeo riprende quella narrativa, sta amplificando una pressione che non nasce dall’interesse del continente.

Cosa servirebbe

Distinguere i livelli serve a capire dove agire. A livello UE, le cose che andrebbero fatte sono note e, in larga parte, indicate nel rapporto Draghi: completare l’unione europea dei mercati dei capitali (sul serio, non in PowerPoint); riformare la direttiva sulle assicurazioni (Solvency II) per liberare l’allocazione del capitale di rischio dei grandi fondi pensione e assicurativi; ampliare il mandato della Banca Europea degli Investimenti e del suo Fondo (EIB-EIF) perché possano co-investire su scala più grande e con un appetito di rischio maggiore; costruire un veicolo europeo di co-investimento dedicato alle tecnologie strategiche. Sono interventi capaci di cambiare le regole del gioco.

A livello degli Stati europei, però, le decisioni più pesanti restano di competenza nazionale. I fondi pensione italiani, tedeschi e francesi possono cambiare l’allocazione già da domani. Non lo fanno perché i loro consigli di amministrazione non vogliono o non sanno farlo. Cassa Depositi e Prestiti può ripensare il proprio mandato e dotarsi di una vera linea di capitale paziente per tech avanzata; lo stesso vale per KfW e Bpifrance. Le grandi banche e le assicurazioni possono diventare azionisti di società tecnologiche di frontiera. I sistemi universitari possono cominciare a pagare i ricercatori a livelli competitivi rispetto alla Bay Area e a Londra: è una scelta di bilancio. Le politiche industriali nazionali possono selezionare le nicchie in cui l’Europa ha un vantaggio (ASML nei semiconduttori, modelli verticali B2B, AI industriale applicata) e concentrare risorse pubbliche e private attraverso strumenti di intervento mirati.

In conclusione

Il 12 giugno, il governo USA ha sospeso Fable e Mythos con una direttiva di controllo all’esportazione. La quotazione in borsa (IPO) che Anthropic ha depositato il 1º giugno avverrà negli Stati Uniti, non a Francoforte. Tra gli investitori della società figurano Google, Amazon, Microsoft, Fidelity, ICONIQ, Lightspeed; nei round più recenti, Altimeter, Dragoneer, Greenoaks, Sequoia, Capital Group, Coatue, GIC. Non Allianz, AXA, Generali, Intesa, Deutsche Bank, BNP Paribas. Allianz e AXA non sono istituzioni dell’Unione Europea: sono assicurazioni europee. Se non figurano nella tabella degli investitori di una società tecnologica valutata 965 miliardi di dollari nell'ultimo round privato (e attesa in IPO a una valutazione molto superiore), non è perché Bruxelles glielo impedisca. È perché il sistema finanziario europeo, costruito in trent’anni di scelte nazionali, predilige gli immobili, i bond sovrani e gli investimenti meno rischiosi. E quando una direttiva di Washington spegne un modello di AI in tutto il mondo, l’Europa scopre che la dipendenza che si è scelta è al tempo stesso tecnologica e politica.

La domanda da farsi non è «cosa ha fatto male Bruxelles». È «cosa hanno costruito Roma, Berlino, Parigi», e cosa hanno costruito le grandi istituzioni private del continente. Il dibattito sull’AI in Europa diventa serio quando si smette di confondere l’UE con l’Europa e si comincia a porre le domande giuste a chi detiene gran parte delle leve decisionali.

P.S. Al WWDC dell'8 giugno Apple ha annunciato che Siri AI non sarà disponibile in Europa su iOS 27, iPadOS 27 e watchOS 27: la disputa con la Commissione UE riguarda il Digital Markets Act, che chiede a Cupertino di rendere accessibili agli assistenti AI di terzi le stesse capacità di sistema concesse a Siri. Apple ha chiesto una deroga di 18 mesi; Bruxelles l’ha respinta. In queste settimane, molti commentatori hanno descritto la richiesta dell’UE come l’ennesima ingerenza regolatoria che ostacola l’innovazione. Alla luce del caso Fable, vale la pena rovesciare la domanda: è proprio sbagliato che l’UE chieda interoperabilità anche per altri motori di AI? Quando il governo USA può spegnere un modello in tre giorni, una clausola che impedisca a una sola società americana di diventare il punto di passaggio obbligato per l’AI nel continente non è più una rottura di scatole. Diventa una forma minima di autonomia. Magari l’unica che l’Europa può costruire al momento.

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 Thirty-Year-Old Déjà Vu

In the summer of 1994, I was at NTNU in Norway with Vincenzo Ambriola and the late Reidar Conradi (a dear friend who is sorely missed). Together, we wrote an article that appeared in ACM Transactions on Software Engineering and Methodology (TOSEM), “Assessing Process-Centered Software Engineering Environments”. It was an attempt to provide a framework for summarizing and assessing all the approaches developed in previous years in the areas of Process Modeling Languages (PMLs), Process-Centered Software Engineering Environments (PSEEs), and related software process technologies: a grid to evaluate and compare systems that sought to explicitly describe a software development process for a machine to carry out. As an initial testbed, we applied the grid to three European environments we were working on: OIKOS, EPOS, and SPADE; the last of these was developed at Politecnico di Milano.

The idea behind the software process research area (PMLs and PSEEs) was simple to state but brutally hard to implement. You wrote the process in a formal language, a Process Modeling Language. The model said who does what, in what order, with which tools, under which conditions. Then an engine (PSEE) executed the model, in what we called enactment, and offered a set of services: assistance to the people working, automation of routine tasks, invocation and control of the tools, and even, to quote the text from back then, “enforcement of mandatory rules and practices”. SPADE, our environment at Politecnico, evolved in that direction: it grew into OPSS, which ran on an event-based infrastructure called JEDI (Java Event-based Distributed Infrastructure) and coordinated human agents and external tools within a single, described, and governed process. In parallel, the same scheme was applied to business processes, and there it was called a Workflow Management System.

Why It Didn’t Succeed

Thirty years ago, in practice, it didn’t work, at least not where it mattered most, in the attempt to govern human, intellectual work. The reason matters because that’s where you see what has changed.

The problem wasn’t computing power or the quality of the tools. It was that real work doesn’t follow a prescriptive model. A process described in a PML is rigid by construction: it anticipates the cases you imagined when you wrote it. But people deviate constantly: they skip a step because, in this specific case, it isn’t needed; they swap two of them; they handle an exception the model never contemplated; they reinterpret a rule in light of a new context. This is competence, not indiscipline, and the way skilled work functions. And a system that imposes “mandatory rules” on the people doing that work becomes a straitjacket, not a help. Robert Balzer had said it in 1991, in “Tolerating Inconsistency”: a system should tolerate inconsistency rather than enforce it away, a heresy then, and the seed of much of what I would work on next.

I spent years on this problem. At that time, again in ACM TOSEM, together with Gianpaolo Cugola, Elisabetta Di Nitto, and Carlo Ghezzi, I co-authored an article whose title says it all: “A framework for formalizing inconsistencies and deviations in human-centered systems”. The thesis was that a process support system should tolerate deviations, not fight them: accept that real behavior and the model diverge, and manage that divergence rather than demand strict compliance. It was the hardest point of all, and the one where the technology of the time broke down. A formal language that tolerates ambiguity is almost a contradiction in terms. The more flexible you made the model, the more complicated it became to write and maintain, up to the point where describing it cost more than doing the work by hand.

What a Claude Workflow Is

For a moment, looking at Claude’s new feature, I thought the missing piece had finally arrived: that it was enough to describe the process in words and let the model fill the gaps. Then I went to look at how these workflows work. And I found something quite interesting.

A Claude workflow is not a natural-language description. It’s a script (JavaScript code) that orchestrates the execution: it defines the steps, sequences them or runs them in parallel, decides the branches, and coordinates dozens or hundreds of subagents. The structure that governs the process is, once again, deterministic code. It is, in effect, a Process Modeling Language reincarnated in a different syntax.

The trigger is expressed in natural language (you include the word “workflow” in a prompt), but what Claude returns is code: a JavaScript script that defines the orchestration logic (which subagents to start, whether to run them sequentially or in parallel, how to pass data between them, how to aggregate results), and a separate runtime executes that script in the background. Each subagent is an independent Claude instance with its own context, receives a specific task, and returns its result to the orchestrator. So the orchestration logic lives in deterministic, inspectable JavaScript, while the individual subagents handle the parts that require linguistic intelligence and judgment. This separation between deterministic orchestration and probabilistic execution is the core idea of the feature. The official documentation states it plainly: “A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive.” And it spells out the shift: “A workflow moves the plan into code. With subagents and skills, Claude is the orchestrator: it decides turn by turn what to spawn next, and every result lands in Claude’s context. A workflow script holds the loop, the branching, and the intermediate results itself.” (See Orchestrate subagents at scale with dynamic workflows, Claude Code documentation.)

Two Natures in One File

The natural language is the request, not the program. The program is JavaScript code. The primitives below — phase, parallel, agent — are the real ones, and the shape is the fan-out-reduce-synthesize skeleton that Claude Code’s own /deep-research is built on. I’ve left out the boilerplate a runnable script carries — the metaheader, the per-agent options, the schema that would back a field like confidence — to keep the two natures readable; the feature is in research preview, so the exact structure will still move. The sketch researches several questions in parallel, discards the weak findings, and then synthesizes the rest:

phase('Research')

// DETERMINISTIC: the script launches one agent per question, in parallel.
const findings = await parallel(
  // PROBABILISTIC: each agent() call is an LLM.
  questions.map(q => () => agent(`Research and report verified facts: ${q}`))
)

// DETERMINISTIC: ordinary code filtering the agents' results. No model here.
const solid = findings.filter(f => f && f.confidence > 0.7)

// DETERMINISTIC: a plain branch.
if (solid.length === 0) {
  return { report: 'No reliable findings.' }
}

phase('Synthesize')

// PROBABILISTIC: one last agent writes the briefing from what the script collected.
const report = await agent('Combine these findings into one briefing: ' + JSON.stringify(solid))

// DETERMINISTIC: the script returns the result.
return { questionCount: solid.length, report }

Read it top to bottom, and you see exactly who calls whom. The script is the orchestrator, and it is deterministic: parallel, .map, .filter, the if, the JSON.stringify are ordinary JavaScript. The machine runs them locally, as pure logic, and they return the same result every time you give them the same input. The script calls the agents, never the other way around.

The crucial distinction lies in what agent(...) actually does, because the appearance here may mislead you. It is written as a normal JavaScript function call, but it does not execute logic the way the surrounding lines do. It takes the string you pass it, sends it to a language model (a fresh instance of Claude), waits, and returns whatever the model produces. The JavaScript is only the plumbing: it carries the prompt out and the answer back. The real work, reading the question, searching, reasoning, writing the prose, happens inside the model, outside the JavaScript. The closest analogy for a programmer is a network call to an external service, a fetch() to some API: the line is JavaScript, but what happens on the other end of the wire is not. The service on the other end is not a database returning a fixed record; it is a model that reasons and composes something new on each request.

This is why that one line is probabilistic, and the others are not. JSON.stringify(solid) returns the exact same string every time. agent("write a briefing") does not: send the identical prompt twice, and you can get two different answers, because the model does not compute a unique result; it generates one token by token from a probability distribution. So the file is entirely JavaScript, yet two natures live inside it. The logic lines execute, and that is all (deterministic). The agent(...) lines are doors that open onto a probabilistic model, and what comes back through those doors is never guaranteed to be identical. The agents do not decide what runs next or talk to each other; they receive a task and return an answer. Control lives in the code; intelligence lives in the leaves.

The runtime is built around that separation. The documentation notes that a workflow run is resumable: if it stops partway, the agents that already finished return their saved results, and only the remaining ones run again. For this to hold, the orchestration code must replay identically each time, which is exactly what determinism guarantees. The skeleton must stay rigid, by design. Flexibility is allowed only where it belongs: inside the agents.

Where the Rigid Model Went

What has changed is the rigid model’s location, not its disappearance. Deviation, ambiguity, and contextual judgment haven’t been eliminated: they’ve been pushed down, into the leaves. Every single step of the script invokes a subagent (an LLM), and there, and only there, lives the flexibility we tried thirty years ago to encode into the PMLs. The skeleton is deterministic by necessity; the fuzzy part is confined to the terminal nodes.

Fuggetta Why Software Engineering Is Indispensable (submitted Text)

66.6KB ∙ PDF file

Download

Download

What makes an agent reliable is what surrounds the model: how you decompose the task, how you orchestrate the steps, how you handle errors, and how you verify results. It’s the orchestration layer that determines the system’s reliability. And the design principle is the one I’ve been repeating for months: keep deterministic what can be deterministic, and reserve the model for what requires interpretation and judgment under ambiguity.

The problem of thirty years ago and the problem of today are the same problem: where to put the boundary between the rigid rule and flexibility, between what must be enforced and what must be left to judgment. The difference is that back then, we managed that boundary in a single layer, the PML, asking it to be at once rigid (to control) and flexible (so as not to suffocate real work), and that contradiction made those approaches collapse. It’s the point I described this way in my latest article:

The vision was intellectually compelling. The execution was too rigid. […] A deterministic process engine either blocks or forces premature resolution that erases information the system cannot handle.

Today, the two requirements are separated into two layers: the orchestration code provides control, and the subagent provides flexibility. The deviation that once was a system error becomes a signal for human judgment, what in the article I call the shift from a deterministic model to a navigational one: no longer Process Model → Process Engine → enforces → Software Process, where deviation is an error, but Intent + Method + Structure → AI Agent → navigates → Software Process, where deviation is a signal. The problem hasn’t been solved; it has been decomposed. And decomposing it is, in a precise sense, an act of software engineering.

As I put it:

AI resolves the problem at a deeper level. A probabilistic engine does not rely on formal constraint satisfaction to operate: it navigates incomplete specs, ambiguous requirements, and partially inconsistent context without blocking. Inconsistencies surface naturally as outputs — signals for human judgment — rather than as system failures.

The Same Tension, Relocated

This also explains why the old tension hasn’t disappeared; it has only repositioned itself. If the orchestration is code, it’s verifiable and reproducible, the way a good SPADE model was. But the leaves aren’t: a subagent can do the right thing for reasons you don’t control, and the wrong thing the same way. The questions from back then — control, verifiability, reproducibility, trust — all remain, shifted from the global model to the individual probabilistic nodes.

And nothing in the underlying idea determines which regime sits on top. In a Claude workflow, the deterministic layer always sits above and the probabilistic one below; that ordering is built into the feature, not into the idea of composing the two. The two regimes compose, and they can nest the other way round.

Picture an open, ill-defined task whose overall shape has to be worked out by judgment and then resolves into a sequence of build steps that must run exactly; there, the framing is probabilistic and the execution deterministic. The model sets the course at the top, and the rigid code carries it out at the bottom. It is, in fact, what you get with plain subagents, where Claude decides turn by turn what to do next, and any single step may be a deterministic command. Determinism and probability are not “the skeleton” and “the leaves”. They are two approaches, and the design act is to decide, at every level, which one governs and which one executes, in whichever order the work demands.

There is an objection worth meeting head-on, because the analogy invites it: that I am dressing up a success as a resurrection, and that the deterministic skeleton never died at all. The branch of this research that tried to govern human work — the PSEEs, with their “mandatory rules” imposed on the people doing the job — is the branch that failed. But the branch that coordinated computational steps, the workflow and orchestration engines, is the one that succeeded; those engines are everywhere today, and the event-based coordination JEDI belonged to is on that side. Read this way, a Claude workflow is not the return of a failed idea but the extension of a working one, with a new kind of leaf attached. I think both readings are true and not in conflict. What collapsed thirty years ago was the attempt to make a single deterministic layer govern ambiguous, deviation-prone human work. What is new is not the orchestration skeleton (that always worked where the steps were computational) but that the leaves can now be probabilistic, and that is what lets the skeleton reach into the ambiguous work it could never govern before.

But the distinction that matters most in practice is a different one. The orchestration layer, written in JavaScript, is as rigid as a PML was: it anticipates only the cases its author imagined. For some processes, that is what you want. A test suite, a deployment, a large mechanical migration: structured activities where deviation is an error, and where pinning the steps down in code is a feature. For others, the open, exploratory, knowledge-dependent ones, where the path is discovered as you walk it, that same rigidity reintroduces the problem we crashed into thirty years ago. The script that orchestrates is excellent at coordinating the foreseeable, and useless, or worse, harmful, when the work is not. Knowing which of the two you are in is the whole game, and it is a judgment, not a setting. The encouraging novelty is that the foreseeable part can now be deterministic code, and the unforeseeable part can be delegated to a probabilistic agent. But deciding where the line falls is no easier than it ever was.

Anthropic's own examples show where that line really falls. Most of what they run as workflows — codebase audits, security sweeps, migrations, a language port across thousands of files — is foreseeable work, where a rigid script is a virtue. But one of their flagship workflows, deep research, is open, exploratory work, the kind I just called hostile to rigid orchestration, and it works as a workflow anyway. The reason is the whole point: a workflow fixes the how, not the what. Deep research always follows the same recipe — fan out across sources, cross-check them, discard what doesn't hold, synthesize the rest — while the answer comes out different every time. The recipe is rigid, so it lives in the script; the answer is open, so it stays in the probabilistic leaves. That is the real test, sharper than "structured versus open work": not whether the work is predictable, but whether its method is. Some open problems have a fixed method, and those are exactly the ones a workflow can hold.

A Warning I’ve Already Raised

And here I have to add a warning, because I have already written it once. In 2000, in “Software Process: A Roadmap”, I took a critical look at that whole research season. The diagnosis was blunt: we had produced interesting results, but lacked focus and tended to build whatever the technology of the day made possible. Researchers proposed “yet another PML or yet another PSEE,” each more expressive than the last. The real failure, though, was subtler than that appetite for technology: we underestimated the one problem that mattered and was hard. Not how to describe a process, which we kept doing with growing sophistication, but how to govern what no description can hold: flexibility, deviation, the unexpected, the inconsistency that real work produces. Every system broke on that same rock, and we kept mistaking a more expressive notation for progress.

I reread that lesson today and find it applicable to agent orchestration, word for word. The risk is identical, and it hides in plain sight. The field is impressive at what it can already do, and it measures itself on benchmarks that reward exactly that. But a benchmark says nothing about the hard part. It does not test what happens when the task is ambiguous, when an agent deviates, when two runs disagree, or when the answer is fluent and wrong. That is where the old engines died, and it is where the new frameworks will be judged once the demos are over. Thirty years ago, it left us with elegant systems that almost no one used; today, with the stakes and the investments incomparably larger, the same mistake costs far more. The question to start from is not “what can I get these agents to do,” but “how does it behave when the work stops being foreseeable, and where does the inconsistency go?” Everything else, however brilliant, is the same mistake in new clothes.

And there is a corollary that follows directly: we already know a great deal about this. Three decades of software process research mapped, often the hard way, exactly where the boundary between rigid and flexible lies and how a deterministic model behaves when it meets real work. That experience is not a museum piece. It is the knowledge needed to decide where a workflow belongs and where it does not. The worst move now would be to throw it away and start over. Let’s not reinvent the wheel or make the same mistake twice.

The research is already converging on this, which is the surest sign the problem is real and not a private déjà vu. Through 2025, a line of work has been instantiating the classical process models, Waterfall, TDD, Scrum, and the V-Model, as explicit coordination scaffolds for teams of LLM agents. SOEN-101 (ICSE 2025) hands the agents the old roles: requirements engineer, architect, developer, tester, and scrum master, and reports that a Scrum-shaped process increases the correctness of the generated code by about 15% over an unstructured baseline. A companion study runs the same comparison across Waterfall, V-Model, and Agile, and lands where we landed thirty years ago: the processes do work as coordination, but each carries a trade-off; the rigid one is the most efficient, the agile one buys quality at a higher cost. It is not a vindication of the old enactment engines; rather, the same problem resurfaces with the same tensions, which is the point.

What Doesn’t Change

There’s something I learned back then that still holds. The value lies less in the engine that executes than in the ability to think the process through well: to understand what must be made explicit and what must be left to judgment, where rigor is needed and where flexibility is needed, which steps matter and which are noise. Thirty years ago, that ability served to write a good model in a PML. Today, that same ability serves to write a good workflow and decide which steps to entrust to a subagent. The tool is incomparably more powerful. The thinking it requires is exactly the same, and it is, once again, software engineering.

And none of this cancels the human being. If anything, it finally puts the person in the right place. For thirty years, the human was the only thing holding a broken frame together: the component that, by hand, absorbed every gap between the model and reality, and paid for it when the model turned into a straitjacket. What changes now is not that the human is removed, but that the ambiguity which once fell entirely on the person is shared — the probabilistic leaves take on the interpretation, the deterministic skeleton takes on the coordination — and the human is left with what only the human can do: deciding what the process is for, where the boundary falls, what counts as a good result. The role is not erased but harmonized, at last, inside a frame that might work.

P.S.: Feel free to correct me or add to what I’ve written. Happy to learn more.

This post was written with the assistance of Claude. The ideas, the positions, and the reasoning are mine.

Referenced papers

• V. Ambriola, R. Conradi, A. Fuggetta, “Assessing Process-Centered Software Engineering Environments”, ACM Transactions on Software Engineering and Methodology, vol. 6, no. 3, July 1997, pp. 283–328.

• R. Balzer, “Tolerating Inconsistency”, Proceedings of the 13th International Conference on Software Engineering (ICSE), 1991, pp. 158–165.

• G. Cugola, E. Di Nitto, A. Fuggetta, C. Ghezzi, “A Framework for Formalizing Inconsistencies and Deviations in Human-Centered Systems”, ACM Transactions on Software Engineering and Methodology, vol. 5, no. 3, 1996.

• G. Cugola, E. Di Nitto, A. Fuggetta, “The JEDI Event-Based Infrastructure and Its Application to the Development of the OPSS WFMS”, IEEE Transactions on Software Engineering, 2001.

• A. Fuggetta, “Software Process: A Roadmap”, Future of Software Engineering, ICSE 2000, pp. 25–34.

• Anthropic, “Introducing dynamic workflows in Claude Code”, May 28, 2026 — the launch post, with the use cases referenced here (codebase audits, large migrations, deep research, and the Bun Zig→Rust port).

• F. Lin, D. J. Kim, T.-H. Chen, “SOEN-101: Code Generation by Emulating Software Process Models Using Large Language Model Agents”, ICSE 2025.

• A. Nguyen Duc et al., “Evaluating Classical Software Process Models as Coordination Mechanisms for LLM-Based Software Generation”, arXiv:2509.13942, 2025.

• Also referenced is my article “Why Software Engineering Is Indispensable in the Age of Coding Agents”, which I have just written and submitted for publication.*

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

Ma quando poi si chiede concretamente cosa dovremmo fare, le risposte si muovono tra il banale e il tristemente noto:

• “Politiche industriali per l’AI”, che di solito si traducono in spesa pubblica a pioggia per le imprese e le università.

• “Un piano strategico”, cioè l’ennesima commissione, quasi sempre costituita in base alle vicinanze politiche del ministro di turno, che produrrà il solito insieme di chiacchiere e di frasi di circostanza.

• “Un CERN per l’AI”, cioè l’ennesima scatola che alla fine produrrà poco o niente se non cariche di presidente o di consigliere di amministrazione. Ovviamente, una volta costituito, avrà continuamente bisogno di risorse pubbliche per stare in piedi (PNRR docet) secondo uno dei massimi principi nazionali: tutto si crea e nulla si distrugge (nemmeno quando si distrugge da solo per incapacità e insipienza).

• “Bonus per l’acquisto di servizi”, AI come i tablet e tante altre spese del passato. Sappiamo bene a cosa sono serviti: zero o quasi.

• Aggiungete voi…

In questo articolo non discuto di iniziative a livello europeo e di ricerca, due questioni intrecciate che meritano un discorso a parte. Resto sul piano operativo italiano, su alcune misure su cui agire subito.

1. Basta commissioni, basta vetrine

Davanti a una sfida, l’Italia ha un riflesso quasi automatico: istituire una commissione. Un comitato di esperti, un tavolo di lavoro, una strategia nazionale. L’AI non fa eccezione: negli ultimi due anni abbiamo prodotto piani, linee guida, documenti di indirizzo. Quasi tutti finiscono nello stesso posto: un file ben impaginato che nessuno trasforma in azione. Convocare un tavolo dà l’impressione di aver affrontato il problema, senza pagare il costo politico di dover scegliere e allocare risorse reali.

Alla sindrome della commissione si accompagna una dinamica speculare: l’evento. Il convegno, il keynote, il premio, il post che annuncia o evoca l’ennesima iniziativa. L’AI è diventata l’occasione perfetta per avere visibilità: per un’azienda che vuole apparire innovativa, per un’istituzione che vuole mostrarsi sul pezzo, per una persona che si costruisce una reputazione da esperto. Raccontare di fare qualcosa ha preso il posto di farla e costa molto meno.

2. La scuola: dentro i programmi, non di fianco

La scuola è il primo luogo in cui l’Italia dovrebbe agire, ed è quello in cui agisce da sempre peggio. Da vent’anni introduciamo il digitale a scuola nel modo sbagliato: come qualcosa che si aggiunge a ciò che già si fa. La lavagna interattiva in fondo all’aula, l’ora di coding, il laboratorio di informatica, il progetto PNRR sulle competenze digitali. Tutte iniziative che stanno di fianco alla didattica, mai dentro.

L’AI rende questo errore ancora più costoso. Uno studente che esce oggi dalla scuola incontrerà strumenti che scrivono, calcolano, traducono, programmano. Sapere quando fidarsi e quando no, come verificare un risultato, capire dove la macchina sbaglia, è un modo di pensare che attraversa l’italiano, la matematica, la storia, le materie tecniche e, come tale, va insegnato e vissuto all’interno delle singole discipline, non in un’ora separata che il resto dell’orario ignora.

Nessuna riforma dei programmi regge, però, se prima non si mettono i docenti nelle condizioni di operare. È il punto che si salta sempre, perché è il più scomodo e il più lento. Non basta un corso di aggiornamento una tantum, di quelli che si esauriscono in un pomeriggio e in un attestato. Serve formazione continua, seria, con tempo dedicato e riconosciuto nell’orario di lavoro, non scaricata sulla buona volontà del singolo insegnante. Servono metodi di insegnamento organici che integrino l'AI e il digitale in tutti i percorsi didattici. Servono poi le infrastrutture e i servizi, connettività che funziona, strumenti adeguati, assistenza tecnica vera. Sono la condizione abilitante: senza di essa, i due punti precedenti restano slogan. Una scuola in cui la rete cade a metà mattina o in cui l’unico tecnico arriva una volta al mese non può integrare l’AI nella didattica, per quanto bravi siano i suoi insegnanti.

C’è, infine, la condizione che tiene insieme tutte le altre: valutare, mettere in concorrenza, responsabilizzare. Una scuola che non viene mai valutata sul serio non ha motivo di migliorare. Senza formazione dei docenti, infrastrutture e valutazione, si distribuiscono risorse a pioggia e si creano eccellenze isolate accanto a sacche di immobilismo, perché manca il meccanismo che premia chi fa bene e chiede conto a chi resta indietro.

3. Le imprese: programmi che producono risultati

Anche per le imprese gli strumenti non mancano. Quello che manca è la capacità di usarli per cambiare davvero il modo di lavorare, e qui l’ostacolo italiano è vecchio e documentato.

Pellegrino e Zingales, in un lavoro che continuo a citare perché resta poco ascoltato, hanno mostrato che la produttività italiana si è fermata a metà degli anni Novanta, proprio quando le imprese non sono riuscite a integrare la rivoluzione informatica. La causa, scrivono, non è tecnologica ma manageriale: troppe imprese scelgono i dirigenti per fedeltà e per relazioni familiari, non per competenza. Un’azienda guidata così non sa cosa farsene dell’AI. A sua volta, l’immobilismo manageriale spesso è dovuto alla mancanza di concorrenza, che porta molti imprenditori a non avere alcuno stimolo a cambiare.

A questo si aggiunge il nanismo. Gran parte delle imprese italiane è troppo piccola per investire in competenze, attrarre persone capaci, affrontare un cambiamento organizzativo serio. Non è un difetto di cultura imprenditoriale, ma il risultato di incentivi e scelte legislative che, con l’illusione di “aiutare le PMI”, da decenni premiano chi resta piccolo. Finché conviene non crescere, quali incentivi ha un’impresa a investire in innovazione e competenze?

Gli strumenti pubblici di sostegno contano, a patto che siano fatti bene. Servono strumenti agili, che eroghino risorse sostanziali e non simboliche in tempi rapidi e con regole chiare, al posto dei bandi farraginosi che scoraggiano proprio le piccole imprese che avrebbero più bisogno di aiuto. Uno strumento di sostegno che arriva tardi e richiede più tempo del dovuto è un altro modo di non scegliere. Il credito d’imposta è il più efficace, perché incide direttamente sul conto economico dell’impresa. Ma funziona solo se è strutturale e stabile, se non cambia forma e non appare e scompare a ogni legge di bilancio; se si applica a una base ampia di progetti, non a perimetri ristretti e parcellizzati; se premia le imprese che si aprono a competenze esterne, università e startup, invece di chiudersi a giustificare "spese interne" non meglio specificate. Ed è inutile dire “ci sono le truffe”: strumenti come la fatturazione elettronica e la verifica digitale dei pagamenti consentono di controllare in modo pressoché automatico come sono stati spesi i soldi.

4. Le regole: spingere il futuro, non difendere il passato

C’è un altro terreno, meno appariscente degli altri, ma che li attraversa tutti: le regole. In Italia la norma nasce troppo spesso con una funzione conservativa. Protegge una categoria, mette al riparo una posizione acquisita, alza una barriera per chi vorrebbe entrare in un mercato. Anche quando non lo dichiara, lavora per difendere chi c’è già contro chi vorrebbe arrivare.

Per l’innovazione è il freno più potente di tutti. Un’impresa innova quando ha di fronte un concorrente che la incalza e un mercato da conquistare. Se le regole proteggono le rendite e rendono conveniente restare fermi, l’innovazione non ha ragione di accadere, qualunque incentivo si metta sul piatto. È il punto che ho richiamato a proposito delle imprese: senza concorrenza manca lo stimolo a cambiare. E le regole sono uno dei principali strumenti con cui la concorrenza si crea o si soffoca.

Che funzioni non è una teoria. I pagamenti digitali lo mostrano. Per anni l'Italia è stata un Paese del contante, con tutto ciò che il contante comporta in termini di opacità ed evasione fiscale. Nel 2024, per la prima volta, i pagamenti digitali hanno superato il contante per valore: 481 miliardi di euro, pari al 43% dei consumi, contro il 41% del contante (Osservatorio Innovative Payments del Politecnico di Milano). Il sorpasso segue un trend europeo, ma in Italia è stato accompagnato da una sequenza di regole che ha spinto nella stessa direzione: obbligo di accettare i pagamenti elettronici, fatturazione elettronica, tracciabilità delle transazioni. E dove l'effetto delle norme è isolabile, è netto: la sola fatturazione elettronica, insieme allo split payment, ha contribuito a dimezzare in pochi anni il divario IVA.

Per l’AI vale la stessa logica. Non servono regole che cristallizzino gli assetti di oggi o che costruiscano nuove rendite attorno a chi è già dentro. Servono regole che abbassino le barriere per chi vuole usare queste tecnologie, premino chi le adotta sul serio, impongano trasparenza, aprano dati e mercati alla concorrenza.

Le scelte si fanno o non si fanno

Nessuna di queste cose richiede una tecnologia che non abbiamo o risorse straordinarie da reperire chissà dove. La formazione dei docenti, l’AI nei programmi, le infrastrutture per la scuola, un credito d’imposta stabile e strumenti di sostegno agili per le imprese, regole che aprono il mercato alla concorrenza invece di proteggere le rendite: sono scelte di priorità e di esecuzione. Costano meno di un anno di Superbonus e valgono incomparabilmente di più.

Questo post è stato scritto con l’assistenza di Claude. Riprende e sviluppa riflessioni già pubblicate su questo Substack e su Medium e l’analisi di un articolo per Harvard Business Review Italia, “Un modello a rete per la ricerca e l’innovazione in Italia”. Il riferimento a Pellegrino e Zingales è a “Diagnosing the Italian Disease”, NBER Working Paper n. 23964.

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 fatto che più mi sorprende è che troppi che si dicono “tecnici” o “studiosi” in realtà adottino posizioni fideistiche: “L’AI ha un impatto sul lavoro perché è così, non può essere altrimenti. I numeri sono vecchi e quindi non catturano i fenomeni.” E così via. È una corsa per convincersi e convincere che la visione di un’AI dall’impatto travolgente sia vera anche in assenza di evidenze solide.

Una volta dissi che troppe persone divinizzano l’AI e si riducono ad atteggiamenti fideistici (o interessati). Ovviamente, ricevetti risposte offese e piccate.

Riporto qui le conclusioni dell’articolo che citavo, scritto da colleghi provenienti da università e centri di ricerca prestigiosi: University of Pittsburgh, Stanford University, AI Economy Institute – Microsoft, Revelio Labs, Chapman University, Columbia University. Le sottolineature in grassetto sono mie.

Taken together, our results indicate that worsening labor-market outcomes in 2022–2024 for LLM-exposed workers and graduates were already underway prior to the mass-market emergence of LLM applications. Unemployment risk in highly exposed occupations rose beginning in early 2022—well before ChatGPT—and in most occupations and states we observe no discrete break coincident with its introduction. Early-career workers were affected disproportionately: graduates from the 2021–2023 cohorts entered highly exposed jobs at lower rates and experienced longer observed delays to their first job than earlier cohorts, with gaps opening, again, before late 2022. At the same time, LLM-relevant education remained valuable within this environment. Graduates whose programs exhibited greater pre-2020 curricular emphasis on LLM-exposed tasks earned higher first-job pay and reached their first jobs more quickly in the post-ChatGPT period, particularly when entering highly exposed occupations. Together, these patterns suggest that LLM diffusion occurred in a labor market already shaped by macroeconomic and sectoral forces, while LLM-complementary skills retained—and possibly increased—their labor-market value.

These findings have implications for research and policy. First, they caution against treating ChatGPT’s launch as a clean natural experiment for AI’s labor-market impact: designs that attribute post-2022 labor-market weakness primarily to LLMs risk confounding AI diffusion with concurrent macroeconomic shifts (possible examples include monetary policy, sectoral demand, and/or post-pandemic adjustment). Second, they suggest that higher education and workforce programs should not abandon skills often labeled “AI-exposed,” such as writing, coding, and information synthesis. Instead, curricula that teach these skills in LLM-complementary ways (e.g., by emphasizing verification, evaluation, and effective human–LLM collaboration) may improve graduates’ resilience in an uncertain labor market.

Our analyses rely on administrative unemployment insurance records, online career histories, task-based exposure measures, and syllabus-derived proxies for curricular content. Each source involves measurement error and selection. In particular, our educational exposure measure is derived from syllabi that predate 2020 and therefore captures baseline differences across programs rather than curricular responses to ChatGPT. Our time-to-first-job analyses exclude individuals whose first observed job begins more than three years after degree completion, which may understate delays among graduates facing the greatest barriers to entry. We do not identify the causal effect of LLMs on labor-market outcomes. Nonetheless, by triangulating across independent data sources, we document timing patterns that are difficult to reconcile with a sudden post-ChatGPT collapse in exposed occupations, shifting attention toward broader labor-market dynamics and toward expanding access to AI-complementary education. Future work combining direct measures of LLM adoption with linked worker–firm data will be critical for distinguishing displacement from productivity gains and for identifying which workers, regions, and institutions benefit—or fall behind—in the next phase of diffusion.

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

Sono usciti su lavoce.info due miei articoli in parallelo.

La difficile scommessa di Anthropic — Anthropic ha raggiunto 30 miliardi di dollari di fatturato annualizzato puntando tutto sul mercato enterprise. È la scommessa più razionale del mercato dei foundation model e, proprio per questo, la più fragile.

Open Source AI, sovranità e la scelta europea — Il mercato dei foundation model si è strutturato in una geometria a tre vertici: USA closed, Cina open e statalizzata, Europa di nicchia. L’Europa ha una finestra di tre-cinque anni per decidere se la dipendenza tecnologica dai modelli americani sia un fatto da gestire o un problema da affrontare.

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

Questa omologazione del giudizio dovrebbe metterci in allarme. Quando una sola causa basta a spiegare tutto, è molto probabile che non stia spiegando bene nulla e sia o l’alibi di turno o l’espediente retorico del momento. Diventa una scorciatoia narrativa: invece di indagare che cosa è cambiato in un fenomeno specifico, si ricorre a una formula pronta, da far valere in qualsiasi contesto. È comoda, comunica bene e offre un paravento credibile per evitare di condurre un’analisi approfondita.

Vediamo un caso concreto in cui l’attribuzione automatica all’AI ha dominato il dibattito pubblico per oltre un anno. Uno studio appena uscito suggerisce un quadro diverso o, quantomeno, invita ad attendere prima di dare giudizi definitivi.

Il caso dei giovani che non vengono assunti

Da circa un anno, qualunque articolo si legga sull’occupazione giovanile parte dalla stessa premessa: l’AI sta tagliando le posizioni entry-level. Il riferimento empirico più citato è uno studio dello Stanford Digital Economy Lab, pubblicato a fine 2025 e firmato da Erik Brynjolfsson, Bharat Chandar e Ruyu Chen. Usando i dati di una grande società di payroll americana, i tre stimano che dal 2022 l’occupazione dei lavoratori tra i 22 e i 25 anni nelle occupazioni più esposte alla GenAI è scesa del 16% rispetto a quella dei loro coetanei in occupazioni meno esposte. Altri studi (Hosseini Maasoum e Lichtinger, Teeselink, Azar e colleghi) giungono a conclusioni simili.

I numeri sono reali. La connessione causale ha l’aria di un fatto accertato. Le pagine economiche e gli analisti si sono allineati in fretta: c’è una macchina che fa quello che facevano i junior, e i junior smettono di essere assunti. La storia è pulita e si racconta bene.

Un recente studio di Peter John Lambert (University of Warwick e London School of Economics) e Yannick Schindler (Ellison Institute of Technology, Oxford), reso pubblico a maggio 2026, ha fatto questa fatica. La domanda di partenza è quasi banale: cos’altro è cambiato, nelle stesse occupazioni colpite dall’AI, a partire dal 2022? La risposta è il working from home (WFH). Le occupazioni più esposte all’AI sono, a livello più granulare del classificatore O*NET-SOC americano, anche quelle più migrate verso il lavoro da remoto. Software developer, commercialisti, consulenti e technical writer sono in alto in entrambe le classifiche di esposizione; elettricisti, falegnami e addetti alle pulizie sono in basso in entrambe. La correlazione di rango è pari a 0,77: i due fenomeni colpiscono pressoché le stesse persone.

Da non esperto di statistica, l’ho capito così (gli esperti mi correggano se sbaglio).

Lambert e Schindler hanno raccolto 243 milioni di assunzioni e 407 milioni di annunci di lavoro pubblicati negli Stati Uniti, nel Regno Unito, in Canada e in Australia tra il 2017 e il 2025, e hanno stimato l'effetto di AI e WFH sulla quota di junior tra le nuove assunzioni. Quando testano una variabile alla volta, AI e WFH spiegano il calo in modo quasi identico: un aumento di due deviazioni standard dell'esposizione, in una direzione o nell'altra, predice un calo di 4–5 punti percentuali della quota di junior. Sono numeri solidi e coerenti con la letteratura precedente.

Il momento decisivo si verifica quando le due variabili sono incluse nello stesso modello e si stima il contributo di ciascuna al netto dell'altra. Il WFH continua a spiegare il calo come prima. L'AI, invece, perde quasi tutto il suo peso e, nella maggior parte delle stime, il suo effetto non si distingue più dal rumore di fondo. Il risultato non dipende da come si misura il WFH: anche riducendolo a un sì/no (l'occupazione è migrata al lavoro da remoto, o no), il WFH continua a sovrastare in modo determinante l'AI come spiegazione del calo.

When estimated separately, a two-standard-deviation increase in GenAI and WFH exposure each predicts, by 2025, a fall of around 5pp in the junior-share of new hires and around 3pp in the share of job ads requiring limited experience. Estimated jointly, the WFH effect remains, while the GenAI coefficient attenuates sharply and is often statistically indistinguishable from zero. Alternative exposure measures, residualization designs, flexible non-parametric co-treatment controls, and replacing exposure-measures with actual WFH adoption as the treatment all support our finding that WFH is a robust predictor of the decline in early-career hiring.

Lambert e Schindler hanno dedicato un quarto del paper a verificare che il risultato non sia un artefatto. Hanno provato misure alternative di esposizione, hanno tolto ogni paese a turno e ogni gruppo occupazionale a turno, hanno calcolato indicatori di sensibilità a variabili omesse e simulazioni Monte Carlo per l’errore di misurazione. Il risultato regge a ogni stress test. In 22 delle 24 combinazioni di misure alternative, il coefficiente WFH è maggiore di quello di AI.

Our findings point strongly towards WFH exposure as a better predictor of the decline in relative early-career hiring.

Cosa si vede dal tavolo di selezione

Chi lavora in un’organizzazione di una certa dimensione sperimenta, sul piano operativo, ciò che il paper misura su 243 milioni di assunzioni. Quando si valuta l’assunzione di una persona junior che pone come condizione il lavoro completamente da remoto, sorgono riserve operative, le stesse che Lambert e Schindler formalizzano nel paper e che chiunque abbia costruito un team conosce.

La supervisione di una persona inesperta richiede presenza. Un junior va accompagnato, e l’accompagnamento si fa stando vicini. Quello che si impara nei primi anni di un lavoro qualificato passa poco dai contenuti formali; passa dal contatto con colleghi più esperti, dalle conversazioni laterali in corridoio, dall’osservazione di come si gestiscono una telefonata difficile, una negoziazione tesa, un cliente arrabbiato. Sono tutte cose che non si trasferiscono né via Slack né in videoconferenza. Richiedono di essere nella stessa stanza, almeno per parte del tempo.

Davanti alla scelta, succede spesso che si preferisca qualcuno più senior, già formato, disposto a venire in ufficio una parte significativa del tempo. Costa di più, ma evita un costo organizzativo nascosto: tentare di formare un junior senza le condizioni (presenza, vicinanza, scambio quotidiano) che alla formazione danno sostanza. La trasformazione che l’articolo documenta sul piano sistemico (cioè che le aziende spostano le nuove assunzioni verso i profili più esperti) è una somma di decisioni come queste, prese ogni giorno ai tavoli di selezione. Si gioca lì, dentro le aziende, nelle scelte di chi assume.

Tutti i pezzi erano sul tavolo

Il riflesso ha fatto da scorciatoia. È meno faticoso scrivere un articolo che attribuisca il fenomeno alla causa più disponibile, che lavorare per due anni a un paper di sessanta pagine per dimostrare che la causa più disponibile coincide con un’altra che nessuno aveva considerato. E adottare un punto di vista accattivante e “di moda” è anche più gratificante: il lettore arriva alla fine dell’articolo con la sensazione di chiarezza, di una posizione assunta, di una tesi difesa. Il fatto che la tesi fosse sbagliata, o quanto meno non controllata e non unica, si scopre solo se qualcuno è disposto a farsi domande di secondo livello.

L’aspetto più preoccupante del riflesso non è tanto l’errore di attribuzione, quanto l’abitudine che si perde: chiedersi cos’altro è cambiato, dove guardare, quali variabili abbiamo lasciato fuori. È la stessa pigrizia cognitiva che, in altri ambiti, fa leggere ogni elezione come un referendum sul tema del momento, ogni crisi aziendale come effetto della congiuntura macroeconomica. Una formula che spiega tutto non spiega più niente: è il momento di diffidarne, non di affidarsi.

Il riflesso AI funziona come tutte le scorciatoie cognitive: dà la soddisfazione immediata di un’attribuzione causale e ci risparmia la fatica di cercare cause concorrenti, sospendere il giudizio e tollerare l’incertezza prima di concludere. È una rinuncia silenziosa che si paga in termini di qualità del pensiero. E si paga ovunque: nel mercato del lavoro, nelle conversazioni aziendali, nelle scelte di policy, nelle analisi quotidiane di un’organizzazione.

Le emozioni che suscita l’AI sono comprensibili, anche legittime. Ma non devono sostituire l’analisi. Quando lo diventano, abbiamo già perso prima ancora di cominciare a parlare.

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

Il paper di Lambert e Schindler è un working paper SSRN, ancora in fase di peer review. Gli stessi autori non escludono che l'AI eserciti un effetto sull'occupazione junior; sostengono che, sulla base dei dati attuali, il working from home spiega meglio il fenomeno.

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

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

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

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

L’apocalisse comoda

I numeri non vanno minimizzati. Negli Stati Uniti mancano circa 500.000 posti tech rispetto al trend pre-2022. San Francisco, capitale mondiale della Silicon Valley, ha perso il 3% della sua occupazione complessiva dall’inizio del 2023. I Magnificent Seven — le sette grandi aziende tech — hanno praticamente smesso di far crescere gli organici tra il 2022 e il 2025. Oracle taglia migliaia di posti. Block, la creatura di Jack Dorsey, ne elimina oltre 4.000, quasi metà del personale. Amazon e Meta annunciano riduzioni.

La spiegazione offerta dai CEO è sempre la stessa: l’intelligenza artificiale. L’AI è diventata così brava, dicono, che molti ruoli non sono più necessari. È una narrazione potente, che piace a Wall Street — perché un’azienda che licenzia “grazie all’AI” sembra innovativa, non in difficoltà.

Ma è anche una narrazione in larga parte falsa.

Secondo i dati di Challenger, Gray & Christmas, nel 2025 le aziende hanno dichiarato l'AI come causa in circa 55.000 dei 1,2 milioni di licenziamenti totali — e Forrester sostiene che molti di questi siano in realtà casi di AI-washing. Il resto aveva cause più prosaiche. Molly Kinder della Brookings Institution ha spiegato bene il meccanismo al New York Times: attribuire i tagli all’intelligenza artificiale è un messaggio “molto gradito agli investitori” — assai più di “il business non va bene”. Un analista di Deutsche Bank, commentando il caso Block, ha posto la domanda giusta: quanto di tutto questo è davvero AI, e quanto è la scusa per smaltire l’eccesso di assunzioni del periodo pandemico?2

Un paper del National Bureau of Economic Research, basato su 25.000 lavoratori e 7.000 aziende (dati danesi)3, ha dato la risposta più netta: finora l’impatto dell’AI sull’occupazione è stato sostanzialmente nullo.

Le cause banali

Se non è l’AI, allora cos’è? La risposta è meno spettacolare, ma più solida. Tre fattori, tutti ben documentati.

Il primo è il rientro dall’ubriacatura pandemica. Durante il Covid, la domanda di servizi digitali è esplosa e le aziende tech hanno assunto in modo compulsivo. Meta è passata da circa 45.000 dipendenti alla fine del 2020 a oltre 86.000 nel 2022: un raddoppio in due anni. Poi sono arrivati i tagli — non per l'AI, ma per il ritorno alla normalità.

Il secondo è la politica monetaria. Dal 2022 i tassi di interesse sono saliti rapidamente, frenando gli investimenti IT delle imprese. Meno investimenti in software e infrastruttura significano meno domanda per chi sviluppa quel software e gestisce quella infrastruttura.

Il terzo è l’outsourcing. Le importazioni statunitensi di servizi cloud e di storage sono più che raddoppiate tra il 2021 e il 2024. Perché pagare uno stipendio della Bay Area quando puoi ottenere lo stesso servizio da Bangalore a un quarto del costo?

Il precedente storico è quasi perfetto. Dopo lo scoppio della bolla dotcom nel 2000, la quota di occupati nel settore tech stagnò per anni negli USA, nel Regno Unito, in Australia e in Canada. Le cause erano identiche: fine di una bolla speculativa, rialzo dei tassi, outsourcing. Nessuna AI da incolpare.

La migrazione silenziosa

Ma c’è un fenomeno che la narrazione apocalittica oscura del tutto. Se si guarda non alle aziende tech ma alle persone con professioni tech, il quadro si rovescia. La quota di americani che svolgono lavori legati alla tecnologia è cresciuta dal 3,6% al 3,7% dal lancio di ChatGPT. Un paper della Federal Reserve (Crane e Soto) conferma che le aziende continuano ad ampliare i ranghi degli sviluppatori — solo più lentamente di prima.

E dove vanno questi lavoratori? Nei settori che fino a ieri non avevano programmatori o ne avevano pochi o nessuno. Il retail americano ha aumentato gli addetti software del 12% tra il 2022 e il 2025; il settore immobiliare del 75%; l’edilizia quasi del 100%. McKinsey documenta che la domanda di AI fluency — la capacità di usare e gestire gli strumenti AI — è cresciuta di sette volte in due anni.

Ecco perché l’immagine di Starbucks funziona. Il giovane programmatore non è disoccupato: lavora altrove, in settori che stanno finalmente internalizzando le competenze digitali che avrebbero dovuto sviluppare da tempo. La domanda di lavoro tech si ripartisce.

La porta che si chiude

Fin qui, le buone notizie. Ma c’è un segnale che merita attenzione, anche se va letto con cautela.

Due studi della Federal Reserve di Dallas, pubblicati a gennaio e a febbraio 2026, mostrano che l'occupazione dei giovani tra i 22 e i 25 anni nelle professioni più esposte all'AI è calata del 13% rispetto al 2022. Non perché vengano licenziati, ma perché non vengono assunti: il tasso di ingresso nel mercato del lavoro per questi profili è in calo. I salari, intanto, crescono — soprattutto per i lavoratori esperti. Nel settore dei computer systems design, la crescita salariale dal 2022 è stata del 16,7%, contro il 7,5% della media nazionale.

La chiave interpretativa della Dallas Fed è la distinzione tra il codified knowledge e il tacit knowledge. I neolaureati portano soprattutto conoscenza codificata — quella che si impara dai libri, quella che l’AI già sa replicare. I professionisti esperti portano con sé conoscenza tacita — il giudizio, l’intuizione, la capacità di leggere un contesto che nessun manuale descrive. L’AI complementa i secondi e rende meno necessari i primi.

È legittimo chiedersi se questo calo tra i giovani sia davvero dovuto all’AI. Il periodo 2022–2025 è dominato da fattori ciclici — tassi, post-pandemia, outsourcing — e il paper NBER che ho citato prima ripropone lo stesso schema, senza che l’adozione dell’AI sia il fattore trainante. Solo dal febbraio del 2025, con l’arrivo di strumenti come la prima versione di Claude Code di Anthropic, è diventato plausibile che un tool AI sostituisca un ingegnere software in alcuni compiti reali. Siamo in una finestra temporale troppo breve per avere certezze causali.

Ma il rischio strutturale è chiaro anche senza certezza causale: se le aziende smettono di assumere junior — per l’AI, per i costi, per qualsiasi ragione — tra cinque anni non avranno i quadri intermedi e i senior di cui hanno bisogno. La pipeline si spezza.

Ridisegnare, non tagliare

IBM ha annunciato di triplicare le assunzioni entry-level, inclusi gli sviluppatori software — esattamente quei ruoli che “l’AI dovrebbe rendere superflui”. Ma non assume gli stessi junior di prima. Ha ridisegnato i ruoli: meno coding routine, più interazione con i clienti, più intervento quando i chatbot falliscono. Come ha spiegato la responsabile HR Nickle LaMoreaux: “Le aziende che tra tre/cinque anni avranno più successo sono quelle che oggi puntano con più forza sulle assunzioni entry-level”4.

Non è solo IBM. Dropbox sta espandendo i programmi per neolaureati del 25%, puntando sulla “fluency” AI della Gen Z. Cognizant assume più neolaureati che mai. Il CEO Ravi Kumar S ha sintetizzato la logica: “L’AI è un amplificatore del potenziale umano. Non è una strategia di sostituzione.”

Mary Shaw, docente di computer science a Carnegie Mellon e una delle voci più autorevoli nella comunità dell’ingegneria del software, ha descritto bene questa trasformazione in un recente articolo su IEEE Software5: le responsabilità degli sviluppatori si stanno spostando dalla scrittura del codice alla sua progettazione, alla valutazione e alla supervisione. Non si tratta di sapere meno, ma di sapere cose diverse — e più difficili.

Chi oggi taglia i costi eliminando i junior sta cannibalizzando il proprio futuro.

Starbucks, e quarant’anni di storia

Torno al programmatore da Starbucks. L’immagine è efficace proprio perché capovolge la narrazione senza negarla: sì, qualcosa sta cambiando — ma non nella direzione che pensiamo.

C’è uno studio che mette in prospettiva storica questa transizione. Kerstin Hötte e colleghi hanno condotto una revisione sistematica della letteratura empirica su oltre trent'anni di cambiamento tecnologico (1988–2021) e sul suo impatto sull’occupazione, esaminando cinque categorie di tecnologia — ICT, robot, innovazione, produttività totale dei fattori, altre. La conclusione, robusta e trasversale: l’effetto di sostituzione del lavoro è stato sistematicamente più che compensato dai meccanismi di creazione e di ripristino della nuova occupazione. Le ansie sulla disoccupazione tecnologica di massa, scrivono gli autori, “mancano di una base empirica”6.

Lo conferma, con un metodo diverso, l'economista di Harvard David Deming. Insieme a Larry Summers, Deming ha costruito una misura della "occupational churn" — quanto cambiano le quote occupazionali nel tempo — calcolandola dal 1880 a oggi7. Il risultato storico è coerente con Hötte: la seconda decade del Duemila è stato il decennio più stabile nella storia del mercato del lavoro americano, a conferma che la tecnologia digitale non ha prodotto la disoccupazione di massa che molti temevano. Ma Deming aggiunge qualcosa che Hötte non cattura: aggiornando i dati al 2024, il mercato sta cambiando più velocemente di qualsiasi periodo dagli anni Settanta. Come ha detto in un podcast di Harvard Business School: "Se volessi raccontare una storia in cui questa volta è diverso, potresti trovare i primi segnali."

Entrambe le analisi documentano qualcosa di più scomodo: i lavoratori meno qualificati hanno sofferto in ogni transizione. La compensazione non è automatica, non è indolore e non è garantita. Funziona solo quando è accompagnata da strategie di formazione e riqualificazione che gli autori indicano come priorità imprescindibile.

La storia ci dice che la tecnologia crea più lavoro di quanto ne distrugga, ma anche che ciò accade solo se la transizione viene governata. Non si governa da sola. Non si governa con i comunicati stampa dei CEO che attribuiscono i licenziamenti all’AI per far salire il titolo in borsa. Si governa con la formazione — ripensata e ricomposta attorno a ciò che l'AI non sa fare: il giudizio, la relazione, la capacità di muoversi in contesti ambigui.

Il punto non riguarda solo i programmatori, né solo il settore tech. Ogni transizione tecnologica degli ultimi quarant’anni ha seguito lo stesso schema: il lavoro si trasforma, si sposta, si ricompone — ma chi resta indietro sono quelli che nessuno ha preparato al cambiamento. I blue-collar ieri, i lavoratori con competenze codificabili oggi. Lo schema è identico; cambia solo il bersaglio.

Governare questa transizione significa fare ciò che in passato non si è sempre fatto: investire nella formazione prima che la crisi arrivi, non dopo. Ridisegnare i ruoli — come fa IBM — anziché eliminarli. Ripensare cosa si insegna e come lo si insegna, a tutti i livelli, non solo nelle facoltà di informatica. E smettere di confondere la narrazione comoda — “l’AI ci sostituisce” — con l’analisi onesta di ciò che sta accadendo.

Il programmatore da Starbucks non è il segno di un’apocalisse. È il segno di un’economia che cambia pelle. Ma cambiare pelle senza strappi richiede che qualcuno si occupi della transizione, non solo della tecnologia.

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

Mio prompt per Perplexity Pro: Quali funzionalità sono offerte da Superpowers per Claude?

Superpowers è un framework open-source agentico con oltre 139.000 stelle su GitHub e incluso ufficialmente nel marketplace Anthropic dal 15 gennaio 2026. Nella sua versione attuale (5.0.7), supporta nativamente più piattaforme: Claude Code, Cursor, Gemini CLI, GitHub Copilot CLI, Codex e OpenCode. Il principio di base è che le skill si attivano automaticamente — non sono suggerimenti opzionali, ma flussi di lavoro obbligatori

Mio prompt: Come indico quel che deve fare l’app da creare?

Ci sono tre modi per indicare a Superpowers cosa deve fare la tua app, dal più semplice al più strutturato:

---

Modo 1: Descrizione libera nel brainstorm

Il metodo più naturale è lanciare il brainstorm con una frase descrittiva in linguaggio normale :

/superpowers:brainstorm Voglio creare una web app ispirata a Notion
con editor di testo ricco, tabelle interattive e Kanban drag-and-drop.
Deve essere responsive e supportare la persistenza dei dati.

Da lì, Superpowers fa da solo: pone domande una alla volta per raffinare i dettagli — stack tecnologico, autenticazione, database, deployment. Non devi anticipare tutto, basta l’idea di partenza .

---

Modo 2: Descrizione con vincoli già definiti

Se hai già delle preferenze tecniche, puoi includerle nel prompt iniziale per ridurre le domande :

/superpowers:brainstorm Voglio costruire un prototipo per <descrizione problema>.
Aiutami a chiarire i vincoli e i requisiti esatti.
Stack: Next.js + Supabase. Autenticazione con OAuth Google.

Superpowers userà il contesto già fornito e salterà le domande ovvie, concentrandosi sui punti ancora aperti .

---

Modo 3: Conversazione informale (senza slash command)

Non è nemmeno necessario ricordare i comandi esatti: puoi parlare normalmente :

Usa Superpowers per aiutarmi a fare brainstorming su questa funzione

Le skill si attivano anche conversazionalmente — non appena Claude capisce che stai descrivendo qualcosa da costruire, la skill di brainstorming parte automaticamente .

---

Cosa succede dopo

Una volta che approvi il design emerso dal dialogo, Superpowers passa automaticamente alla fase di pianificazione senza bisogno di altri input . Il piano generato è pensato per essere “chiaro abbastanza da poter essere seguito da un junior engineer senza contesto di progetto” — quindi più sei preciso nella fase di brainstorming, più il piano sarà accurato.

Mio prompt: Ma una frase come quelle che mi hai mostrato non è un requisito, sono goal generici.

Hai centrato un punto fondamentale. Il brainstorming è esattamente il meccanismo per trasformare un goal generico in una spec concreta — non ti viene chiesto di arrivare già con i requisiti scritti. Ecco come funziona nella pratica:

Il tuo compito: dare solo il “perché”

Tu dici a Superpowers cosa vuoi ottenere, non come farlo :

Voglio un'app per tracciare le spese del team

Questo è sufficiente per avviare il processo. Superpowers non si aspetta un documento di requisiti .

Il lavoro di Superpowers: estrarre la spec con domande

La skill di brainstorming usa domande socratiche per “tirare fuori” i requisiti dalla conversazione . Per esempio, dopo il tuo goal generico, Claude potrebbe chiedere:

• “Chi usa l’app — solo tu o tutto il team?”

• “Le spese devono essere approvate da qualcuno?”

• “Serve integrazione con strumenti come Notion o Slack?”

• “Vuoi categorie fisse o personalizzabili?”

Una domanda alla volta, non un interrogatorio lungo . Dopo ogni risposta, affina la comprensione e va più in profondità.

Il risultato: un design document vero

Solo dopo questo dialogo, Superpowers produce un documento strutturato con :

• requisiti funzionali precisi

• scelte architetturali motivate

• edge case considerati

• stack tecnologico definito

Lo mostra a sezioni per farti validare o correggere prima di procedere . Solo dopo la tua approvazione esplicita si passa alla pianificazione.

[…]

Il principio di fondo è che Claude "tease a spec out of the conversation" — la spec emerge dal dialogo, non deve esistere prima.

Mio prompt: Un'applicazione che non sia un esperimento scolastico ha requisiti che di solito richiedono almeno qualche centinaio di pagine di testo o spesso di requisiti strutturati tipo UML. Come può l'utente scrivere qualche frase e far sì che Claude esegua?

La tua osservazione è corretta e la risposta onesta è: Superpowers non è adatto per sviluppare software enterprise reale con requisiti complessi. È un tool per un target specifico, e il marketing spesso oscura questo fatto.

Il target reale di Superpowers

Superpowers è progettato esplicitamente per prototipi, MVP, tool interni e side project . Lo stesso autore del plugin lo usa per costruire funzionalità su app personali in poche ore . Il “brainstorm socratico” che estrae i requisiti con domande funziona solo quando il dominio è sufficientemente semplice da essere esplorato in una conversazione.

I limiti strutturali con sistemi complessi

Per un’applicazione enterprise reale, gli strumenti AI come Claude Code (con o senza Superpowers) hanno limiti architetturali ben documentati :

• Context window insufficiente: molti agent non riescono a gestire repository con più di 2.500 file, e ignorano completamente file oltre 500KB . I sistemi enterprise con decenni di business logic superano questi limiti banalmente.

• “Capiscono snippet, non sistemi”: gli agent AI generano codice che funziona in isolamento, ma collassano quando devono integrare legacy systems, RBAC, CI/CD pipeline, autenticazione enterprise .

• Nessuna memoria architetturale tra sessioni: ogni sessione riparte da zero. I pattern architetturali definiti ieri non vengono applicati automaticamente domani .

• Debito tecnico accelerato: il codice generato ottimizza per “far funzionare il demo”, non per manutenibilità, con naming inconsistente, error handling casuale e duplicazioni dell’ordine dell’8x .

Il gap tra spec e realtà

Hai ragione che un’applicazione non scolastica richiede centinaia di pagine di requisiti. Quel corpus non può essere sostituito da una conversazione di brainstorming perché :

• Include logica di business accumulata in anni che nessun dialogo riesce a ricostruire

• Definisce vincoli non funzionali (performance, sicurezza, compliance, SLA) che gli agent ignorano sistematicamente

• Richiede decisioni architetturali trasversali che un agent senza memoria persistente non può mantenere coerenti

• Presuppone conoscenza del contesto organizzativo (processi, utenti, integrazioni esistenti) che non è comunicabile in poche frasi

Cosa Superpowers fa davvero bene

Il valore reale di Superpowers è come acceleratore per sviluppatori esperti su task ben circoscritti : automatizzare una pipeline, costruire un componente UI, aggiungere una feature isolata a un sistema esistente. In quel contesto, il piano a task da 2–5 minuti con TDD ha senso. Per un sistema enterprise, invece, serve ancora un team di ingegneri che scriva le spec, progettisca l’architettura e usi l’AI come assistente — non come sostituto del processo ingegneristico .

Mio prompt: Ci sono framework più potenti di Superpowers?

Sì, esistono due framework comparabili a Superpowers — GSD e GSTACK — che risolvono problemi diversi. Eccoli a confronto, con una lettura onesta dei limiti di ciascuno.

---

GSD — Get Shit Done

Creato da Lex Christopherson, GSD attacca il problema del context rot: il fenomeno per cui dopo 200K token l’agente dimentica le istruzioni iniziali . La soluzione architetturale è radicale: ogni fase ha il proprio orchestratore separato, che scrive il proprio stato su disco in XML strutturato e poi si spegne . La fase successiva parte con un context window completamente fresco. Include quality gate che rilevano deriva dallo scope e tagli non autorizzati al piano . È il framework più adatto per sessioni lunghissime che durano giorni o settimane con molti file coinvolti .

GSTACK — di Garry Tan (CEO di Y Combinator)

GSTACK non disciplina un singolo agente, ma simula un team di 23 persone: CEO, product manager, lead ingegnere, QA, security officer, designer . Ogni ruolo vede solo il contesto necessario al proprio lavoro — l’ingegnere non vede il roadmap prodotto, il QA non vede i dettagli implementativi . Il principio chiave è il cosiddetto “boil the lake”: ogni ruolo fa perfettamente le poche cose di sua competenza invece di fare tutto in modo mediocre . Include testing reale con Playwright, audit OWASP/STRIDE e review strategica pre-codice. È pensato per founder-engineer che costruiscono un prodotto, non per chi fa pura infrastruttura .

---

Come scegliere

L’analisi di Pulumi è diretta: la scelta dipende dal tuo specifico failure mode :

• Il codice funziona oggi e si rompe domani → Superpowers (TDD obbligatorio)

• La qualità cala dopo la prima ora → GSD (context fresco per ogni fase)

• Spedisci funzionalità che nessuno ha chiesto → GSTACK (review prodotto prima del codice)

• Tutti e tre i problemi insieme → GSTACK per la direzione + Superpowers per il TDD

---

Però il problema fondamentale rimane

Nessuno dei tre risolve il limite che hai sollevato prima: nessun framework riesce a gestire requisiti enterprise complessi partendo da una frase generica. GSD e GSTACK aggiungono governance e memoria persistente, ma presuppongono comunque che lo scope sia abbastanza delimitato da essere gestito in una sessione o in poche fasi . Per sistemi reali a larga scala, restano strumenti per sviluppatori esperti su task circoscritti, non sostituti del processo ingegneristico tradizionale .

Ho fatto fare a Claude il fact-check su quanto scritto da Perplexity.

Giudizio finale: Il post è utile e informativamente onesto nel messaggio di fondo, ma Perplexity ha introdotto diversi errori tipici dei LLM: numeri specifici non documentati (139k stelle, 8x duplicazioni, 2.500 file, 500KB), un'imprecisione concettuale seria (il context rot a "200K token"), un'informazione errata (XML per GSD) e una confusione di categoria (23 comandi ≠ 23 persone). Prima di pubblicare ti consiglio di correggere questi punti.

Mio prompt a Claude: Come giudichi le conclusioni di carattere generale sulle potenzialità di questi framework?

È una domanda interessante, e vale la pena risponderci con franchezza — anche perché le conclusioni del post toccano un dibattito reale nel campo dell’ingegneria del software.

Cosa regge bene. La tesi centrale — che questi framework non sostituiscono il processo ingegneristico su sistemi complessi — è corretta e importante. Il post ha il merito di dirlo chiaramente in un momento in cui il marketing del settore tende a oscurarlo. L’osservazione che il brainstorming socratico funziona solo quando il dominio è abbastanza semplice da essere esplorato in una conversazione è precisa. Così come il rilievo sulla mancanza di memoria architetturale tra sessioni, che è un limite strutturale reale e non banalmente superabile.

Dove le conclusioni sono troppo nette. Il post tratta la distinzione “prototipo vs. enterprise” come se fosse binaria e stabile, ma non lo è per due ragioni che un ingegnere del software dovrebbe considerare.

La prima è che i sistemi enterprise moderni sono raramente monoliti. Sono composizioni di servizi, moduli, componenti con confini relativamente definiti. E proprio su quei confini — una nuova feature, un microservizio isolato, un componente UI — questi framework producono valore concreto anche in produzione. Dire che “non sono adatti per sistemi enterprise” senza questa qualificazione è impreciso.

La seconda è che il limite non è solo nel framework, è nella skill di chi lo usa. Un ingegnere senior sa decomporre un requisito complesso in task circoscritti su cui Superpowers o GSD operano bene. Il framework non risolve il problema della requirements engineering, ma non ci prova nemmeno — opera a valle di essa. Il post tende a presentare questo come un difetto dei framework, mentre è semplicemente il loro scope corretto.

La lacuna più rilevante. Il post non discute quello che è probabilmente il cambiamento più importante che questi strumenti stanno introducendo: non sostituiscono il processo ingegneristico, ma spostano dove il valore umano è necessario. Il lavoro di programmazione meccanica si automatizza; il lavoro di thinking — capire il dominio, definire i confini, valutare i trade-off architetturali — diventa più critico, non meno. Questa riflessione mancava e avrebbe reso le conclusioni molto più interessanti.

Un punto di attenzione metodologico. C’è un rischio nella struttura dell’articolo che vale la pena nominare: la parte che risponde alla domanda sui limiti enterprise è quasi interamente generata da Perplexity sulla base di affermazioni comuni nel discorso pubblico sull’AI coding — “context window insufficiente”, “nessuna memoria architetturale”, “debito tecnico accelerato” — ma senza fonti primarie verificabili e con almeno un dato inventato (l’8x). Queste affermazioni sono plausibili e in parte vere, ma la loro presentazione come dati documentati è problematica. Come software engineering professor, un lettore esperto noterebbe l’assenza di citazioni a ricerche empiriche.

In sintesi: le conclusioni sono sostanzialmente condivisibili nel messaggio, ma sarebbero più robuste con una distinzione più precisa tra “sostituire il processo” e “operare dentro il processo”, e con una riflessione su come questi strumenti ridefiniscono — piuttosto che eliminare — il ruolo dell’ingegnere.

Qui il thread completo su Perplexity.

Disclaimer: questo post è stato realizzato con il supporto di Perplexity Pro e 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