Generative UI: cuando la IA no solo responde, sino que construye la interfaz

Durante años, la interacción con un asistente de IA ha seguido el mismo patrón: escribes una pregunta, recibes texto. Útil, sí. Pero limitado. ¿Qué pasa cuando lo que necesitas no es una frase, sino una tabla comparativa, una gráfica de tendencias o un panel de métricas? Ahí es donde entra Generative UI. Este paradigma va más allá del texto clásico y convierte al modelo de lenguaje en un verdadero orquestador de interfaces. En el equipo de desarrollo de Sngular, hemos analizado esta tecnología para transformar la experiencia de usuario en tiempo real.

¿Qué es el paradigma Generative UI?

Generative UI es el patrón de diseño en el que un modelo de lenguaje no solo produce texto. Además, decide qué componentes de interfaz mostrar y con qué datos trabajar. En lugar de responder "los ingresos de enero fueron 12.400 €", el modelo renderiza directamente una gráfica de barras con los doce meses del año.

Por consiguiente, el modelo actúa como una capa de orquestación. Interpreta la intención del usuario, selecciona la representación visual más adecuada e inyecta los datos reales en el componente correcto. De este modo, la conversación deja de ser un intercambio de texto plano para convertirse en una experiencia interactiva y adaptativa.

Dos estrategias para implementar Generative UI

Hemos construido una aplicación de demostración que explora dos aproximaciones al problema. Cada una cuenta con sus propias ventajas y casos de uso específicos.

Estrategia 1: Componentes predefinidos (tool calling)

El modelo elige entre un catálogo cerrado de herramientas: displayTable, displayBarChart, displayLineChart, displayPieChart y displayStats . Una vez seleccionada la herramienta, la aplicación inyecta los datos reales y renderiza el componente de React correspondiente.

¿Por qué funciona bien? El modelo nunca serializa el dataset completo. Solo declara qué quiere mostrar y qué campos necesita. Los datos reales se inyectan en el servidor, específicamente en el método execute de cada herramienta. Esto tiene una consecuencia directa en el coste. En efecto, no se pagan tokens de salida por re-serializar información que ya existe en el backend.

JavaScript

// El modelo elige una tool y los campos

export const displayBarChartTool = createTool({

  description: 'Muestra una gráfica de barras con los datos de ventas',

  inputSchema: z.object({

    xField: z.string().describe('Campo para el eje X (p. ej., month)'),

    yField: z.string().describe('Campo para el eje Y (p. ej., revenue)'),

    title: z.string().describe('Título de la gráfica'),

  }),

  execute: async ({ xField, yField, title }) => {

    // Los datos reales se inyectan aquí, no los genera el modelo

    return expandVizSpec({ type: 'bar', xField, yField, title });

  },

});

🎥 Demo en vídeo — API externa + componentes predefinidos

Ver en YouTube

Estrategia 2: Generación libre de código JSX

En este caso, el modelo escribe el componente React completo. El código generado se compila y renderiza en un sandbox usando react-live. Los componentes de Recharts y los hooks de React están disponibles en el scope sin necesidad de imports.

JavaScript

// Ejemplo de salida del modelo en modo libre

function Visualization({ data }) {

  return (

    <ResponsiveContainer width="100%" height={300}>

      <AreaChart data={data}>

        <Area type="monotone" dataKey="profit" stroke="#6366f1" fill="#6366f120" />

        <XAxis dataKey="month" />

        <YAxis />

        <Tooltip />

      </AreaChart>

    </ResponsiveContainer>

  );

}

Un error boundary contiene los fallos de código inválido. Gracias a esto, una visualización rota no tirará la página entera. En la práctica, esta estrategia brilla cuando el usuario pide algo fuera del catálogo. Por ejemplo, un gráfico radar, un dashboard compuesto o una comparativa de área apilada.

🎥 Demo en vídeo — API externa + generación libre de componentes

Ver en YouTube

Dónde se ejecuta el modelo: servidor vs. navegador

La aplicación añade un segundo eje de experimentación. El modelo puede correr en la nube o directamente en el navegador del usuario.

API externa (servidor)

Se usan Gemini y Claude (Anthropic) a través del AI SDK de Vercel. La ventaja es directa: acceso a modelos grandes que razonan mejor sobre la intención del usuario. Además, siguen instrucciones complejas con fiabilidad y generan código React válido con consistencia suficiente para entornos de producción.

Modelo — Externo vs. Local

IA local en el navegador con la Prompt API de Chrome

La Prompt API de Chrome es una API web experimental. Esta tecnología expone Gemini Nano directamente al JavaScript de cualquier página. Cabe destacar que Gemini Nano es la versión más pequeña de su familia. El modelo no vive en un servidor remoto; Por el contrario, se descarga una sola vez en el dispositivo del usuario. A partir de ahí, todas las inferencias ocurren localmente.

Para nuestro caso de uso, esto significa que el navegador puede recibir una petición en lenguaje natural. El sistema decide qué visualización corresponde y devuelve la especificación de la gráfica. Todo esto ocurre sin que ningún dato salga de la máquina.

Una combinación que funciona muy bien: navegador + catálogo predefinido

La idea clave aquí es que no necesitamos que el modelo escriba código. Con la Prompt API en el navegador y un catálogo cerrado de componentes, el modelo solo tiene que elegir entre cinco opciones e indicar qué campos del dataset usar. Es una decisión pequeña, encajada en un esquema bien definido. Por lo tanto, un modelo del tamaño de Gemini Nano puede tomarla con total fiabilidad.

El resultado es un flujo de generación de interfaces dinámicas con grandes ventajas:

• Sin coste: No hay API key, no hay facturación por tokens ni cuotas. Las inferencias son gratis para siempre.

• Con privacidad total: El prompt, los datos y la respuesta nunca salen del navegador. Esto es vital para entornos con información sensible, como datos médicos o financieros. Se convierte en un requisito técnico que ningún modelo en la nube puede cumplir.

• Tiempos de respuesta aceptables: La respuesta en modo predefinido es un pequeño JSON. Así, la latencia se mantiene en un rango razonable.

• Funciona offline: Tras la descarga inicial, la conectividad deja de ser necesaria.

🎥 Demo en vídeo — IA local en navegador + componentes predefinidos

Ver en YouTube

Donde la cosa se complica: generación libre con Gemini Nano

El modo libre es otra historia. Pedirle al modelo local que escriba un componente React completo es sumamente complejo. Debe procesar Recharts, hooks y JSX válido, lo que saca al modelo de su zona de confort.

Recordemos lo obvio: un LLM es un modelo probabilístico. La salida correcta no está garantizada. Por lo tanto, cuanto más pequeño es el modelo, más fácil es que aparezcan errores de sintaxis o datos mal transformados. Con Gemini Nano en modo libre nos encontramos dos problemas combinados:

1. Tiempos de espera altos: La salida es larga (un componente entero) y la inferencia local en CPU o GPU integrada es más lenta que la de un acelerador dedicado en la nube. 2. Inconsistencia en la respuesta: El modelo no siempre acierta con la sintaxis JSX o con la forma de los datos.

Por el contrario, con modelos potentes vía API externa ambos problemas se minimizan: la latencia se reduce y la consistencia sube hasta un punto donde la experiencia de usuario se mantiene fluida y la generación libre se vuelve una herramienta viable, no una curiosidad.

Las cuatro combinaciones posibles de Generative UI

La interfaz combina los dos selectores en una matriz de cuatro opciones:

Lecciones aprendidas

1. El modelo no necesita ver los datos para visualizarlos: En modo predefinido, el modelo solo declara la intención ("quiero una gráfica de barras de ingresos por mes"). Los datos reales los inyecta el servidor. Esta separación es clave para mantener los costes bajo control y evitar respuestas truncadas.

2. La IA en el navegador no es una versión "más barata" del servidor: es otra herramienta. Gemini Nano en Chrome no es un sustituto de los modelos grandes. Es gratis y privado, pero también más pequeño, más lento y menos preciso. Para elegir entre un catálogo cerrado de componentes funciona muy bien; para generar código React libre, los errores y los tiempos de espera son frecuentes. La decisión correcta no es "local vs. servidor" en abstracto, sino entender qué garantiza cada uno y elegir según el caso de uso.

Conclusión

Generative UI no es una tendencia de laboratorio. Es una evolución natural de cómo los modelos de lenguaje se integran en productos reales. Actúan como capas de orquestación que deciden qué mostrar y cómo hacerlo, no como meros chatbots de texto.

Las dos estrategias que hemos explorado —catálogo predefinido y generación libre— no son excluyentes. En producción, lo más sensato es combinarlas: usar tool calling para los casos conocidos y frecuentes, y reservar la generación libre para cuando el usuario necesita algo que no estaba previsto.

El código completo de la demo está disponible en el repositorio, junto con instrucciones de puesta en marcha para quien quiera explorarlo de primera mano.

¿Quieres saber más sobre cómo aplicamos IA generativa en productos reales?