La interfaz de usuario en la era agéntica

Si cada usuario puede tener su propia interfaz, ¿qué sentido tiene el software estándar?

¿Y si construir la interfaz dejara de ser el problema?

Durante décadas, la mayoría de aplicaciones han funcionado de forma parecida: un equipo diseña las pantallas y los usuarios aprenden a utilizarlas. No es necesariamente una mala solución. Diseñar una experiencia diferente para cada empresa, departamento o persona resultaba demasiado caro, así que hemos construido productos comunes y añadido las opciones de configuración que podíamos permitirnos.

Los agentes de IA empiezan a cuestionar ese equilibrio. Pueden utilizar herramientas, consultar datos, ejecutar acciones y escribir el código de una interfaz a partir de una descripción. Si cada vez resulta más barato construir y modificar pantallas, ¿seguirá teniendo sentido que todos trabajemos con las mismas?

La respuesta no depende únicamente de cuánto cueste generarlas. Que construir una interfaz sea barato no significa que utilizarla, entenderla, compartirla con otros o mantenerla también lo sea. Y sospecho que buena parte del futuro de la UI se decidirá precisamente en esa diferencia.

Dos preguntas que solemos mezclar

Cuando imaginamos el software de los próximos años, solemos pensar en un asistente universal, como ChatGPT o Claude, que conoce nuestro contexto y opera las aplicaciones por nosotros. También podemos imaginar algo más continuista: aplicaciones especializadas que mantienen su interfaz e incorporan agentes capaces de trabajar dentro de ella. Son dos modelos distintos sobre dónde se produce la interacción, no necesariamente sobre cómo será la interfaz.

El asistente universal tiene una ventaja evidente: nuestros procesos no respetan los límites entre aplicaciones. Podemos necesitar consultar una venta, comprobar existencias y preparar una compra, todo en sistemas diferentes. Un agente capaz de coordinar esas acciones nos ahorraría bastante trabajo. Para quienes desarrollamos software aparece una tensión comercial: abrir las capacidades de nuestras aplicaciones a agentes externos puede hacerlas mucho más útiles, pero también supone ceder parte del control sobre la experiencia y la relación con el cliente. Habrá incentivos tanto para facilitar esa integración como para resistirse a ella.

Además, conversar no tiene por qué significar escribir en un chat. La voz puede ser una forma magnífica de consultar información o comunicar incidencias mientras trabajamos con las manos ocupadas. Pero si necesito reorganizar la planificación semanal de una fábrica, seguramente preferiré ver un Gantt, identificar conflictos y mover operaciones visualmente, quizá mientras le pido al agente que calcule alternativas.

Por eso no creo que la cuestión sea elegir entre agentes e interfaces. Pueden convivir. La pregunta sobre la que quiero detenerme es otra: si seguimos necesitando pantallas, ¿quién las construye y cuánto tiempo deberían durar?

Tres formas de construir una interfaz

1. Diseñarla para muchos usuarios

Es el modelo tradicional. Un equipo investiga necesidades, diseña una experiencia común y mejora sus pantallas a medida que aprende de su uso. Tiene el inconveniente de que no todo el mundo trabaja igual, pero ofrece algo muy valioso: una interfaz familiar, optimizada y compartida. Sabemos dónde están las cosas, podemos formar a nuevos compañeros y el soporte puede ayudarnos sin descubrir una aplicación distinta en cada conversación.

Una buena interfaz diseñada no pierde su valor porque aparezcan los agentes. Si repetimos una operación cincuenta veces al día, probablemente nos interese más la rapidez y la previsibilidad que la capacidad de improvisar una pantalla nueva.

2. Generarla cuando la necesitamos

Imaginemos que pedimos a un agente comparar la evolución de los retrasos de varios proveedores. En lugar de devolver un párrafo o enviarnos a una pantalla preexistente, podría generar una tabla con filtros, un gráfico y los controles necesarios para explorar los datos. Terminamos el análisis y esa interfaz desaparece. OpenAI ya está explorando este enfoque con Intelligent UI, que permite generar experiencias interactivas directamente en las respuestas de ChatGPT.

Es una posibilidad muy potente para preguntas excepcionales, análisis exploratorios o necesidades que nadie había previsto cuando se diseñó el producto. Pero llevada al extremo tiene una contradicción: si cada vez que pregunto algo el agente me genera una aplicación distinta, quizá hayamos eliminado el coste de aprender una interfaz a cambio de tener que aprender una nueva cada vez.

No quiero que mi panel de indicadores cambie de distribución cada mañana. Quiero reconocerlo de un vistazo. Y eso nos lleva al siguiente modelo.

3. Generarla, conservarla y hacerla evolucionar

Una interfaz puede nacer de una petición concreta y convertirse después en una herramienta habitual. Un responsable de compras podría conservar un panel adaptado a sus proveedores; un jefe de turno, otro pensado para sus incidencias y las operaciones en curso. La aplicación seguiría proporcionando las mismas capacidades y reglas de negocio, pero no obligaría a todos a trabajar con las mismas pantallas.

La personalización profunda no es nueva. Lo novedoso sería reducir lo suficiente el coste de crearla y mantenerla para que dejara de reservarse a grandes clientes con presupuestos de desarrollo a medida. Eso abre dos posibilidades bastante diferentes: que un equipo de implantación construya interfaces con ayuda de agentes, o que los propios usuarios puedan crearlas y modificarlas. La primera parece mucho más fácil de introducir a corto plazo; la segunda exige resolver problemas adicionales de seguridad, soporte y diseño.

Porque no todo lo que un usuario pide es necesariamente lo que necesita. Diseñar una buena interfaz implica descubrir el proceso real, identificar casos que nadie había mencionado y tomar decisiones que quizá el usuario no sepa formular. Un agente puede ayudar con ese trabajo, pero generar lo pedido no equivale a haber diseñado bien la solución.

También existe un coste colectivo. Si cada operario ve una aplicación diferente, ¿cómo formamos al siguiente empleado? ¿Cómo le dice un jefe de turno a otro dónde encontrar un dato? Una biblioteca de componentes puede mantener la estética, pero no garantiza un vocabulario compartido. Por eso imagino muchas personalizaciones a nivel de empresa, departamento o rol, y bastante menos libertad individual de la que sugiere la idea de «una interfaz para cada persona».

El verdadero reto: mantener todo lo que generamos

Aquí aparece una objeción evidente. La historia del software empresarial está llena de personalizaciones que terminaron haciendo casi imposible actualizar los productos. Grandes implantaciones de ERP han acumulado extensiones, dependencias y cambios específicos que nadie se atrevía a tocar. ¿No estaríamos repitiendo el problema, esta vez a mayor velocidad?

La respuesta fácil sería decir que una buena arquitectura lo evita, pero eso no sería ninguna novedad. SAP lleva años impulsando su enfoque Clean Core: mantener el núcleo estándar y extenderlo mediante contratos e interfaces estables. Las plataformas low-code también llevan mucho tiempo ofreciendo componentes y mecanismos de personalización. Separar la lógica de negocio de su presentación no es algo que hayamos descubierto gracias a la IA; es ingeniería de software bien conocida.

Lo que puede cambiar frente al low-code tradicional es cómo construimos y mantenemos esas personalizaciones. En lugar de depender de la configuración de un editor específico, podemos hacer que los agentes generen código convencional, que guardamos en Git, revisamos y probamos con las mismas herramientas que utilizamos para desarrollar cualquier otra aplicación. No necesitamos aprender un entorno visual diferente para cada cambio, y el código sigue siendo nuestro aunque mañana cambiemos de agente.

Pero la apuesta realmente diferente está en otro sitio: ¿por qué asumir que los agentes solo servirán para crear interfaces y no para mantenerlas? Si una personalización se construye sobre un SDK versionado y APIs públicas, cuando el producto evolucione otros agentes podrían identificar los cambios que la afectan, adaptar el código y ejecutar pruebas antes de desplegar una nueva versión.

Una buena arquitectura intentaría mantener la compatibilidad hacia atrás y limitar las migraciones a las interfaces realmente afectadas. Los agentes podrían encargarse de buena parte de ese trabajo, aunque siempre habría un coste de ejecución y validación.

También tendría que existir una responsabilidad clara. Si ofrecemos interfaces personalizadas como parte de nuestro producto, debemos garantizar su mantenimiento dentro de unos límites definidos, y ese servicio tiene un coste que debemos contemplar. La automatización puede reducirlo mucho, pero no hacerlo desaparecer.

Más difícil todavía es comprobar que una migración preserva el comportamiento correcto. Una pantalla puede compilar, pasar pruebas visuales y continuar mostrando datos, pero dejar de representar correctamente las reglas del negocio.

Imaginemos que un agente construye una pantalla personalizada para mostrar las órdenes de fabricación con riesgo de retraso. Como la API no ofrece exactamente la información que necesita, decide calcular ese riesgo combinando fechas de entrega y operaciones pendientes.

Meses después actualizamos la lógica de planificación para tener en cuenta también la disponibilidad de materiales. Las pantallas estándar utilizan el nuevo cálculo, pero la personalizada sigue aplicando el suyo. Ningún contrato se ha roto, todo compila y, sin embargo, ahora tenemos dos versiones distintas de qué órdenes están en riesgo.

El problema no es exclusivo de la IA. Un desarrollador podría haber cometido exactamente el mismo error, pero si empezamos a generar muchas más interfaces, también podemos multiplicar este tipo de inconsistencias.

Precisamente por eso es fundamental que las interfaces no reimplementen reglas de negocio. Si el SDK o la API no ofrecen una capacidad necesaria, lo correcto sería ampliar ese contrato en lugar de introducir lógica paralela. Y para comprobar que se respeta esa separación necesitaremos pruebas que validen el comportamiento del sistema, no solo que el código generado funciona.

No sabemos todavía hasta qué punto ese mantenimiento podrá automatizarse de manera fiable y rentable a gran escala. Pero tampoco parece razonable calcular su coste futuro suponiendo que cada personalización seguirá requiriendo las mismas horas humanas que hoy.

Ahí está, para mí, la hipótesis interesante: la IA podría cambiar no solo el coste de producir software personalizado, sino el de conservarlo a lo largo del tiempo.

De una pantalla puntual a una funcionalidad del producto

Hay una consecuencia que me interesa especialmente. Quizá no tengamos que decidir de antemano si una interfaz será temporal, personalizada o estándar.

Una persona podría pedir una visualización para resolver una duda puntual y descartarla después. Si le resulta útil cada semana, podría conservarla. Si todo su equipo necesita lo mismo, podrían compartirla. Y si descubrimos que responde a una necesidad común a muchos clientes, quizá merezca convertirse en una funcionalidad del producto, diseñada y mantenida centralmente.

Ese paso no debería ser automático. Que varias empresas construyan algo parecido no demuestra que sea la mejor solución, y detectar esas coincidencias tampoco es trivial. Necesitaríamos analizar patrones de uso, recoger feedback o estudiar las necesidades que motivaron esas personalizaciones, sin asumir que podemos inspeccionar libremente el código o los datos de nuestros clientes.

Pero sí ofrecería otra manera de descubrir oportunidades de producto, partiendo de problemas que la gente ha intentado resolver de verdad.

Por supuesto, una pantalla muy utilizada por una sola fábrica no tiene por qué acabar en el producto estándar. Podría seguir siendo una personalización perfectamente válida, siempre que mantenerla resulte razonable.

Lo que queremos explorar en Bold

Esta discusión nos toca de cerca. En Bold desarrollamos software de operaciones industriales, y vemos constantemente que dos fábricas con procesos parecidos necesitan trabajar de formas muy distintas. Hasta ahora hemos tenido que equilibrar un producto común y mantenible con adaptaciones cuyo coste no siempre se justifica para una pyme.

Lo primero que nos interesa explorar no es que cada operario pueda generar cualquier pantalla, sino abaratar las personalizaciones durante la implantación. Que nuestro equipo pueda construir, con ayuda de agentes, experiencias adaptadas a cada fábrica sin modificar el núcleo de Bold. Más adelante tendría sentido permitir que los propios clientes soliciten cambios, probablemente empezando por un alcance limitado y con mecanismos de aprobación.

Un primer experimento podría ser crear para un jefe de turno una pantalla que reúna órdenes urgentes, disponibilidad de máquinas e incidencias, sin incorporar esa combinación al producto estándar. Nos permitiría medir si mejora su trabajo y, algo igual de importante, cuánto cuesta mantenerla tras varias actualizaciones.

Para las interfaces persistentes, nuestra idea es que vivan dentro de Bold y utilicen componentes y capacidades de la propia plataforma. Eso no impide que un asistente externo pueda operar Bold a través de APIs o herramientas como MCP, e incluso mostrar sus propias interfaces temporales. Son superficies diferentes y no tienen por qué compartir el mismo SDK visual.

Seguimos teniendo preguntas abiertas: cómo validar los cambios funcionales, qué nivel de personalización podremos soportar y cuál será su coste real de mantenimiento. No tenemos una respuesta demostrada para todo ello ni queremos presentar esta arquitectura como un problema ya resuelto. Precisamente por eso merece la pena investigarla.

¿Qué interfaces merece la pena diseñar y mantener?

Después de darle todas estas vueltas, creo que la respuesta depende principalmente de tres cosas: la frecuencia con la que utilizamos una interfaz, cuántas personas necesitan algo parecido y qué tipo de tarea queremos resolver.

Para una consulta excepcional o un análisis exploratorio, probablemente tenga sentido generar una interfaz temporal y descartarla después. Si es algo que una empresa o un departamento utiliza habitualmente, una personalización persistente puede aportar mucho valor. Y si esa necesidad es común a numerosos clientes, seguramente merezca convertirse en una funcionalidad diseñada y mantenida como parte del producto estándar.

No son categorías rígidas, pero me parecen una buena forma de decidir dónde invertir el esfuerzo de diseño y mantenimiento.

La IA podría hacer económicamente viables combinaciones que hasta ahora resultaban demasiado caras. Pero cuanto más fácil sea construir y modificar software, más valor tendrán los contratos claros, el versionado, las pruebas y una buena separación de responsabilidades. La IA no sustituye a la buena ingeniería; cambia cuánto podemos construir y mantener cuando la hacemos bien.

Y si conseguimos eso, quizá podamos personalizar mucho más sin renunciar a lo que hace útil una buena aplicación: que sea comprensible, predecible y coherente para quienes trabajan con ella.

Porque la personalización total no tiene por qué significar inconsistencia total.