Para qué sirven las interfaces si tenemos LLM

De la línea de comandos a la interfaz — y de vuelta otra vez

Al principio de la era informática, la gente tenía que aprender a hablar el lenguaje de la máquina: interruptores, tarjetas perforadas, comandos en la terminal. Un error en un solo carácter y no pasaba nada. Cuando las computadoras se convirtieron en un producto masivo, este enfoque colapsó. No se puede exigir a cada usuario que memorice decenas de comandos y sus parámetros. Llegaron las ventanas, los menús, los iconos y el ratón. Se podía arrastrar un archivo a la papelera en lugar de escribir un comando de borrado. Entre la persona y el programa se formó una capa: la interfaz.

Ahora esa lógica se invierte. Los LLM permiten que las personas vuelvan a hablarle a la computadora en su propio idioma, pero ahora es la máquina la que entiende el lenguaje natural, no la persona la que aprende la sintaxis del sistema. Toma como ejemplo la analítica corporativa: en lugar de buscar una sección, elegir un informe y configurar filtros y condiciones, simplemente dices: «Muéstrame los clientes que antes compraban con regularidad pero dejaron de hacerlo en los últimos tres meses».

El sistema analiza la solicitud por sí mismo, la compara con los datos disponibles, construye una consulta estructurada y entrega el resultado. O con los billetes de avión: en lugar de elegir ciudades, fechas, filtros y configuraciones de vuelo de regreso, simplemente dices «Quiero encontrar vuelos a Pekín la próxima semana sin escalas, idealmente por menos de 200 euros, de vuelta el domingo por la noche».

La forma de preguntar y la forma de recibir la respuesta son dos

tareas distintas

Cuando se habla de una interfaz con LLM, se piensa en un chat: texto → respuesta en texto. En realidad son dos parámetros independientes. La solicitud puede pronunciarse por voz: las frases largas con varias condiciones se dicen más rápido de lo que se escriben en un teléfono. Una frase como «muéstrame los proyectos de mi área donde el plazo de entrega aumentó el último mes pero el alcance no cambió» puede decirse prácticamente sin pausas.

Pero del hecho de que hayas preguntado por voz no se deduce que la respuesta deba ser también por voz. Si preguntas cómo han cambiado los gastos por categoría en los últimos seis meses, por voz escucharás un resumen breve: «En seis meses se gastó un millón de rublos, y las principales categorías fueron alquiler, infraestructura y contratistas». Mientras tanto, en la pantalla aparecerán un gráfico y una tabla detallada con el desglose mensual.

Lo mismo ocurre con una consulta escrita: escribes algo y recibes un mapa, un gráfico, tarjetas de productos, un formulario de confirmación o una tabla interactiva. Elegir la forma de ingresar la solicitud y elegir la forma de mostrar el resultado son dos tareas distintas.

Hoy, la entrada y la salida están ligadas a un único dispositivo: le preguntas al teléfono y la respuesta aparece en el teléfono. Esto es una limitación de los productos actuales, no una restricción técnica. Los dispositivos podrían conectarse a través de una sesión de usuario compartida: un altavoz inteligente como dispositivo de entrada por voz con una respuesta de audio breve, un teléfono que muestra una interfaz interactiva, una laptop como dispositivo de trabajo principal, una pantalla de televisión en la sala de reuniones como pantalla grande compartida.

La elección del dispositivo se convierte en parte del enrutamiento de la respuesta. Los datos financieros no deberían mostrarse automáticamente en el televisor de la sala de reuniones, y un gráfico con 20 indicadores no se puede leer a través de un altavoz.

Cuatro formas de implementarlo

N.º 1. UI generativa controlada

El producto define un conjunto de componentes: ExpenseChart, ComparisonTable, HotelCards, Map, Confirmation. El modelo no dibuja la pantalla, sino que elige el componente adecuado, obtiene los datos y devuelve un JSON estructurado:

``` { "component": "ExpenseBreakdown", "period": "6m", "data": [...], "groupBy": "category" } ```

El diseñador y el desarrollador mantienen el control total sobre la apariencia, el comportamiento, la accesibilidad y los estados de error. El modelo solo elige la representación y le pasa los datos. Este enfoque está implementado en CopilotKit.

N.º 2. Descripción declarativa a partir de bloques básicos

El modelo no recibe pantallas terminadas, sino elementos básicos: contenedor, texto, métrica, tabla, tarjeta, gráfico, botón, formulario. Devuelve una descripción declarativa de la interfaz que el cliente ensambla con su propio kit de UI, conservando el sistema de diseño en todas partes: web, aplicación móvil, otros clientes. Una misma respuesta puede representarse en entornos distintos. Este es el enfoque que desarrolla A2UI de Google.

N.º 3. MCP Apps con interfaz lista

La herramienta devuelve una interfaz interactiva que el cliente muestra dentro de un iframe en sandbox. Se pueden usar tecnologías web estándar: HTML, CSS, JavaScript, crear formularios, gráficos, mapas, escenarios de varios pasos. Esto lo admiten distintos clientes MCP y aplicaciones dentro de ChatGPT. Aquí el proveedor de la herramienta controla más la apariencia que el cliente.

N.º 4. Generación completa de HTML/CSS/JavaScript

El modelo genera el código por completo al vuelo. Ofrece máxima libertad, pero surgen dudas sobre calidad, seguridad, estabilidad y coherencia visual. Puede ser práctico para un prototipo o una tarea puntual, pero convertirlo en la base de un sistema corporativo crítico es arriesgado.

Cómo cambiará el desarrollo

Con el enfoque clásico, rápidamente aparecen: página principal, catálogo de informes, páginas de detalle, constructor de filtros, vistas guardadas, pantalla de comparación de períodos, exportación, configuraciones. Cada nuevo escenario incrementa la cantidad de estados del producto que hay que diseñar, implementar, probar y adaptar a distintos tamaños de pantalla.

Con el modelo basado en LLM, esta lógica cambia. En lugar de prever todas las combinaciones posibles de componentes en pantallas separadas, el desarrollador crea un conjunto de elementos básicos y reglas de interacción entre ellos. El modelo ensambla por sí mismo la combinación necesaria para cada solicitud concreta del usuario. Hay menos pantallas, más lógica dentro del sistema, y resulta más cómodo trabajar con él.