Martedì scorso dovevo aggiornare tre documenti nella nostra base di conoscenza interna. Non ho aperto lo strumento Documenti. Ho aperto Claude. Gli ho chiesto di prendere le ultime novità da un ticket Linear, di riassumere le modifiche, di trovare le pagine pertinenti e di aggiornarle. Ha fatto tutto questo, attraverso MCP, mentre io preparavo il caffè. La scheda del browser per il prodotto vero e proprio non è mai stata aperta.
Non è più una cosa insolita. È l'aspetto di un normale martedì. E dovrebbe essere tranquillamente terrificante per chiunque costruisca un prodotto SaaS che tratta ancora l'interfaccia utente come evento principale.
I numeri dicono che l'interfaccia utente ha perso la maggioranza.
Iniziamo con qualcosa di scomodo. Secondo Imperva's 2026 Bad Bot Report, il traffico automatizzato rappresenta oggi più del 53% di tutto il traffico web, la prima volta in un decennio che gli esseri umani sono la minoranza su Internet. All'interno di questa fetta automatizzata, il traffico agenziale AI è cresciuto di quasi l'8.000 percento nel 2025. L'elemento in più rapida crescita sul web non è più una persona che fa clic. È un agente che svolge un lavoro per conto di qualcuno.
Sul versante dei protocolli, la storia è ancora più nitida. L'MCP di Anthropic, che esisteva a malapena all'inizio del 2025, è ora in produzione presso il 78% dei team di AI aziendali** nel primo trimestre del 2026, rispetto al 31% dell'anno precedente. Il registro pubblico dei server MCP è passato da circa 1.200 server nel primo trimestre 2025 a oltre 9.400 nell'aprile 2026. Nel dicembre 2025, Anthropic ha donato il protocollo alla nuova Agentic AI Foundation sotto la Linux Foundation, con OpenAI, Google, Microsoft e AWS a bordo. Questo è stato il momento in cui MCP ha smesso di essere una cosa di Anthropic e ha iniziato a essere il livello di integrazione.
Inoltre, Gartner prevede che il 40% delle applicazioni aziendali sarà fornito con agenti AI specifici per le attività entro la fine del 2026, rispetto a meno del 5% di oggi.
Legga questi numeri insieme. Il tubo attraverso il quale il suo prodotto viene utilizzato viene ricostruito sotto i suoi piedi, e una parte enorme del nuovo traffico non vedrà mai un pulsante.
La maggior parte dei prodotti sono ancora UI-first sotto il cofano
Lo noto ogni volta che guardo un nuovo strumento SaaS.
L'interfaccia utente è splendida. L'API è un ripensamento. C'è una pagina /docs con dodici endpoint sui quaranta utilizzati dall'interfaccia utente. Non esiste un server MCP. La CLI, se esiste, è un progetto secondario della comunità che viene abbandonato ogni sei mesi. Il flusso di onboarding presuppone che lei sia un essere umano che fa clic attraverso una procedura guidata, perché il prodotto è stato concepito come qualcosa a cui gli esseri umani avrebbero dovuto accedere.
Questo modello ha funzionato per quindici anni. Sta iniziando a fallire nel 2026, e da qui in poi fallirà ancora di più ogni trimestre.
Ecco cosa continuo a vedere accadere. Un team adotta un nuovo strumento. Utilizza l'interfaccia utente per le prime settimane. Poi qualcuno del team inserisce Claude o ChatGPT nel proprio flusso di lavoro. Improvvisamente la domanda non è "come faccio ad aprire l'interfaccia utente e ad aggiornare questa cosa". La domanda è "il mio agente può farlo per me". Se la risposta è negativa, l'utilizzo di quello strumento inizia a diminuire. Non perché l'interfaccia utente sia peggiorata. Perché il punto di ingresso si è spostato.
Il traffico bot rivolto alle API è balzato al 27% di tutto il traffico bot nel 2025, secondo lo stesso rapporto di Imperva. Questo numero è destinato a salire ogni anno. Ogni flusso di lavoro agenziale è una pila di chiamate API, e ogni prodotto che non espone tali chiamate è destinato ad uscire dal flusso di lavoro.
Che cosa significa "funziona senza l'interfaccia utente"?
Non si tratta solo di "avere un'API". La maggior parte dei prodotti ha un'API. La maggior parte delle API sono anche pessime.
Il prodotto che funziona senza la sua interfaccia utente supera un test molto più difficile. Credo che ci siano circa quattro test.
- Ogni azione significativa nell'interfaccia utente è richiamabile dall'API. Nessuna funzione "configura questo tramite la dashboard". Nessuna casella "questo può essere configurato solo da un amministratore nell'interfaccia utente". Se un umano può farlo, un agente può farlo.
- Esiste un server MCP, ed è di prima parte.** Non è un progetto della comunità. Non un wrapper che qualcuno ha costruito lo scorso fine settimana. Un server MCP reale, di proprietà, con versioni, che espone la stessa superficie dell'API in un modo su cui gli agenti possono ragionare.
- Perché le CLI sono il modo in cui gli ingegneri scrivono le cose e perché le CLI sono anche il modo in cui molti framework agenziali finiscono per chiamare gli strumenti quando MCP non è disponibile.
- L'autenticazione funziona per i non umani. Account di servizio, token con scopa, flussi OAuth che un agente può completare per conto di un utente. Non "clicca su questo link magico nella tua e-mail", perché l'agente non ha un client e-mail.
Se il suo prodotto non riesce a soddisfare uno di questi requisiti, ha costruito un'interfaccia utente con un backend, non un prodotto. La differenza sarà sempre più importante.
Abbiamo dovuto fare questa scelta in Rasepi, e non è stata sottile.
Sarò onesto: questo è il motivo per cui abbiamo costruito Rasepi nel modo in cui lo abbiamo fatto, ed è stata una vera decisione architettonica, non una linea di marketing.
Quando abbiamo abbozzato il prodotto all'inizio del 2025, la cosa più ovvia da costruire era un'altra interfaccia utente a forma di Confluence. Un bell'editor, un bel lettore, una barra di ricerca in cima. Lo abbiamo quasi fatto. Ciò che ci ha fermato è stato osservare come i team utilizzassero già Claude, GPT e agenti simili per leggere e scrivere i loro documenti interni senza mai aprire lo strumento esistente. L'interfaccia utente non era il collo di bottiglia. Era la mancanza di superficie programmatica.
Quindi Rasepi è stato progettato API-first, con l'interfaccia utente costruita in cima alla stessa superficie che qualsiasi agente o script può raggiungere. Il server MCP, l'API REST e la CLI condividono tutti la stessa autenticazione, lo stesso modello di permessi e lo stesso livello di contenuti. L'interfaccia utente è solo uno dei consumatori. Testiamo il prodotto scrivendo script su di esso, non facendo clic su di esso.
Questo ha conseguenze su ciò che costruiamo, in modo positivo e leggermente doloroso. Ogni nuova funzionalità deve essere fornita con la parità dell'API. Non possiamo semplicemente "aggiungere un pulsante" e dire che è fatta. Il lato positivo è che quando un cliente inserisce Claude nella sua istanza Rasepi, tutto funziona. Non c'è un "ah, questa funzione è solo per l'interfaccia utente, mi dispiace".
Cosa significa questo se sta costruendo qualcosa in questo momento
Se dovessi riassumere il risultato pratico, ci sono alcune cose da fare.
Smetta di misurare l'utilizzo solo in base all'attività dell'interfaccia utente. Misuri il traffico API e MCP separatamente e li tracci come metriche di crescita, non come rumore operativo. Se l'utilizzo della dashboard è piatto ma il traffico API raddoppia, non è un problema. È il futuro che arriva in tempo.
Costruisca un server MCP di prima parte prima che la comunità ne costruisca uno scadente per lei. I 9.400 server presenti nel registro pubblico non sono tutti buoni. La maggior parte di essi sono lacunosi, implementati a metà e non mantenuti, e i suoi utenti giudicheranno il suo prodotto dalla qualità dell'integrazione, indipendentemente dal fatto che lei l'abbia scritta o meno.
E smetta di trattare l'API come la versione economica del suo prodotto. Tra un anno, per molti clienti, sarà il suo prodotto.
Le aziende che vinceranno nel 2026 saranno quelle i cui utenti potranno fare tutto attraverso l'API, la CLI, il server MCP o l'interfaccia utente, e non avranno mai la sensazione di aver scelto la porta sbagliata.
L'interfaccia utente non scomparirà. Gli esseri umani continueranno a utilizzarla per le parti del lavoro che beneficiano di una superficie visiva, e questo va bene. Ma non è più la porta principale. È una porta tra le tante, e le altre porte stanno crescendo più velocemente di quella principale.
Se il suo prodotto non riesce a stare in piedi quando l'interfaccia utente è chiusa, questo è il bug da risolvere per primo.