Actualizado: 2026-07-07

En 2024 la idea de una UI que se genera sobre la marcha, en lugar de programarse a mano, era todavía un experimento de laboratorio. En 2025 llegó a producción de verdad, con v0 de Vercel[1], con Generative UI del AI SDK de Vercel[2] y con equipos que montaron su propia versión encima de React o Vue. Llevo un año viéndolo en proyectos reales y el balance es más matizado de lo que prometía el entusiasmo inicial.

Puntos clave

  • El patrón típico: el LLM devuelve un árbol de componentes React pre-autorizados (JSON con nombres y props), nunca HTML/JSX crudo.

  • La UI generada encaja en dashboards personalizados, formularios adaptativos y visualizaciones ad-hoc; no encaja en flujos frecuentes que requieren memoria muscular.

  • El coste por generación con LLM es significativo; el patrón "generar una vez, cachear, reusar" es obligatorio en flujos de alta frecuencia.

  • Un prompt injection en un campo de entrada puede influir en qué componentes se generan; los componentes deben estar pre-autorizados con lista blanca estricta.

  • El patrón híbrido ganador: UI estática para el shell y operaciones críticas, generativa para widgets específicos y respuestas conversacionales ricas.

Donde funciona bien

Casos donde la generación en runtime aporta personalización real que la UI estática no puede igualar sin combinatoria explosiva:

  • Dashboards personalizados por usuario según su historial de uso y preferencias.

  • Formularios adaptativos que ajustan campos según lo que ya se ha contestado.

  • Visualizaciones ad-hoc construidas al vuelo a partir de una query de datos.

Patrón típico: el LLM devuelve un árbol de componentes (JSON con nombres de componentes React y sus props) que el frontend renderiza. Los componentes están pre-autorizados: el modelo no inventa componentes nuevos, solo combina los que ya existen en la lista aprobada.

Donde no cumple expectativas

Flujos de uso frecuente que requieren memoria muscular. Los usuarios aprenden la interfaz y quieren consistencia; UI que cambia en cada sesión es frustrante. El patrón generativo funciona para casos únicos o raros, no para el 80% del trabajo diario.

Tampoco funciona bien para:

  • Operaciones críticas donde la predictabilidad es obligatoria: finanzas, salud, operación de infraestructura.

  • Flujos auditables: la generación dinámica diluye las cualidades de verificabilidad y auditabilidad que estas áreas requieren.

El coste oculto

Generar UI con un LLM cada vez cuesta tokens, y en flujos de alta frecuencia ese coste se dispara rápido. El patrón que funciona es generar una vez, cachear el árbol resultante y reusarlo. Incluso así, el coste sigue siendo mayor que el de una UI pre-compilada; conviene presupuestarlo antes de comprometerse con el enfoque. Si tu equipo ya lleva la cuenta de gasto en tokens de agentes, el ejercicio de FinOps de tokens en agentes aplica igual aquí: mide antes de decidir si el patrón generativo compensa.

Seguridad: nueva superficie de ataque

Si el modelo genera la UI, un prompt injection puede influir en qué se muestra. El proyecto OWASP GenAI Security[3] lo trata como el riesgo número uno de las aplicaciones con LLM en su lista de 2025 (LLM01: Prompt Injection): un atacante puede inyectar texto en un campo de entrada para que el modelo renderice un componente que no debería existir, por ejemplo un formulario de login falso. No hace falta un caso concreto para tomárselo en serio, es exactamente el patrón que describe ese catálogo de riesgos.

Defensa obligatoria:

  • Componentes pre-autorizados con lista blanca estricta.

  • Nunca interpretar HTML/JSX crudo del modelo.

  • El modelo solo puede referenciar componentes de la lista aprobada; no puede crear nuevos tipos.

El patrón híbrido que ha ganado

La arquitectura que prevalece combina:

  • UI estática para el shell de la aplicación, navegación y operaciones críticas.

  • UI generativa para widgets específicos, visualizaciones ad-hoc y respuestas conversacionales ricas.

Este mix aprovecha lo bueno de cada enfoque sin pagar el coste completo de uno solo. Es el mismo equilibrio coste-calidad que ya vimos con Claude Sonnet 4.6 en producción: no se trata de elegir el extremo más potente para todo, sino de repartir el trabajo donde cada pieza rinde mejor.

Conclusión

UI generada en runtime es una herramienta real para casos específicos, no la muerte de la UI tradicional como se dijo. El patrón híbrido, estática donde ayuda la predictabilidad y generativa donde ayuda la personalización, es la forma madura. Equipos que adoptan este mix ganan valor real; los que quieren reemplazar toda su UI con generación dinámica se chocan con los costes y la frustración del usuario.

Si buscas la versión en inglés de este balance, está en Runtime-generated UI: the first serious year.

Fuentes

  1. v0 de Vercel
  2. Generative UI del AI SDK de Vercel
  3. proyecto OWASP GenAI Security