“Non c’è nulla di nuovo sotto il sole” (Qoelet)
Due esempi recenti di un’industria (AI) che troppo spesso propone come nuovo ciò che ha quarant’anni, o anche settanta.
La citazione dal libro biblico di Qoelet (anche detto Ecclesiaste) è volutamente provocatoria: non è vera in assoluto, ma diventa vera se guardiamo a ciò che sta succedendo nel mondo dell’AI. Non conoscendo a sufficienza la storia dell’informatica, o volendo in modo malizioso riverniciare di nuovo ciò che nuovo non è, stiamo creando nuovi termini o “riscoprendo l’acqua calda.”
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.
È come voler andare sulla Luna e discutere se passare dalla bicicletta allo scooter.
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.
Se il contenuto, la conoscenza e le relazioni sono rappresentati in modo organico e completo, il rendering diventa un aspetto secondario, che si sa affrontare.
Si potrebbe obiettare che questi “razzi” non raggiungono gli “spazi” in cui si è in grado di rispondere alle sfide degli LLM, e che le ontologie sono state tentate e poi abbandonate. È in parte vero. Ma chi sollevasse questa obiezione, implicitamente, riconoscerebbe che il problema della rappresentazione esiste e non è ancora risolto.
Inoltre, paradossalmente, si sottovalutano le potenzialità dei sistemi di GenAI che potrebbero aiutare ad applicare ciò che in precedenza era troppo complesso o costoso.
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.
Otto varianti — sei nomi di ruolo e due modelli operativi — in settant'anni. La funzione è invariata: ingegnere o consulente che opera all’interno dell’organizzazione del cliente per integrare tecnologie complesse nei suoi processi. Cambiano gli strumenti, cambia il pricing, cambia l’etichetta. La funzione resta.
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.
Il prezzo si paga nel medio e nel lungo termine. Si alloca male il capitale. Si investono energie per risolvere problemi che la disciplina aveva già affrontato in forme più mature.
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.
© 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 mio primo giorno di lavoro il concetto di Service Oriented Architecture era il topic più hot del momento. In 20 anni ho rivisto lo stesso concetto ri-emergere con un nuovo nome numerose volte, e ogni volta sembrava ci fossimo dimenticati tutto. Non avevo mai pensato al collegamento biblico, ma evidentemente si tratta di una caratteristica dell'esperienza umana, dovuta alla nostra memoria limitata. Allargando il perimetro, lo vediamo anche con i challenge sociali a livello globale. Una cosa che fa molta paura é che sono passati tanti anni dall'ultima grande guerra con impatto mondiale e perdere la memoria di quella é estremamente pericoloso.