Dal software al dato, trasformandoci.
Perché il 2026 è l'anno in cui ripensare cosa significa costruire prodotti digitali
Qualche notte fa ho letto un articolo. Si intitola The Death of Software 2.0 e usa una metafora che mi è rimasta in testa: paragona il software del futuro alle gerarchie di memoria dei computer. La memoria veloce ed effimera, quella che chiamiamo dram, sarebbe l’intelligenza artificiale che processa in modo non deterministico. La memoria persistente, la nand, sarebbe il dato strutturato, le api, quella che chiamiamo single source of truth. La conclusione dell’autore è brutale: il software orientato all’interfaccia utente sta diventando obsoleto. Ciò che avrà valore sono i dati e le api attraverso cui gli agenti ai accedono ai sistemi.
Leggendo quell’articolo qualcosa ha fatto click nella mia testa. Non perché fosse una teoria affascinante. Perché descriveva esattamente quello che sto cominciando a fare nel mio lavoro, quello che sento necessario fare, anche se una parte di me resiste ancora.
Ho passato quindici anni a costruire software con una logica di valore semplice: prima l’interfaccia, poi l’api. Dal punto di vista del cliente la UI era il prodotto, l’API un’aggiunta, un complemento per gli integratori, qualcosa da documentare quando avanzava tempo. Questo modello funzionava perché il software doveva essere usato da persone. Ora non è più così, o almeno non è più solo così.
Claude, ChatGPT, Gemini, gli agenti ai, gli strumenti agentic in generale non usano il software come lo usa un umano. Non cliccano pulsanti. Non seguono flussi di ux. Non si confondono con i diciassette casi edge nella form di checkout che ho passato settimane a gestire. Hanno bisogno di tre cose: dati strutturati e accessibili tramite API ben disegnate, contesto persistente che possono comprendere in una conversazione, azioni deterministiche e ripetibili che possono orchestrare senza errori. Se il prodotto che costruisci non è pensato attorno a questi tre pilastri, lo stai costruendo per il 2015.
E qui devo essere onesto con me stesso. Per anni ho messo l’anima nelle interfacce. Ho discusso per ore su quale fosse il colore giusto per un bottone, su come organizzare un menu, su quale microinterazione avrebbe reso l’esperienza più fluida. Non era tempo sprecato, lungi da me dire questo. Ma mi chiedo se non stessi costruendo cattedrali su fondamenta che stavano già iniziando a tremare.
Il Model Context Protocol è lo standard che Anthropic ha rilasciato a novembre 2024. Lo hanno adottato immediatamente OpenAI e Google. È il ponte standardizzato tra un’intelligenza artificiale e i sistemi aziendali. Fino a oggi, ogni integrazione ai era un progetto custom: raw api calls nella app, pipeline rag fragili, tool calling bespoke, nessuna reusabilità, nessuna governance. Con MCP il paradigma cambia. Esponi il tuo sistema come MCP server. L’ai lo consuma come un client standardizzato. Lo autentichi una volta. Lo governi una volta. Lo monitori una volta.
Non è poco. È l’equivalente di come http ha standardizzato la comunicazione sul web negli anni novanta. E come http, cambierà tutto senza che la maggior parte delle persone se ne accorga.
Provo a immaginare cosa significherebbe concretamente per i clienti con cui lavoro.
Oggi il flusso è questo: il cliente accede alla ui, clicca per otto o dieci azioni diverse, esporta dati in csv, li incolla in un’altra app, ottiene il risultato. È un processo che funziona, che abbiamo ottimizzato negli anni, che i clienti conoscono. Ma è anche un processo che richiede tempo, attenzione, competenza specifica su come funziona quel particolare software.
Il flusso futuro potrebbe essere questo: il cliente parla a Claude/ChatGPT/Gemini/whatever e dice “processa questi dati e dammi il rapporto”. Claude si connette direttamente al sistema via MCP, legge i dati, li elabora, scrive il risultato nella tabella giusta. Tutto in dieci secondi, nessun clic. Non è ai che conosce il software. È il software che diventa consumabile da ai. E con strumenti che tutti già usano quotidianamente.
Scrivo queste parole e sento una resistenza interna. Costruire interfacce è stato il mio lavoro per anni. C’è qualcosa di umano nel disegnare un’esperienza, nel pensare a come una persona interagirà con qualcosa che hai creato. C’è anche, devo ammetterlo, una forma di controllo. Quando progetti un’interfaccia, decidi tu il flusso. Guidi l’utente. Scegli cosa può fare e cosa no, in quale ordine, con quali vincoli. Aprire tutto questo a un agente ai significa cedere quel controllo. Significa fidarsi che il sistema farà la cosa giusta anche quando non puoi prevedere esattamente cosa chiederà l’utente.
Ma forse è proprio qui il punto. Forse quel controllo era sempre un’illusione, un modo per gestire la complessità riducendo le opzioni invece di affrontarla davvero.
I dati di mercato sono chiari. Più dell’ottanta per cento dei team di sviluppo seguono già una metodologia api-first. Si stima un miliardo e settecento milioni di api attive nel 2030, un aumento del trecento per cento rispetto al baseline attuale. Chi adotta api-first rispetto ad approcci tradizionali vede una riduzione del 37% nei costi di integrazione. Ma il dato che mi ha colpito di più è questo: Gartner stima che più del quaranta per cento dei progetti con agenti AI sarà cancellato entro il 2027 se non hanno una governance solida.
Ecco il punto dove tutto si complica, dove la visione tecnologica si scontra con la realtà operativa. MCP oggi ha gap importanti. Non c’è uno standard di autenticazione: ogni implementazione è diversa. Il sandboxing è debole: se un agente prende il controllo, dove lo fermi? Ci sono rischi di prompt injection: come garantisci che l’AI non sia manipolata per fare azioni indesiderate? E ci sono lacune nell’auditing: come tracci chi ha fatto cosa e quando?
La Commissione Europea e le banche centrali europee stanno già spingendo verso api trasparenti, controllabili, auditabili. Non è solo una scelta tecnica. È una scelta di sopravvivenza normativa. E qui si apre un territorio che conosco bene, quello del bilanciamento tra innovazione e compliance, tra quello che potresti fare e quello che dovresti fare.
Mi trovo spesso a riflettere su questo equilibrio. Da una parte c’è la spinta a muoversi velocemente, ad adottare nuove tecnologie prima dei competitor, a essere i primi a offrire ai clienti qualcosa che non sapevano nemmeno di volere. Dall’altra c’è la responsabilità verso quei clienti, verso i loro dati, verso la sostenibilità di lungo periodo. Non sono sempre in conflitto, ma a volte lo sono. E quando lo sono, la scelta non è mai ovvia.
Ho visto aziende muoversi troppo velocemente e bruciare la fiducia dei clienti con implementazioni AI che non erano pronte. Ho visto aziende muoversi troppo lentamente e diventare irrilevanti mentre il mercato cambiava attorno a loro. Il tradeoff perfetto non esiste. Esiste solo la capacità di scegliere consapevolmente, sapendo cosa stai sacrificando e perché.
Quello che sto esplorando concretamente è un layer backend che espone i dati del cliente come MCP server. Un set di istruzioni e configurazioni per AI che sa come interrogare quel server. Un’interfaccia di governance dove il cliente può decidere cosa l’AI può leggere e cosa no, quale azione può compiere e quale non può. Un audit trail completo che traccia ogni interazione, ogni decisione, ogni errore.
Il risultato, se funziona, è che il cliente non avrà bisogno di noi per tre quarti dei task ripetitivi. Avrà bisogno di noi per mantenere il sistema pulito, per aggiungere nuove sorgenti di dati, per governance e compliance, per problemi che richiedono giudizio umano. È un cambio di rapporto: da chi fa il lavoro a chi rende il lavoro automatizzabile.
Scrivo questa frase e mi rendo conto di quanto sia radicale. Sto pensando a qualcosa che ridurrà la quantità di lavoro che i clienti mi chiederanno di fare. Dal punto di vista del fatturato immediato, è una follia. Dal punto di vista del valore di lungo periodo, credo sia l’unica strada sensata. I clienti pagano perché amano pagare. Pagano perché hai qualcosa di cui hanno bisogno. Se possiamo dare loro lo stesso valore, o maggiore, con meno frizione, perché non dovremmo? E se non lo fai tu, lo farà qualcun altro.
C’è una frase che mi ripeto spesso: il valore non sta nel lavoro che fai, sta nel problema che risolvi. Per anni ho misurato il mio valore in termini di ore, deliverable, feature rilasciate. Adesso mi chiedo se non dovrei misurarlo in termini di problemi eliminati, attrito ridotto, capacità restituita ai clienti di fare quello che sanno fare meglio.
La finestra temporale per questo cambiamento è adesso, nel 2026. MCP è standard, supportato dai tre principali provider di ai. I gap di sicurezza vengono chiusi progressivamente. I clienti cominciano a capire che vogliono qualcosa tipo “parla a ChatGPT e fatto”. Chi non si muove in questa direzione sarà tagliato fuori. Non domani. Adesso.
Ma “adesso” non significa “a qualunque costo”. Non significa sacrificare la sicurezza dei dati per la velocità di implementazione. Non significa promettere ai clienti funzionalità che non sono ancora mature. Non significa ignorare le normative perché sono scomode. Significa trovare il modo di muoversi velocemente nella direzione giusta, con gli occhi aperti su dove stai andando.
C’è qualcosa che mi solletica particolarmente quando penso a tutto questo. Non è la paura di sbagliare tecnicamente. Quella c’è, ma è gestibile. È qualcosa di più profondo. È la consapevolezza che le decisioni che prendiamo oggi come costruttori di software stanno definendo il rapporto che le persone avranno con la tecnologia domani. Ogni API che esponiamo, ogni dato che rendiamo accessibile, ogni azione che automatizziamo crea un precedente. Stabilisce cosa è normale, cosa è accettabile, cosa ci si aspetta.
Penso ai nostri clienti, persone che gestiscono aziende, che hanno dipendenti, che servono a loro volta altri clienti. Quando apro i loro sistemi all’AI, sto cambiando il modo in cui lavorano. Sto ridefinendo quali competenze saranno necessarie, quali ruoli avranno senso, come sarà strutturata la loro giornata. Non è una responsabilità da prendere alla leggera e dobbiamo aspettarci molta più resistenza perché quello che offriamo non è un software ma un cambiamento (a volte sostanziale) di ruoli e processi interni, nonché di gerarchie.
Ma è anche un’opportunità straordinaria. La possibilità di liberare tempo ed energia umana per attività che richiedono davvero intelligenza, creatività, giudizio. Di ridurre il lavoro ripetitivo che consuma le persone senza aggiungere valore. Di rendere le piccole aziende competitive con le grandi, perché l’accesso all’automazione non sarà più una questione di budget per team dedicati.
Forse è questo il tradeoff fondamentale. Da una parte il rischio di costruire sistemi che sfuggono al controllo, che creano dipendenze, che concentrano potere in mani sbagliate. Dall’altra la possibilità di costruire qualcosa che davvero aiuta le persone a lavorare meglio, a vivere meglio, a dedicare il loro tempo a ciò che conta.
Ed ho la convinzione che restare fermi non sia un’opzione e la determinazione a muovermi nella direzione che mi sembra giusta, un passo alla volta, con gli occhi aperti.
E insomma, questo è quello che sto facendo.
Se riconosci questa traiettoria e vuoi fare due chiacchiere su dove potrebbe portarci, parliamone.