El martes pasado necesité actualizar tres documentos de nuestra base de conocimientos interna. No abrí la herramienta docs. Abrí Claude. Le pedí que cogiera lo último de un ticket de Linear, resumiera los cambios, encontrara las páginas pertinentes y las actualizara. Hizo todo eso, a través de MCP, mientras me preparaba un café. La pestaña del navegador para el producto real nunca se abrió.
Esto ya no es inusual. Es lo que parece ahora un martes normal. Y debería ser tranquilamente aterrador para cualquiera que esté construyendo un producto SaaS que todavía trate la interfaz de usuario como el evento principal.
Los números dicen que la UI perdió la mayoría
Empecemos con algo incómodo. Según Imperva's 2026 Bad Bot Report, el tráfico automatizado representa ahora más del 53% de todo el tráfico web, la primera vez en una década que los humanos son minoría en Internet. Dentro de esa porción automatizada, el tráfico agéntico de la IA creció casi un 8.000 por ciento en 2025. Lo que más crece en la web ya no es una persona haciendo clic. Es un agente haciendo un trabajo en nombre de alguien.
En cuanto al protocolo, la historia es aún más aguda. El MCP de Anthropic, que apenas existía a principios de 2025, está ahora en producción en el 78% de los equipos de IA de las empresas en el primer trimestre de 2026, frente al 31% de un año antes. El registro público de servidores MCP pasó de unos 1.200 servidores en el primer trimestre de 2025 a más de 9.400 en abril de 2026. En diciembre de 2025, Anthropic donó el protocolo a la nueva Agentic AI Foundation en el marco de la Fundación Linux, con OpenAI, Google, Microsoft y AWS a bordo. Ese fue el momento en que MCP dejó de ser una cosa de Anthropic y empezó a ser la capa de integración.
Y por si fuera poco, Gartner predice ahora que el 40% de las aplicaciones empresariales se comercializarán con agentes de IA para tareas específicas a finales de 2026, frente a menos del 5% actual.
Lea estas cifras juntas. La tubería a través de la cual se utiliza su producto se está reconstruyendo bajo sus pies, y una enorme parte del nuevo tráfico nunca verá un botón.
La mayoría de los productos siguen siendo UI-first under the hood
Me doy cuenta de esto cada vez que veo una nueva herramienta SaaS.
La interfaz de usuario es preciosa. La API es una ocurrencia tardía. Hay una página /docs con doce puntos finales de los cuarenta que utiliza la interfaz de usuario. No existe un servidor MCP. La CLI, si existe, es un proyecto paralelo de la comunidad que se abandona cada seis meses. El flujo de onboarding asume que usted es un humano haciendo clic a través de un asistente, porque el producto fue concebido como algo en lo que los humanos se registrarían.
Ese modelo funcionó durante quince años. Está empezando a fallar en 2026, y va a fallar con más fuerza cada trimestre a partir de ahora.
Esto es lo que sigo viendo que ocurre. Un equipo adopta una nueva herramienta. Utilizan la interfaz de usuario durante las primeras semanas. Entonces alguien del equipo enchufa Claude o ChatGPT en su flujo de trabajo. De repente, la pregunta no es "¿cómo abro la interfaz de usuario y actualizo esto?. La pregunta es "¿puede mi agente hacer esto por mí?. Si la respuesta es negativa, el uso de esa herramienta empieza a decaer. No porque la IU haya empeorado. Porque el punto de entrada se ha desplazado.
El tráfico de bots dirigido a las API saltó al 27% de todo el tráfico de bots en 2025, según el mismo informe de Imperva. Esa cifra aumentará cada año. Todo flujo de trabajo agéntico es una pila de llamadas a API, y todo producto que no exponga esas llamadas se va a quedar fuera del flujo de trabajo.
Lo que realmente significa "funciona sin su interfaz de usuario
Esto es algo más que "tener una API". La mayoría de los productos tienen una API. La mayoría de las API también son malas.
El producto que funciona sin su interfaz de usuario pasa un listón mucho más difícil. Creo que hay aproximadamente cuatro pruebas.
- Todas las acciones significativas de la interfaz de usuario son invocables desde la API. Nada de "configure esto a través del panel de control". Sin casillas de "esto sólo puede configurarlo un administrador en la IU". Si un humano puede hacerlo, un agente puede hacerlo.
- Hay un servidor MCP, y es de origen. No un proyecto de la comunidad. No una envoltura que alguien construyó el fin de semana pasado. Un servidor MCP real, propio y versionado que expone la misma superficie que la API de un modo que los agentes pueden razonar.
- Hay una CLI con paridad. Porque las CLI son la forma en que los ingenieros scriptan las cosas, y porque las CLI son también la forma en que muchos marcos de trabajo agénticos acaban llamando a las herramientas cuando MCP no está disponible.
- La autenticación funciona para los no humanos. Cuentas de servicio, tokens de alcance, flujos OAuth que un agente puede completar en nombre de un usuario. No "haga clic en este enlace mágico de su correo electrónico", porque el agente no tiene un cliente de correo electrónico.
Si su producto falla en alguno de estos puntos, ha construido una interfaz de usuario con un backend, no un producto. La diferencia importará cada vez más.
Tuvimos que hacer esta llamada en Rasepi, y no fue sutil
Seré honesto, esta es la razón por la que construimos Rasepi como lo hicimos, y fue una decisión arquitectónica real, no una línea de marketing.
Cuando esbozamos el producto a principios de 2025, lo obvio era construir otra interfaz de usuario con forma de Confluence. Un bonito editor, un bonito lector, una barra de búsqueda en la parte superior. Casi lo hicimos. Lo que nos detuvo fue ver cómo los equipos ya utilizaban Claude, GPT y agentes similares para leer y escribir sus documentos internos sin abrir nunca la herramienta existente. La interfaz de usuario no era el cuello de botella. Lo era la falta de superficie programática.
Así que Rasepi fue diseñado API-first, con la UI construida on top de la misma superficie que cualquier agente o script puede golpear. El servidor MCP, la API REST y la CLI comparten la misma autenticación, el mismo modelo de permisos y la misma capa de contenido. La interfaz de usuario es sólo uno de los consumidores. Probamos el producto escribiendo scripts contra él, no haciendo clic a través de él.
Eso tiene consecuencias para lo que construimos, de formas buenas y ligeramente dolorosas. Cada nueva característica tiene que salir con la paridad de la API. No podemos limitarnos a "añadir un botón" y darlo por hecho. La ventaja es que cuando un cliente conecta Claude a su instancia de Rasepi, todo funciona. No hay "ah, esa característica es sólo UI, lo siento".
Lo que esto significa si está construyendo algo ahora mismo
Unas pocas cosas, si tuviera que resumir la salida práctica.
Deje de medir el uso únicamente por la actividad de la interfaz de usuario. Mida su tráfico de API y MCP por separado, y haga un seguimiento de ellos como métricas de crecimiento, no como ruido de operaciones. Si el uso de su panel de control es plano pero el tráfico de su API se duplica, eso no es un problema. Eso es el futuro llegando a tiempo.
Construya un primer servidor MCP antes de que la comunidad construya uno malo para usted. Los 9.400 servidores del registro público no son todos buenos. La mayoría tienen fugas, están implementados a medias y sin mantenimiento, y sus usuarios juzgarán su producto por la calidad de esa integración, la haya escrito usted o no.
Y deje de tratar la API como la versión barata de su producto. Dentro de un año, para muchos clientes, es su producto.
Las empresas que ganen en 2026 serán aquellas cuyos usuarios puedan hacerlo todo a través de la API, la CLI, el servidor MCP o la interfaz de usuario, y nunca tengan la sensación de haber elegido la puerta equivocada.
La interfaz de usuario no va a desaparecer. Los humanos seguirán utilizándola para las partes del trabajo que se benefician de una superficie visual, y eso está bien. Pero ya no es la puerta principal. Es una puerta entre varias, y las otras puertas están creciendo más rápido que la delantera.
Si su producto no puede mantenerse en pie cuando la interfaz de usuario está cerrada, ése es el fallo que hay que solucionar primero.