Poder ser headless: la nueva feature obligatoria del software

Hubo dos anuncios este año que, puestos uno al lado del otro, me quedaron dando vueltas.

El primero pasó casi sin ruido. Anthropic habilitó que los artifacts de Claude Code consuman conectores MCP de forma interactiva: una mini-app generada dentro de un chat puede, mientras la usás, llamar a servidores MCP y tocar datos reales —con tu identidad y sin exponer nada al mundo—. No es un artifact que muestra un resultado congelado; es una interfaz descartable que, en vivo, tiene manos para operar sobre tus sistemas. Una nota de release menor, de esas que juntan unos pocos likes. Nadie escribió un thread apocalíptico.

El segundo fue difícil de ignorar. En abril, en su TDX, Salesforce presentó Headless 360: más de 60 herramientas MCP, más API, más CLI, todo sobre el mismo core. Parker Harris, cofundador, lo puso en una pregunta que en Salesforce suena a herejía: “¿Por qué deberías volver a loguearte en Salesforce?”. The Register lo tituló como la empresa despidiéndose de su propia UI. El lema: build once, render everywhere.

Uno es un feature flag; el otro, una de las plataformas empresariales más grandes del planeta reordenando su tesis de producto. Y sin embargo apuntan al mismo lado —hacia lo headless—. Cuando el más chico y el más grande empujan en la misma dirección, me cuesta leerlo como anécdota.

La idea, en una frase

No creo que estemos ante la muerte de la UI. Me parece que estamos ante “poder ser headless” convirtiéndose en algo que se le va a pedir a casi todo software: que todo lo que se hace desde la pantalla se pueda hacer también por API, MCP o CLI.

Como pasó con “ser responsive” alrededor de 2012, o con “tener API pública” unos años después. En su momento cada una era un diferenciador; después dejó de ser un plus y pasó a ser un piso. Si tu producto no era responsive en 2016, no estaba incompleto: estaba roto.

El error, me parece, es leerlo en binario. No es UI o no-UI. Es que la interfaz del vendor deja de ser el punto de entrada y pasa a ser un consumidor más: la API, un servidor MCP, la CLI, un agente que actúa en tu nombre, una interfaz generada en el momento para una tarea puntual. El que no exponga bien esa superficie no va a tener una UI menos linda; probablemente quede afuera de conversaciones que cada vez más arranca un agente preguntando “¿con esto puedo operar por API o me obligás a hacer clicks?”.

De dónde viene “headless” (y qué cambió)

Conviene separar dos olas, porque se llaman igual y no son lo mismo.

La primera es el headless clásico, el de la era CMS y commerce: desacoplar el frontend del backend para que la capa de presentación la reemplace otro humano —vos, tu equipo de front— con un Next.js, una app móvil, lo que sea. El consumidor seguía siendo un desarrollador construyendo una interfaz para personas. Era una decisión de arquitectura.

La segunda es la que estamos viviendo, y el corte se siente más profundo. No le saca la cabeza al sistema para que la ponga otro humano, sino porque aparece un nuevo tipo de usuario: el agente. Un LLM con herramientas que no quiere tu formulario, quiere tus verbos. No navega, invoca. No necesita que le expliques dónde está el botón de “crear factura”; necesita una tool crear_factura con un schema claro y permisos bien puestos.

Por eso MCP importa tanto. Cuando Anthropic donó el protocolo a la Linux Foundation, a fines de 2025, y empezó a circular la analogía del “USB-C para IA”, lo que se estaba estandarizando era el enchufe por el cual un agente se conecta a tu software sin pasar por tu pantalla.

Por qué me parece una tendencia estructural, no una moda

Con un solo caso no alcanza, así que no me quedo solo con Salesforce. Lo que me hace pensar que hay algo estructural es cuánta gente llegó al mismo lugar por caminos distintos.

Geoffrey Litt, desde Ink & Switch, lo viene diciendo desde 2023: cuando los LLM sacan el cuello de botella de programar, la gente deja de aceptar el software enlatado y arma sus propias herramientas. Su observación más filosa —que rescató Simon Willison— es que el chat es “un modo de interacción limitado”: no querés escribir un párrafo para mover un slider. Si la interfaz correcta depende de la tarea, no puede vivir hardcodeada en el vendor.

Netlify le puso nombre a la contracara: Agent Experience (AX), con una formulación bien directa: “tus APIs son la interfaz principal para los agentes”. Yext lo lleva al terreno comercial: “la API es ahora la UI”, y el usuario elige la interfaz, no el vendor. Team8 publicó “Headless Was Only the Beginning”, con una lectura que debería incomodar a los grandes: cuando los agentes son usuarios de primera clase, la vieja ventaja de la UI pegajosa y el “ya lo tenemos instalado” pesa menos. Matt Webb lo dice más poético: en el mundo de la IA personal, la UI se vuelve “sacrificial”, se genera y se tira. Y del lado de la generative UI se cierra el círculo: InfoWorld tituló “el agente de IA es el front end”, a16z escribió sobre cómo la IA generativa rehace el diseño de UI/UX, NN/g le puso marco de usabilidad, y Google ya está estandarizando el cómo con A2UI + MCP Apps.

La inversión del 95/5

Hay una relación que me parece una buena forma de medir el cambio. Durante veinte años, el software se construyó en una proporción tácita de 95/5: el 95% del esfuerzo iba a la UI para humanos y un 5%, si llegaba, a la API. La API era el patio trasero.

Esa proporción se está difuminando, y en varios productos se está dando vuelta. La superficie programática —API, MCP, CLI, tools bien descriptas— pasa a ser la entrada principal, porque es la que consumen los agentes. La UI del vendor no desaparece, pero baja de rango: de ser la forma de usar el producto a ser una de las formas.

Dónde se rompe la idea

Si terminara acá estaría contando solo la mitad. “Poder ser headless” no es lo mismo que “todo headless”. La capacidad es la superficie; que todo se consuma sin UI me parece una fantasía que choca con problemas reales.

El primero es el no-determinismo. Una UI generada al vuelo es distinta cada vez, y una interfaz que cambia sola erosiona el modelo mental del usuario: la memoria muscular, el “sé que el botón está arriba a la derecha”. Hay críticas bien fundadas a esto —el problema del “AI slop” frente a la UI restringida, e incluso un paper titulado “Against Generative UI”—. No son ludistas: señalan que la generación libre produce interfaces mediocres, inconsistentes y difíciles de auditar.

El segundo es gobernanza, y es el que más me preocupa. Cuando abrís tu sistema para que agentes lo operen, multiplicás la superficie de ataque. Los números que circularon con Headless 360 son elocuentes: apenas un 13% de los líderes de IT se sienten preparados, y un 74% ve a los agentes como un vector de seguridad. Un agente con permisos amplios y un prompt mal cerrado es un incidente esperando pasar. La UI, con toda su fricción, también era una barrera. Sacarla sin reponer esa gobernanza en la capa de tools es cambiar seguridad por velocidad.

Por eso no leo esto como “tiremos la UI”. La UI del vendor deja de ser el único camino, pero sigue siendo el camino por defecto para las tareas de alto riesgo o alta frecuencia. La misma Anthropic diseñó ese consumo interactivo de MCP para que corra con la identidad del que usa el artifact y sin compartir nada públicamente, precisamente porque una UI generada con manos para operar, pero sin barandas, no es una feature: es un pasivo.

Qué puede significar para comprar y para construir

Si comprás software, quizás valga sumar una pregunta al checklist: “¿Todo lo que puedo hacer desde la UI, lo puedo hacer también por API, MCP o CLI?”. Si la respuesta es no, puede que estés comprando una isla, y las islas envejecen mal. La paridad entre la interfaz humana y la superficie programática se parece bastante al nuevo “¿es responsive?”.

Si construís software, la implicancia es más incómoda pero también más liberadora. Vale la pena dejar de pensar la API como el patio trasero: diseñar las capacidades primero —verbos claros, schemas explícitos, permisos granulares, buenos mensajes de error— y tratar la propia UI como el primer consumidor de esa superficie. Si tu pantalla se construye sobre las mismas tools que le vas a exponer a un agente, ganás dos veces: tenés una UI y tenés un producto que ya puede ser headless el día que un cliente lo pida.

La cabeza no se le está cayendo al software. Lo que se le está cayendo, me parece, es la exclusividad de la cabeza. Durante veinte años el vendor decidía cómo mirabas su producto; ese poder se está redistribuyendo hacia el usuario y sus agentes. Poder ser headless no es el fin de la interfaz. Es, tal vez, el fin de que la interfaz sea solo tuya.