UI generada en tiempo real: primer año en serio
Actualizado: 2026-05-03
En 2024 la idea de “UI que se genera sobre la marcha” era experimento. En 2025 llegó a producción con v0 de Vercel[1], Generative UI de Vercel AI SDK[2], y equipos construyendo su propia versión encima de React/Vue. Un año después, 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 son pre-autorizados —el modelo no inventa componentes, solo los combina—.
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. Para flujos con alta frecuencia, el coste se dispara. El patrón que funciona es generar una vez, cachear el árbol resultante, y reusar. Incluso así, el coste es mayor que una UI pre-compilada. Hay que presupuestarlo antes de comprometerse con el enfoque.
Seguridad: nueva superficie de ataque
Si el modelo genera la UI, un prompt injection puede influir en qué se muestra. Caso reportado en 2025: un atacante inyectó texto en un campo que hizo al modelo generar un componente de “login como admin” falso.
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.
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, 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.
