La morte dell'interfaccia utente come la conosciamo

C’è qualcosa di profondamente ironico nella condizione dell’utente digitale nel 2026. Mai nella storia dell’informatica abbiamo avuto accesso a così tanti strumenti, così potenti, così economici. Eppure, chiunque lavori con un computer passa una porzione significativa della propria giornata non a fare cose, ma a navigare tra le cose. Apriamo applicazioni, cerchiamo funzionalità nei menu, compiliamo form, spostiamo dati da un sistema all’altro, impariamo interfacce nuove che sostituiscono quelle vecchie senza un motivo evidente. Il software prometteva di liberarci dal lavoro ripetitivo; invece, ha creato nuove forme di lavoro ripetitivo, travestite da “produttività”.

Il modello SaaS (Software as a Service) ha democratizzato l’accesso a strumenti che un tempo richiedevano investimenti enormi. Oggi chiunque può avere un CRM, un sistema di project management, una suite di analytics, pagando pochi euro al mese. Ma questa abbondanza ha un costo nascosto: ogni strumento è un mondo a sé, con la propria logica, il proprio vocabolario visivo, le proprie convenzioni. L’utente medio in un’azienda utilizza decine di applicazioni diverse, e ognuna richiede di essere imparata. L’interfaccia utente, nata per rendere il computer accessibile a tutti, è diventata essa stessa una barriera, una tassa cognitiva che paghiamo ogni giorno.

E se fosse il momento di chiederci: l’interfaccia grafica come la conosciamo è stata davvero il punto di arrivo, o solo una fase transitoria? E se il prossimo salto nell’interazione uomo-macchina fosse già in corso, silenziosamente, mentre ci ostiniamo a cliccare bottoni progettati negli anni Ottanta?

Dal terminale al touch, e ritorno

Per capire dove stiamo andando, vale la pena ricordare da dove veniamo. La storia dell’interfaccia utente è stata raccontata per decenni come un progresso lineare verso la “naturalezza”. Prima c’era la riga di comando, austera e potente, ma riservata agli iniziati che conoscevano la sintassi arcana. Poi arrivò l’interfaccia grafica (finestre, icone, menu, puntatore) e improvvisamente il computer diventò accessibile a chiunque sapesse muovere un mouse. Il Macintosh del 1984, Windows 95, il web con i suoi link cliccabili: ogni passo sembrava avvicinarci a un’interazione più umana, più intuitiva.

Il touch screen completò apparentemente questa parabola. Con l’iPhone nel 2007, l’interfaccia diventò letteralmente tattile: niente più intermediari, il dito tocca direttamente l’oggetto digitale. I bambini imparano a usare un tablet prima di saper leggere. Cosa potrebbe esserci di più naturale?

Ma ogni passaggio ha comportato dei trade-off che raramente vengono discussi. La GUI ha reso il computer accessibile ai non-tecnici, certo, ma ha anche nascosto la complessità invece di eliminarla. L’utente della riga di comando vedeva esattamente cosa stava succedendo; l’utente della GUI vede metafore (cartelle, cestini, finestre) che lo proteggono dalla realtà sottostante ma anche lo separano da essa. Il touch ha reso tutto “intuitivo” ma ha drammaticamente impoverito le possibilità di input: un dito su uno schermo può fare molto meno di una tastiera, e infatti sui dispositivi mobile siamo tornati a digitare, faticosamente, su tastiere virtuali.

La riga di comando non è mai veramente scomparsa. Gli sviluppatori non l’hanno mai abbandonata. Io vivo nel terminale. E c’è una ragione: la CLI è componibile. Piccoli programmi che fanno una cosa sola, collegati da pipe, orchestrati da script. È la filosofia Unix, enunciata da Doug McIlroy negli anni Settanta: “Scrivi programmi che fanno una cosa sola e la fanno bene. Scrivi programmi che lavorano insieme.”

Questa filosofia non ha mai trovato un equivalente nel mondo delle GUI. Le applicazioni grafiche sono monoliti che non parlano tra loro se non attraverso integrazioni faticosamente costruite. Ogni SaaS è un’isola.

Ed ecco che nel 2026 assistiamo a qualcosa di inaspettato: un ritorno all’interfaccia testuale, ma in una forma radicalmente nuova. Non la sintassi rigida del terminale, ma il linguaggio naturale. Non comandi da memorizzare, ma intenzioni da esprimere. E dietro, non un parser deterministico, ma un modello linguistico che capisce.

Il paradigma SaaS: trionfo e crisi

Prima di esplorare il nuovo, è necessario capire perché il vecchio sta scricchiolando. Il modello SaaS è stato un successo straordinario. Ha eliminato la necessità di installare software, ha abbattuto i costi di distribuzione, ha permesso aggiornamenti continui senza intervento dell’utente. Per le aziende software, ha trasformato vendite una tantum in flussi di ricavi ricorrenti. Per gli utenti, ha reso accessibili strumenti prima riservati alle grandi organizzazioni.

Ma il successo del SaaS ha portato con sé patologie strutturali che oggi sono evidenti.

La prima è la frammentazione. Poiché ogni problema specifico ha generato il suo SaaS dedicato, l’utente si trova a operare in decine di ambienti diversi. I dati sono sparsi ovunque: i contatti nel CRM, i task nel project manager, i documenti nel cloud storage, le conversazioni nella chat aziendale, le email nel client di posta. Strumenti come Zapier o Make sono nati proprio per costruire ponti tra queste isole, ma sono soluzioni fragili, che richiedono manutenzione costante e competenze tecniche non banali.

La seconda patologia è il feature creep. Un SaaS deve giustificare il suo abbonamento mensile. La risposta universale è aggiungere funzionalità. Slack, nato come semplice chat, è diventato una piattaforma con canvas, workflow, huddle, clip, e decine di integrazioni. Notion, nato come blocco note evoluto, è diventato database, wiki, project manager, sito web. Ogni strumento tende a espandersi fino a coprire territori adiacenti, gonfiando l’interfaccia, moltiplicando i menu, seppellendo le funzioni semplici sotto strati di complessità.

La terza patologia è più sottile: l’inversione del rapporto tra mezzo e fine. L’utente non vuole “usare Notion”, vuole organizzare le proprie idee. Non vuole “navigare Salesforce”, vuole capire se un cliente è pronto a comprare. L’interfaccia dovrebbe essere trasparente, un mezzo invisibile verso un risultato. Invece è diventata opaca, una presenza costante che richiede attenzione, apprendimento, manutenzione cognitiva.

Questa inversione era forse inevitabile. Un’interfaccia grafica è, per sua natura, un linguaggio imposto. Il designer decide quali azioni sono possibili, dove sono collocate, come si chiamano. L’utente deve imparare quel linguaggio. E poiché ogni applicazione ha designer diversi con idee diverse, l’utente deve imparare decine di linguaggi diversi, spesso incoerenti tra loro.

L’agente come nuovo paradigma

Il cambiamento in corso è radicale, anche se superficialmente può sembrare solo un’evoluzione. Non si tratta di aggiungere un chatbot a un’applicazione esistente, e quello è il modo in cui il vecchio mondo cerca di assorbire il nuovo senza capirlo. Si tratta di ripensare completamente il rapporto tra utente e software.

Nel paradigma tradizionale, l’utente compie azioni atomiche attraverso l’interfaccia: clicca un bottone, compila un campo, seleziona un’opzione. Il software esegue quell’azione specifica. Se l’utente vuole ottenere un risultato complesso, deve scomporre mentalmente il risultato in una sequenza di azioni atomiche e compierle una per una, spesso attraverso applicazioni diverse.

Nel paradigma emergente, l’utente esprime un’intenzione in linguaggio naturale, e un agente AI si occupa di tradurre quell’intenzione in azioni concrete. L’agente capisce cosa l’utente vuole ottenere, determina quali strumenti sono necessari, li orchestra, gestisce gli errori, e restituisce il risultato.

Consideriamo un esempio concreto: “Prepara un report settimanale per il team sui progressi del progetto Alpha, includendo i task completati, quelli in ritardo, e un grafico del burndown, poi mandalo via email a tutto il team.”

Oggi, questa frase innocente richiede: aprire il project manager, filtrare i task per progetto e settimana, esportare i dati, aprire un foglio di calcolo, creare il grafico, aprire un editor di documenti, formattare il report, tornare al project manager per la lista del team, aprire il client email, comporre il messaggio, allegare il documento, inviare. Venti minuti di lavoro manuale, trenta se qualcosa va storto.

Con un agente sufficientemente capace e ben integrato, è una frase. L’agente interroga l’API del project manager, elabora i dati, genera il grafico, compone il documento, recupera gli indirizzi email del team, e invia. L’utente esprime l’intenzione, l’agente gestisce la complessità.

Scrivo questo non come osservatore esterno, ma come praticante quotidiano. Le mie giornate lavorative si svolgono in larga parte in finestre di terminale dove conversazioni con agenti AI si alternano a comandi tradizionali. È un’esperienza ibrida, a cavallo tra due mondi: la precisione della CLI classica e la flessibilità del linguaggio naturale. E ciò che colpisce, dopo mesi di questa pratica, è quanto rapidamente il vecchio modo di lavorare (aprire applicazioni, navigare menu, compilare form) inizi a sembrare inefficiente, quasi primitivo. Non perché fosse sbagliato, ma perché ora esiste un’alternativa che si avvicina di più al modo in cui pensiamo.

Questo non è fantascienza. Nel 2026, abbiamo strumenti che supportano nativamente decine di integrazioni via MCP, con memory persistente che mantengono il contesto tra sessioni, con capacità di ragionamento che permettono di gestire task multi-step: siamo già dentro questa transizione!

MCP: il protocollo che abilita la composizione

Il Model Context Protocol, introdotto da Anthropic e rapidamente adottato come standard de facto, è il tassello tecnico che rende possibile questo nuovo paradigma. Per capirne l’importanza, è utile un’analogia con la storia del web.

Negli anni Ottanta, i computer potevano già comunicare in rete, ma ogni sistema usava protocolli diversi. Poi arrivò HTTP, un protocollo semplice e universale: qualsiasi client poteva parlare con qualsiasi server, purché entrambi rispettassero le stesse convenzioni. Questa standardizzazione permise l’esplosione del web. Non importava se usavi un Mac o un PC, Netscape o Internet Explorer: la pagina web era la stessa.

MCP fa qualcosa di simile per gli agenti AI. Definisce un modo standard per esporre capability, cose che un servizio sa fare, e per permettere agli agenti di scoprirle e utilizzarle. Un server MCP può esporre l’accesso a un filesystem, a un database, a un’API di terze parti, a qualsiasi risorsa o funzionalità. Un client MCP, tipicamente un agente AI, può connettersi a questi server, scoprire quali capability sono disponibili, e usarle per compiere azioni.

L’architettura è elegante nella sua semplicità. Il server MCP dichiara quali “tool” mette a disposizione, con una descrizione in linguaggio naturale di cosa fanno e quali parametri accettano. L’agente AI, quando deve compiere un’azione, può esaminare i tool disponibili, scegliere quello appropriato, invocarlo con i parametri giusti, e interpretare il risultato. Il protocollo gestisce la comunicazione, l’autenticazione, la gestione degli errori.

Quello che rende MCP potente non è la singola integrazione, ma la composizione. Un agente connesso a dieci server MCP diversi può combinare le loro capability in modi che nessuno dei singoli servizi aveva previsto. Può leggere dati da un database, elaborarli, scrivere i risultati in un documento, e inviarlo via email, il tutto in un’unica conversazione, orchestrando servizi che non sanno nulla l’uno dell’altro.

C’è un’eco della filosofia Unix in tutto questo: “Scrivi programmi che fanno una cosa sola e la fanno bene. Scrivi programmi che lavorano insieme.” I server MCP sono i nuovi programmi Unix: piccoli, focalizzati, componibili. Ma invece di essere collegati da pipe e orchestrati da script bash, sono collegati da un protocollo standard e orchestrati da un modello linguistico che capisce le intenzioni.

Il tramonto dei RAG tradizionali

Un altro cambiamento tecnico merita attenzione, perché illumina la direzione del paradigma emergente. Fino a pochi mesi fa la soluzione standard per dare agli LLM accesso a conoscenza esterna è stata il RAG (Retrieval-Augmented Generation). L’idea è semplice: prendi i tuoi documenti, spezzettali in chunk, trasformali in vettori numerici (embedding), salvali in un database vettoriale. Quando l’utente fa una domanda, trasforma la domanda in un vettore, cerca i chunk più “simili”, e iniettali nel prompt insieme alla domanda. Il modello risponde usando quelle informazioni.

Il RAG ha funzionato, e continua a funzionare per certi casi d’uso. Ma i suoi limiti sono diventati sempre più evidenti. Il chunking spezza il contesto: un documento coerente viene tagliato in pezzi che perdono il significato complessivo. Il retrieval è imperfetto: la similarità vettoriale non sempre cattura la rilevanza semantica. L’utente non ha controllo né visibilità su cosa viene recuperato. E l’architettura presuppone che la conoscenza sia statica, indicizzata una volta e poi interrogata, mentre spesso la conoscenza rilevante cambia continuamente o va verificata alla fonte.

Nel 2026, diverse evoluzioni tecniche hanno eroso la centralità del RAG. Le finestre di contesto sono enormemente più ampie: modelli che accettano centinaia di migliaia di token possono semplicemente contenere documenti interi invece di recuperarne frammenti. La memory persistente, integrata nativamente anche nei prodotti consumer come Claude, permette di mantenere contesto attraverso conversazioni diverse senza bisogno di infrastrutture esterne. Il tool use maturo permette di interrogare fonti in tempo reale invece di affidarsi a indici potenzialmente obsoleti.

Il RAG non scompare, ma cambia ruolo. Da architettura portante, diventa uno strumento tra tanti che l’agente può decidere di usare quando appropriato. Per cercare in un archivio enorme di documenti storici, un indice vettoriale ha ancora senso. Per rispondere a una domanda sui dati del trimestre corrente, meglio interrogare direttamente il database. L’agente, non l’architettura, decide quale approccio usare.

Questo riflette un pattern più ampio: nel nuovo paradigma, le scelte architetturali si spostano dal design-time al run-time. Non è il progettista del sistema che decide come recuperare l’informazione; è l’agente che decide, caso per caso, in base al contesto e all’intenzione dell’utente.

Cosa resta dell’interfaccia?

Se l’interazione primaria con il software diventa conversazionale, mediata da agenti che capiscono il linguaggio naturale, qual è il destino dell’interfaccia grafica? La GUI è destinata a scomparire?

La risposta, probabilmente, è più sfumata. L’interfaccia grafica non scompare, ma il suo ruolo cambia. Da control panel, il luogo dove l’utente compie azioni, diventa display, il luogo dove l’utente visualizza risultati e conferma decisioni.

Alcune funzioni dell’interfaccia grafica restano essenziali. La visualizzazione di informazioni complesse (grafici, mappe, tabelle, diagrammi) beneficia enormemente della rappresentazione visiva. Nessuna descrizione testuale sostituisce un grafico ben fatto per cogliere un trend. L’agente può generare la visualizzazione, ma l’interfaccia deve mostrarla.

La conferma di azioni critiche è un altro ambito dove l’interfaccia mantiene un ruolo. Vogliamo davvero che un agente cancelli file, invii email importanti, o modifichi dati sensibili senza un passaggio esplicito di conferma? Un bottone “Conferma” o “Annulla” può sembrare primitivo, ma è un checkpoint di sicurezza essenziale.

L’esplorazione senza una domanda precisa è un terzo caso. A volte non sappiamo cosa cercare. Vogliamo navigare, farci un’idea, scoprire cosa c’è. Un’interfaccia navigabile permette la serendipità; una conversazione richiede di sapere già cosa chiedere.

Infine, c’è la questione dell’accessibilità. Non tutti possono o vogliono interagire tramite testo. Difficoltà linguistiche, disabilità cognitive, preferenze personali: un’interfaccia visiva con elementi cliccabili resta più accessibile per molti utenti.

Ma il baricentro si sposta. L’interfaccia grafica diventa un complemento dell’interazione conversazionale, non il canale primario. L’utente parla con l’agente per dire cosa vuole; l’interfaccia mostra i risultati e permette interventi puntuali. È un’inversione rispetto al modello attuale, dove l’interfaccia è primaria e l’eventuale assistente AI è un add-on.

La prospettiva hacker: liberazione o nuova dipendenza?

Per chi è cresciuto nella cultura hacker, per chi ha letto il Jargon File e i saggi di Raymond, per chi considera la libertà del software un valore fondante, questo nuovo paradigma presenta una tensione profonda.

Da un lato, c’è qualcosa di genuinamente liberatorio. Per decenni, l’utente non-tecnico è stato prigioniero delle interfacce che altri avevano progettato per lui. Non poteva modificarle, non poteva estenderle, spesso non poteva nemmeno capirle veramente. Doveva adattare il suo modo di pensare al linguaggio del software. Ora, per la prima volta, il rapporto può invertirsi: è il software che si adatta al linguaggio dell’utente. Chiunque sappia esprimere un’intenzione può comandare una macchina complessa. È una democratizzazione del potere computazionale che avrebbe fatto sorridere Engelbart.

MCP è un protocollo aperto. La specifica è pubblica, le implementazioni sono disponibili, chiunque può costruire server e client. C’è un ecosistema vivace di integrazioni open source. La filosofia Unix della composizione, che sembrava persa nel mondo dei monoliti SaaS, torna in una forma nuova.

Ma dall’altro lato, le preoccupazioni sono serie. Chi controlla l’agente? Nel modello SaaS, almeno, i dati risiedevano su server specifici, le interfacce erano ispezionabili, i flussi di lavoro erano prevedibili. Nel modello ad agenti, ogni intenzione passa attraverso un modello linguistico. Se quel modello è proprietario, se è un servizio di Anthropic, OpenAI, Google, la dipendenza è totale e opaca.

Richard Stallman ha sempre insistito sulla differenza tra “software libero” e “software gratuito”. Il software libero è quello di cui puoi studiare il codice, modificarlo, ridistribuirlo. Garantisce libertà, non solo prezzo. Ma gli LLM più capaci non sono software libero in nessun senso significativo. Anche i modelli “open weight” (quelli di cui vengono rilasciati i pesi) non sono veramente open source: non puoi riaddestrarli senza risorse enormi, non puoi sapere esattamente cosa hanno imparato e da dove, non puoi modificarli in modo significativo.

Cory Doctorow ha coniato il termine enshittification per descrivere il ciclo inevitabile delle piattaforme: prima attraggono gli utenti con valore genuino, poi estraggono valore dagli utenti per darlo ai business partner, infine estraggono valore da tutti per massimizzare il profitto, finché la piattaforma diventa inutilizzabile e collassa. Se gli agenti AI diventano il layer universale di interazione con il software, cosa impedisce lo stesso ciclo?

La trasparenza è un’altra preoccupazione cruciale. Quando clicco un bottone in un’interfaccia, so cosa sto facendo, o almeno posso saperlo, se voglio ispezionare. Quando chiedo a un agente di fare qualcosa, quali azioni compie realmente? Quali dati legge? A quali servizi li trasmette? L’opacità del ragionamento degli LLM si estende all’opacità delle azioni.

Bruce Schneier parla di trust nei sistemi tecnologici: di chi ci fidiamo, perché, e cosa succede quando quella fiducia viene tradita. Affidarsi a un agente AI significa fidarsi dell’azienda che lo sviluppa, della sua infrastruttura, delle sue policy, delle sue decisioni future. È una fiducia molto concentrata.

Scenari futuri e domande aperte

È impossibile prevedere con certezza come evolverà questo paradigma. Ma possiamo immaginare scenari alternativi e chiederci quali condizioni li renderebbero più o meno probabili.

Lo scenario ottimista vede l’emergere di un ecosistema aperto e competitivo. MCP e protocolli simili diventano standard consolidati, adottati universalmente. Modelli open source raggiungono capacità competitive con quelli proprietari, permettendo a chiunque di controllare il proprio agente. I server MCP proliferano, offrendo integrazioni con ogni servizio immaginabile. L’utente può scegliere quale modello usare, quali capability abilitare, dove risiedono i suoi dati. Il software diventa davvero componibile e personalizzabile come mai prima. Gli hacker costruiscono configurazioni elaborate di agenti e strumenti, condividendole come un tempo condividevano dotfiles e script.

Lo scenario pessimista vede la concentrazione del potere in pochi gatekeeper. Due o tre aziende controllano gli agenti dominanti, perché addestrare modelli competitivi richiede risorse che solo loro possono permettersi. Ogni interazione con il software è mediata, registrata, analizzata, monetizzata. Le integrazioni MCP esistono, ma quelle davvero utili richiedono abbonamenti premium. I modelli open source restano sempre un passo indietro, sufficienti per sperimentare ma non per lavorare seriamente. L’interfaccia conversazionale diventa il nuovo walled garden, più insidioso perché più “naturale”: non sembrano muri, sembra solo una conversazione con un assistente gentile.

Lo scenario più probabile, forse, è una via di mezzo. Agenti proprietari domineranno il mercato consumer, dove la facilità d’uso e l’integrazione sono priorità. Ma nel mondo enterprise, nella comunità tecnica, tra chi ha competenze e motivazioni per costruire alternative, emergeranno soluzioni ibride. Modelli locali per compiti sensibili, agenti self-hosted per organizzazioni che non vogliono dipendere da cloud esterni, ecosistemi di strumenti open source per chi è disposto a investire tempo in cambio di controllo.

Restano domande aperte che richiederanno risposte negli anni a venire. Come garantire trasparenza nelle decisioni dell’agente? Un log delle azioni compiute è sufficiente, o serve qualcosa di più? Come preservare la privacy quando ogni intenzione passa per un modello che potrebbe essere addestrato sui dati degli utenti? Come evitare che “non saper parlare con l’AI” diventi la nuova forma di analfabetismo digitale, escludendo chi fatica a esprimersi in modo chiaro e strutturato? Come regolare un paradigma dove le azioni sono mediate da sistemi che nessuno capisce completamente?

Un viaggio che ricomincia

Circa 38 anni fa (sic! fa strano scriverlo), davanti a un Amstrad CPC464 con il suo monitor a fosfori verdi, imparavo a dialogare con una macchina. Non c’erano icone da cliccare, non c’erano finestre da trascinare: c’era un cursore lampeggiante e la necessità di sapere cosa scrivere. Ogni comando era una piccola conquista, ogni errore di sintassi una lezione. Poi vennero le BBS, le notti passate a esplorare mondi testuali attraverso un modem gracchiante, e infine Metro Olografix, la scoperta che dietro quei terminali c’era una comunità, una cultura, un modo di pensare il rapporto tra umani e macchine. La GUI, quando arrivò, era promettente ma anche sospetta: semplificava, certo, ma a quale prezzo? Nascondeva, ma cosa?

Oggi siamo a un passaggio simile, forse più profondo. L’interfaccia grafica non muore (nulla muore davvero nel software, i layer si accumulano) ma cambia ruolo, si ritira sullo sfondo, cede il centro della scena a qualcosa di nuovo. L’interazione conversazionale, mediata da agenti che capiscono e agiscono, promette di liberarci dalla tirannia delle interfacce imposte. Ma ogni liberazione porta nuove dipendenze, ogni democratizzazione nasconde nuove concentrazioni di potere.

Il Model Context Protocol è aperto. Gli agenti possono essere self-hosted. Le alternative esistono, per chi le cerca. Ma la direzione di default, quella che seguirà chi non sceglie consapevolmente, porta verso pochi grandi fornitori che mediano ogni interazione con il digitale.

La domanda non è se questo futuro arriverà: sta già arrivando. La domanda è chi lo costruirà, secondo quali valori, con quali salvaguardie. È una domanda tecnica, ma anche politica, etica, sociale. È la domanda che la cultura hacker si pone da sempre, ogni volta che una nuova tecnologia ridefinisce il rapporto tra umani e macchine.

La risposta, come sempre, dipenderà da chi si farà carico di darla.