Runtime-generated UI: the first serious year
Updated: 2026-07-07
The idea of UI generated on the fly instead of pre-built reached production in 2025. After a year of real-world use, the balance is more nuanced than the initial enthusiasm suggested.
In 2024 the idea of a UI that generates itself on the fly, instead of being hand-built, was still a lab experiment. In 2025 it reached real production, with Vercel’s v0[1], with Generative UI from Vercel’s AI SDK[2], and with teams building their own version on top of React or Vue. I have spent a year watching it run in real projects, and 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 does not fit frequent flows that rely on 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 cannot 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) that the frontend renders. Components are pre-authorised: the model does not invent new components, it only combines the ones already on the approved list.
Where it does not deliver
High-frequency usage flows that rely on muscle memory. Users learn the interface and want consistency; UI that changes every session is frustrating. The generative pattern works for one-off or rare cases, not for the 80% of daily work.
It also does not 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, and in high-frequency flows that cost explodes fast. The pattern that works is generate once, cache the resulting tree, and reuse it. Even so, the cost stays higher than a pre-compiled UI; budget for it before committing to the approach. If your team already tracks agent token spend, the same discipline from FinOps for agent tokens (a jacar piece written in Spanish) applies here too: measure before deciding whether the generative pattern pays off.
Security: a new attack surface
If the model generates the UI, a prompt injection can influence what is shown. The OWASP GenAI Security Project[3] treats this as the number one risk for LLM applications on its 2025 list (LLM01: Prompt Injection): an attacker can inject text into an input field so the model renders a component that should not exist, for example a fake login form. You do not need a specific incident to take it seriously, it is exactly the pattern that risk catalogue describes.
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. It is the same cost-quality balance covered in Claude Sonnet 4.6 in production: the point is not picking the most powerful option for everything, it is putting each piece of work where it pays off best.
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 and 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.
If you want the Spanish version of this balance, it is at UI generada en tiempo real: primer año en serio.