Qualche giorno fa ho letto un post di Mircha Emanuel D’Angelo sulla morte dell’interfaccia utente. Di quelli che ti rimangono addosso. L’ho letto, l’ho riletto, e poi ho iniziato a farci caso anche nella vita reale: quante energie mentali spendiamo solo per ricordarci dove si fa una cosa, in quale tab, in quale menu, in quale prodotto.
E mentre cercavo di addormentarmi, la domanda è diventata più fastidiosa e più interessante: se davvero la UI smette di essere il centro del software, cosa succede al resto? Perché forse non muore solo la schermata. Forse muore l’applicazione come l’abbiamo conosciuta.
Se muore la UI, non cade da sola
Quando diciamo “app”, di solito intendiamo un oggetto abbastanza chiaro. Ha un nome, un’icona, un posto nel dock, un abbonamento mensile, una personalità. E soprattutto ha un confine. Dentro c’è il mondo di Notion. Dentro c’è Jira. Dentro c’è Salesforce. Fuori c’è tutto il resto.
Mi sono accorto che quel confine, spesso, non è lì perché il problema lo richiede. È lì perché il modello economico lo richiede.
Un sacco di software moderno è costruito come un recinto. Non per cattiveria, magari. È solo che per anni il modo più semplice di monetizzare è stato questo: prendi un insieme di funzionalità, le impacchetti, ci costruisci intorno un’interfaccia che diventa familiare, ci metti dentro i dati dell’utente e poi fai in modo che uscire sia doloroso.
Mircha fa un parallelo che mi sembra illuminante: i server MCP come “nuovi programmi Unix”. E se è vero, allora la conseguenza naturale è un’altra, un po’ più scomoda. Le applicazioni SAAS, viste da lì, somigliano ai mainframe. Grandi monoliti nati in un’epoca in cui distribuire software era costoso e l’unico modo per farlo pagare era costruire muri.
In un mondo in cui un agente può comporre capability piccole e precise al volo, quel muro diventa più un ingombro che una protezione.
L’interfaccia generativa: non progettata, evocata
C’è un passaggio del post di Mircha che mi ha fatto fermare a riflettere. L’idea che la GUI passi da control panel a display. E mi è venuto da chiedermi: e se non fosse né l’una né l’altra?
Forse l’interfaccia, nel prossimo giro, diventa effimera.
Oggi un designer, quando progetta una schermata, sta facendo un compromesso. Cerca un layout che funzioni “abbastanza bene” per tante persone, in tanti contesti. Il risultato è spesso un’interfaccia solida, coerente, testata, ma inevitabilmente generica. Deve servire tutti, quindi non serve perfettamente nessuno.
Con un agente in mezzo, quel compromesso potrebbe saltare.
Non intendo “fare tutto via chat”, che è una caricatura comoda. Intendo un sistema che, data la tua intenzione, genera l’interfaccia giusta per quel momento. Un form non generico, ma con quei campi, in quell’ordine , con i default sensati per il tuo caso. Una dashboard non standard, ma la visualizzazione che risponde a una domanda precisa, con i dati necessari e niente rumore.
Queste UI non vengono mantenute. Non vengono versionate. Non hanno bisogno di una roadmap.
Vengono evocate e poi spariscono.
E la cosa inquietante è che non è nemmeno più fantascienza. Oggi già vediamo modelli che generano componenti, pagine, piccoli artefatti in React in tempo reale. È ancora grezzo, sì. Ma la direzione è difficile da ignorare.
A quel punto il ruolo del designer non sparisce, però cambia pelle. Da progettista di schermate diventa progettista di sistemi generativi. Design system, vincoli, pattern, regole. Un lavoro più simile a costruire una grammatica che a disegnare frasi.
L’agente come sistema operativo
Un’altra conseguenza che mi torna in testa è questa: forse la metafora giusta per l’agente non è “assistente”. È “sistema operativo”.
Un OS fa cose che diamo per scontate: astrae l’hardware, gestisce risorse, offre un’interfaccia unificata, permette a programmi diversi di convivere e parlarsi.
L’agente fa qualcosa di simile, un livello sopra. Astrae i servizi, gestisce contesti, offre un’interfaccia unificata (il linguaggio naturale), orchestra capability diverse.
Se questa metafora regge, allora succede una cosa quasi inevitabile: l’agente diventa la piattaforma. Non perché tutto “vive dentro” l’agente, ma perché tutto passa attraverso l’agente. Come oggi nessun software gira senza un OS, domani nessun servizio verrà usato senza un agente.
E qui entra la parte politica, o economica, che forse è la più delicata. Chi controlla l’agente controlla il punto di accesso al software. È una posizione che abbiamo già visto nella storia, solo con nomi diversi.
E mi chiedo se riusciremo a evitare la solita traiettoria. Quella che Cory Doctorow chiama enshittification. Prima tutto è utile e aperto, poi diventa una rendita, poi diventa un pedaggio.
Dall’app alla capability
Se l’applicazione perde senso, cosa resta?
Resta la capability.
Una capability è una funzione atomica esposta via protocollo, descritta in modo umano, invocabile da un agente. “Crea una fattura”. “Cerca questo contatto”. “Riassumi questi ticket e dimmi i rischi”. Non è un prodotto con un brand e un layout. È un mattoncino.
E appena pensi in termini di mattoncini, cambia anche l’economia.
Oggi paghi un abbonamento per un bundle: cento funzioni, ne usi venti, ma il prezzo è per tutte. Domani potresti pagare a consumo, capability per capability, nel momento in cui serve. Frazioni di centesimo per una singola azione ben fatta.
Questo manda in crisi tre vantaggi storici del SAAS:
Primo, l’interfaccia come lock-in. Se l’interfaccia è dell’agente, non è più tua.
Secondo, i dati come prigione. Se i dati stanno in vault personali e l’accesso è a permessi granulari, il recinto perde potere.
Terzo, il bundle. Se l’agente può comporre il meglio per ogni pezzo, il pacchetto monolitico diventa meno attraente.
A quel punto resta una cosa sola: la qualità della capability. Fai una cosa sola, falla meglio di tutti. È Unix come filosofia tecnica, ma anche come modello di business. Elegante, e un po’ spietato.
Il nuovo alfabetismo
C’è un’altra idea del post di Mircha che mi sembra sottovalutata: “non saper parlare con l’ai” come nuova forma di analfabetismo.
Per decenni abbiamo chiamato “alfabetizzazione digitale” una cosa molto specifica: saper usare interfacce. Cliccare, trascinare, navigare menu, compilare form. Abbiamo costruito corsi, certificazioni, ruoli professionali.
Se l’agente diventa l’interfaccia principale, tutto questo si sgonfia.
La competenza centrale diventa un’altra, e forse è più umana che tecnica. Saper esprimere un’intenzione con chiarezza. Saper dare contesto. Saper scomporre un problema. Saper giudicare un risultato e iterare.
E qui c’è un paradosso che mi affascina. Ci sono persone che non hanno mai imparato davvero Excel, ma sanno spiegare cosa vogliono con una precisione chirurgica. E ci sono power user che, messi davanti a un agente, non sanno cosa chiedere.
La mappa delle competenze si ridisegna.
E sì, il rischio di un nuovo digital divide è reale. Però c’è anche un’opportunità rara: per la prima volta, il vantaggio non è “saper parlare il linguaggio macchina”. È saper pensare e comunicare bene.
La sorpresa europea: compliance come capability
C’è un pezzo di questa storia che, secondo me, in Europa non possiamo ignorare.
Mentre la narrativa americana tende a vedere la regolazione come freno, qui stiamo costruendo un quadro normativo che tocca proprio i nervi scoperti di un mondo a capability componibili: AI Act, Cyber Resilience Act, Product Liability Directive, EAA.
In un sistema dove un agente combina tre capability di tre fornitori diversi, la domanda “chi è responsabile se qualcosa va storto?” diventa esplosiva.
Se la legge ti chiede tracciabilità, sicurezza, audit trail, spiegabilità, allora la compliance smette di essere solo un costo. Diventa una capability differenziante.
Lo SBOM come passaporto del componente. Il log delle azioni dell’agente come requisito. La trasparenza come vantaggio competitivo.
E qui c’è un ribaltamento quasi ironico: molte richieste storiche della cultura hacker, apertura, accountability, verificabilità, stanno diventando legge. Forse l’Europa, più che rallentare, sta costruendo l’infrastruttura di fiducia senza cui il mondo degli agenti non regge nelle aziende serie.
2030, un giorno qualunque (forse)
Provo a immaginare una giornata normale, senza voler fare fantascienza.
Non hai più “app” sul telefono. Hai un agente. Gli parli, scrivi, magari fai un gesto. Lui orchestra servizi diversi e tu non vedi quasi mai il dietro le quinte. Un po’ come oggi non pensi ai microservizi quando si apre una pagina.
L’interfaccia che vedi è stata generata per te, in quel momento. Tra cinque minuti non esiste più.
Il commercio diventa conversazione. “Mi servono scarpe da trail, budget 150 euro, terreno misto, preferisco suola Vibram.” L’agente conosce taglia, storico, preferenze, fonti affidabili. Ti propone tre opzioni con una comparazione fatta su misura. Scegli, fine.
In ufficio succede qualcosa di simile. Il PM non apre Jira, chiede “come stiamo messi su Alpha?” e ottiene stato, rischi, prossimi passi. Il commerciale non naviga il CRM, chiede “quali deal sono a rischio questa settimana?” e riceve un briefing. Lo sviluppatore descrive un comportamento e il sistema genera, testa, deploya.
I dati stanno in un vault personale, cifrato e portabile. Le capability chiedono permessi granulari, revocabili, e tutto è loggato. Ogni azione produce un audit trail.
In quel mondo, il valore sta in due cose: capability buone e fiducia.
Un realismo necessario
È inevitabile? Non lo so.
Le transizioni non sono mai lineari. Ci saranno resistenze economiche enormi. L’enterprise si muove con una lentezza quasi geologica. Le abitudini cambiano più lentamente dei comunicati stampa. E ci sono problemi tecnici veri: affidabilità su task complessi, gestione degli errori nelle catene di composizione, sicurezza, costi.
Però la direzione che Mircha mette a fuoco mi sembra difficile da ignorare, perché è sostenuta da due forze concrete.
Da una parte il costo cognitivo delle interfacce tradizionali, che cresce con ogni nuovo SAAS.
Dall’altra la capacità degli agenti di ridurre quel costo, che cresce con ogni iterazione dei modelli.
Quando la distanza tra i due supera una soglia, la transizione diventa pratica, non ideologica. E per alcuni casi d’uso, forse, quella soglia è già stata superata.
Mircha chiude chiedendo chi costruirà questo futuro e con quali valori. Io mi porto dietro un’altra domanda, un po’ più personale e un po’ più cinica: chi avrà il coraggio di costruire per questo futuro, sapendo che significa smontare il modello che oggi paga gli stipendi?
Perché il dilemma, alla fine, non è tecnico. È la volontà di cannibalizzare il presente.
E il tempo per decidere da che parte stare, probabilmente, non è infinito.
Questo post nasce dalla lettura di“La morte dell’interfaccia utente come la conosciamo” di Mircha Emanuel D’Angelo. Se non l’avete letto, secondo me vale la pena partire da lì.
Cosa ti porti a casa
Le applicazioni SaaS, viste dagli MCP, somigliano ai mainframe: monoliti nati per monetizzare quando distribuire era costoso.
L’agente non è assistente, è sistema operativo: chi lo controlla controlla il punto di accesso al software.
Il valore migra dall’app alla capability: fai una cosa, falla meglio di tutti.
In Europa la compliance smette di essere costo e diventa capability differenziante: tracciabilità e audit trail come vantaggio competitivo.
Il dilemma non è tecnico: è la volontà di cannibalizzare il modello che oggi paga gli stipendi.
Domande e risposte
Perché la morte della UI porta alla morte dell'idea di app?
Perché l’app come oggetto (nome, icona, dock, abbonamento, personalità) ha senso finché esiste un’interfaccia che la delimita. Se l’interfaccia scompare — sostituita da agenti AI che parlano a più servizi contemporaneamente — il confine dell’app smette di essere richiesto dal problema. Resta solo perché il modello economico lo richiede: prendere funzionalità, impacchettarle, rendere doloroso uscirne. Quel recinto, senza UI, non regge.
Cosa sono gli MCP server in questo contesto?
Secondo Mircha Emanuel D’Angelo, i nuovi “programmi Unix”: piccoli servizi specializzati che gli agenti AI compongono al bisogno. Sostituiscono le grandi applicazioni SaaS — che visti da lì assomigliano a mainframe degli anni ‘70 — con architetture modulari. Ogni MCP fa una cosa bene, gli agenti compongono flussi multipli in linguaggio naturale.
Cosa cambia per le aziende SaaS che oggi vivono di abbonamenti?
Il problema strutturale: se l’utente interagisce con un agente AI che compone funzionalità da dieci MCP diversi, il valore percepito non è più dell’app ma dell’agente. L’app diventa una commodity API-based, facilmente sostituibile dal concorrente che espone un MCP migliore. Il pricing dovrà spostarsi dall’accesso all’interfaccia all’accesso ai dati o alle funzionalità atomiche. Il modello seat-based è tra i primi a saltare.
Cosa dovrebbe fare un prodotto SaaS oggi per non essere disintermediato?
Tre mosse: (1) esporre funzionalità via MCP prima che glielo chiedano i clienti, non dopo; (2) separare chiaramente cosa è infrastruttura sostituibile da cosa è valore difendibile (relazioni contrattuali, dati esclusivi, competenza verticale); (3) smettere di investire in UI polish quando quella UI sta per smettere di essere il punto di ingresso. Ogni sprint che aggiunge un pulsante al posto di un endpoint MCP è sprint sprecato nel 2026.
L'autore
