Runtime-generated UI: the first serious year
Actualizado: 2026-05-03
In 2024 the idea of “UI that generates on the fly” was experiment. In 2025 it reached production with Vercel’s v0[1], Vercel AI SDK’s Generative UI[2], and teams building their own version on top of React/Vue. A year later, the balance is more nuanced than the initial enthusiasm promised.
Key takeaways
- Typical pattern: the LLM returns a pre-authorised React component tree (JSON with names and props), never raw HTML/JSX.
- Generated UI fits personalised dashboards, adaptive forms, and ad-hoc visualisations; it doesn’t fit frequent flows requiring muscle memory.
- Per-LLM generation cost is significant; the “generate once, cache, reuse” pattern is mandatory for high-frequency flows.
- A prompt injection in an input field can influence which components are generated; components must be pre-authorised with strict allowlist.
- The winning hybrid pattern: static UI for the shell and critical operations, generative for specific widgets and rich conversational responses.
Where it works
Cases where runtime generation delivers real personalisation that static UI can’t match without combinatorial explosion:
- User-personalised dashboards based on usage history and preferences.
- Adaptive forms adjusting fields based on previous answers.
- Ad-hoc visualisations built on the fly from data queries.
Typical pattern: the LLM returns a component tree (JSON with React component names and their props), which the frontend renders. Components are pre-authorised — the model doesn’t invent components, only combines them.
Where it doesn’t deliver
High-frequency usage flows requiring muscle memory. Users learn the interface and want consistency; UI that changes every session is frustrating. The generative pattern works for one-offs or rare cases, not for 80% of daily work.
It also doesn’t work well for:
- Critical operations where predictability is mandatory: finance, health, infrastructure operation.
- Auditable flows: dynamic generation dilutes the verifiability and auditability these areas require.
The hidden cost
Generating UI with an LLM each time costs tokens. For high-frequency flows, cost explodes. The working pattern is: generate once, cache the resulting tree, reuse. Even so, cost exceeds pre-compiled UI. Budget for it before committing to the approach.
Security: a new attack surface
If the model generates the UI, a prompt injection can influence what’s shown. Reported case in 2025: an attacker injected text in a field that made the model generate a fake “login as admin” component.
Mandatory defence:
- Pre-authorised components with strict allowlist.
- Never interpret raw HTML/JSX from the model.
- The model can only reference components from the approved list; it cannot create new types.
The winning hybrid pattern
The prevailing architecture combines:
- Static UI for the application shell, navigation, and critical operations.
- Generative UI for specific widgets, ad-hoc visualisations, and rich conversational responses.
This mix harvests the good of each approach without paying the full cost of one alone.
Conclusion
Runtime-generated UI is a real tool for specific cases, not the death of traditional UI as was said. The hybrid pattern — static where predictability helps, generative where personalisation helps — is the mature form. Teams adopting this mix gain real value; those wanting to replace all their UI with dynamic generation collide with costs and user frustration.
