Nuestro diario9 min de lectura

El problema de granularidad en GenUI: ¿dónde debería detenerse la generación del LLM?

Notas de la construcción del motor GenUI de AirJelly — y por qué darle más libertad al LLM empeoró el resultado.

Translated by AI

Este blog surge de nuestra exploración práctica del motor GenUI en el proyecto AirJelly. No empezamos con teoría. Empezamos con un experimento que, sinceramente, fue bastante frustrante: ¿por qué el resultado empeoró cuando le dimos al LLM más libertad para generar UI?

01 · Contexto

Por qué GenUI merece una atención seria

Antes de los detalles, vale la pena dejar claro por qué GenUI es un problema de ingeniería serio, no solo un truco de demo. En Generative Interfaces for Language Models, el equipo de SALT-NLP / Stanford comparó las preferencias de los usuarios entre GenUI y el chat tradicional basado en texto. La conclusión es clara: cuando un sistema de IA necesita comunicar contenido estructurado y denso en información, una interfaz generada dinámicamente puede ser mucho mejor que un muro de texto.

La ola de GenUI se aceleró entre 2023 y 2025 porque dos condiciones maduraron a la vez: los LLM mejoraron mucho en la generación de código, y ecosistemas de componentes como shadcn/ui y Radix se volvieron lo bastante estables como para construir sobre ellos. Una vez que esas condiciones estuvieron dadas, las herramientas surgieron de forma natural — Vercel v0 es una de las implementaciones industriales más representativas.

02 · El punto de partida

Dejamos que el LLM improvisara libremente, y el resultado empeoró

En la rama feat/genui-real-content-experiment ejecutamos un conjunto de comparaciones. El enfoque antiguo tenía un diseño fijo y componentes unificados — pulido y predecible. El nuevo enfoque hacía el diseño más flexible, pero lo visual se volvió desordenado y los estilos de los componentes, inconsistentes.

Esto iba contra nuestra intuición. Cuanta más libertad le dábamos al modelo, menos control teníamos, y peor se volvía la consistencia visual. El artículo Gen-UI-Lang señala lo mismo: pide a un LLM HTML o JSX en bruto y la salida será verbosa, frágil y fácil de romper. Eso no es un problema de calidad del prompt — significa que empujamos al LLM a una granularidad donde no da lo mejor de sí.

03 · La tensión central

Una contradicción estructural en GenUI

A través del experimento identificamos una contradicción interna que se aplica básicamente a todo sistema GenUI.

Cuanta más libertad tiene el LLM, más difícil es garantizar la consistencia visual. Cuanto más fuertes son las restricciones, menos significativo se vuelve GenUI.

Esta es una tensión estructural del paradigma, no un error de una implementación concreta. Todo sistema GenUI tiene que encontrar su equilibrio en algún punto entre estas dos fuerzas. Así que la pregunta se vuelve muy concreta: ¿dónde debería detenerse el límite de generación del LLM?

04 · El campo

Elecciones de granularidad existentes

Antes de decidir nuestra propia respuesta, ayuda ver cómo otros han abordado la misma pregunta.

Vercel v0 — generar hasta el código de componente

v0 permite que el LLM llegue hasta el final y genere código completo de componentes React. Su consistencia visual proviene del sistema de tokens semánticos de shadcn/ui — externaliza la consistencia al tema de la biblioteca. El costo: la lógica de generación queda fuertemente acoplada al ecosistema de componentes, así que salir del stack shadcn/ui + Next.js + Vercel genera fricción real.

Una forma típica del código de componente al estilo v0

<Card className={cn("flex flex-col",
  plan.recommended && "border-primary shadow-lg scale-105"
)}>

El enfoque de arXiv — una representación intermedia estructurada

El enfoque de SALT-NLP / Stanford inserta una representación intermedia estructurada entre el lenguaje natural y el código de UI, en dos niveles: un flujo de interacción de alto nivel (un grafo dirigido de rutas de usuario y etapas de tarea) y máquinas de estados finitos de bajo nivel (los estados de cada componente y sus respuestas a eventos). La salida final sigue siendo HTML, CSS y JavaScript — la representación es un riel de guía, no el destino.

Gen-UI-Lang — definir una capa de intención de UI

Gen-UI-Lang diseña un DSL dedicado para que el LLM solo emita descripciones estructuradas de nodos. La estructura de nodos es explícita, superficial y consistente — exactamente lo que los LLM generan de forma fiable. Frente a generar HTML directamente, reporta una reducción del 65,3 % en el uso de tokens a la vez que mejora la estabilidad, y puede renderizar a HTML, React JSX o Gradio desde la misma descripción.

Una descripción de intención de UI de Gen-UI-Lang

genui(
  row(
    text("Sales Overview"),
    btn("Load", on_load=lambda: get_graph(2001, 2002))
  ),
  chart(type="line", data="sales_q4"),
)

05 · Nuestra elección

Detenerse en la capa de semántica de producto

Los tres enfoques empujan al LLM hacia arriba, lejos de la capa de renderizado. Solo difieren en dónde se detienen. Nosotros elegimos detenernos más arriba que cualquiera de ellos: en la capa de semántica de producto.

El LLM no emite nodos de UI genéricos como row o btn. Emite conceptos de producto — «esto es una tarjeta de resumen de tareas, alta densidad de información, proveniente del calendario de hoy». Qué componente renderizar y cómo disponerlo lo decide enteramente la biblioteca de componentes — no el LLM.

01La lección directa de nuestro caso de fallo

Una vez que aflojamos la libertad de generación del LLM, el resultado visual empeoró. Cuanto más cerca está el LLM de la capa de renderizado, mayor es el costo de su aleatoriedad.

02La analogía con los motores de renderizado de los navegadores

Los navegadores no dejan que el JavaScript de la página controle los píxeles directamente. Aceptan una descripción DOM controlada, y el motor decide los píxeles. Un motor GenUI debería funcionar igual.

03La fiabilidad de las salidas estructuradas de los LLM

OpenAI lanzó Structured Outputs en 2024 precisamente para combatir la deriva de formato. Cuanto más cerca está la salida de la capa de renderizado, mayor es el costo de los errores de formato.

04La necesidad a largo plazo de una biblioteca de componentes reemplazable

Detente en la capa de semántica de producto y la biblioteca de componentes se convierte en un backend de renderizado conectable — cambia el sistema de diseño mañana sin tocar la capa semántica.

06 · Una dirección no verificada

Generación en dos rondas

Mientras depurábamos el complejo componente GenUIPager, descubrimos que una sola pasada del LLM tenía dificultades para optimizar la calidad del contenido y la calidad del diseño al mismo tiempo. Eso nos llevó a una arquitectura de dos rondas — como hipótesis.

Hipótesis de generación en dos rondas

First-round LLM:  content orchestration + page-structure decisions
                  (product semantics layer)
      ↓
Second-round LLM / component library:  concrete rendering decisions

La motivación es razonable: la orquestación de contenido y el renderizado son dos tareas cognitivas distintas, y forzarlas en una sola pasada puede hacer que interfieran entre sí.

Pero tenemos que ser honestos: esto es solo una hipótesis, y no la hemos validado por completo.

Está aquí porque apunta a una dirección que vale la pena explorar — no porque sea una conclusión asentada.

07 · El mapa

Un mapa de compensaciones de las elecciones de granularidad

Ninguna elección de granularidad es universalmente correcta. Depende de la tolerancia del producto a la inconsistencia visual, del ciclo de vida esperado de la biblioteca de componentes y de cuán estructurado sea el contenido generado.

Enfoque	Hasta dónde emite el LLM	Cómo se garantiza la consistencia	¿Biblioteca reemplazable?	Escenarios adecuados
Vercel v0	Capa de código de componente	Tokens semánticos de shadcn/ui	No, fuertemente acoplada	Prototipado rápido dentro del ecosistema Vercel
Gen-UI-Lang	Capa de intención de UI general	Renderizador multiobjetivo	Sí, agnóstica al framework	Prototipado entre frameworks, flujos de trabajo centrados en la eficiencia
Enfoque de arXiv	HTML / CSS / JS	Representación intermedia estructurada como rieles de guía	Depende	Escenarios con alta complejidad de interacción
AirJelly	Capa de semántica de producto	La biblioteca de componentes controla por completo el renderizado	Sí, conectable	Aplicaciones con altos requisitos de consistencia de la UI de producto

Si el producto tiene baja tolerancia a la inconsistencia visual, la granularidad debería ser más alta, más cercana a la semántica de producto. Si es probable que la biblioteca de componentes evolucione o se reemplace, más alta aún. Y si el contenido generado está muy estructurado, es más adecuado describirlo semánticamente en un nivel superior.

Fuentes

Fuentes y lecturas adicionales

Generative Interfaces for Language Models (SALT-NLP / Stanford) — repositorio de código oficial
Gen-UI-Lang — arXiv · repositorio de GitHub · SSRN
Vercel v0 — Documentación de Vercel · Blog de Vercel · documentación de sistemas de diseño de v0
shadcn/ui — sitio oficial

Cierre

La granularidad es la decisión de diseño central en GenUI.

La mayor conclusión no es que hayamos encontrado la respuesta correcta. Es que aclaramos la pregunta: GenUI no se trata de dejar que el LLM dibuje la interfaz. Se trata de diseñar una división clara de responsabilidades entre el LLM y el sistema de renderizado.

La elección de la granularidad decide dónde se traza esa línea, y dónde se traza la línea decide la mantenibilidad del sistema, su estabilidad visual y su capacidad de evolucionar a largo plazo.

En octubre de 2025, el W3C Design Tokens Community Group publicó la especificación estable Design Tokens 2025.10, una señal de que separar la semántica de lo visual se está convirtiendo en un estándar de ingeniería. El problema de granularidad en GenUI es esa misma tendencia manifestándose dentro de las interfaces generadas por IA.

Seguimos en el camino. Si estás explorando algo similar, me encantaría hablar.

Más del equipo de AirJelly →