Why Runtime Assembly Beats Static Code Generation Every Time
Most teams spend 40% of their UI development budget on something that adds zero user value: rebuilding components after design tweaks. Static code generators lock you into a painful cycle where one spacing change in Figma triggers a full redeploy cycle, stale components pile up, and your users see yesterday's layout while your designers stare at merged PRs.
Here's where it gets interesting: Runtime assembly decouples design from code entirely. Your UI adapts without redeploying the app. Notion and Linear already use this pattern. They render context-specific cards, tables, and dashboards based on what the user needs right now, not what was hardcoded last sprint.
"The interface is assembled at runtime rather than generated as static code. Platforms like Claude, Notion, and Linear use query-aware composition where UI elements are dynamically selected and rendered based on user intent."
But that's only half the picture. The real win isn't just avoiding redeploys. It's that your design system becomes a living API instead of a dead style guide.
The 3-Layer Architecture That Makes Dynamic UI Actually Maintainable
Here's the problem most teams hit: they try runtime assembly and end up with spaghetti code that nobody can debug. The solution is a three-layer architecture that keeps each concern isolated.
Layer 1: A design system registry. This serves tokens, components, and rules via a lightweight API. Your colors, spacing, typography, and component variants live here as data, not hardcoded CSS. When a designer changes a primary button radius in Figma, the API updates and your UI follows.
Layer 2: A runtime orchestrator. This selects and assembles components based on user intent and context. It's a thin decision engine that asks: "What does this user need right now? A table? A card? A form?" and picks the right assembly path.
Layer 3: A fallback chain. When the AI or design data is unavailable, your UI gracefully degrades. No blank screens. No error modals. Just a simpler layout that still works.
Think about it this way: Each layer handles one job. The registry knows what exists. The orchestrator knows what to use. The fallback knows what to do when things break. This is where most people get stuck: they try to build one monolithic system that does all three and it collapses under its own complexity.
How to Wire Your Figma Design System Into Live Code Without the Handoff Headache
Design handoff is a lie. You know it. I know it. Every developer has received a Figma file with 47 unnamed frames and "final_v3_actually_final.sketch" energy.
The 1-2 Punch: You can import design tokens and component variants directly from Figma using tools like Claude Design. These tools ensure AI outputs conform to established style guides, variables, and components. They automate the handoff process so design changes in Figma become API updates, not redeploy triggers.
Map Figma auto-layout rules to CSS Grid or Flexbox at runtime. When a designer changes padding from 16px to 24px, your runtime picks it up. When they swap a card variant from "default" to "featured," your orchestrator sees the new variant key and renders it.
The loop is simple: Design changes in Figma → API updates → UI refreshes without a deploy. Your designers get instant feedback. Your users get the latest layout. Your DevOps team stops getting pinged about "just one more spacing change."
Query-Aware Composition: Let User Intent Drive Which UI Elements Render
Now for the part nobody talks about: How do you decide which UI to show? The answer is query-aware composition, and it's simpler than you think.
Classify incoming requests with a lightweight AI router. Tables for data queries. Cards for summaries. Forms for input. The router doesn't need to be a massive LLM. A small, fast model can classify intent in under 100ms.
Use Zod-validated tool calls to ensure the assembled UI matches both design specs and functional requirements. The Vercel AI SDK 6 supports this natively with agent abstractions and streaming. Your orchestrator calls a tool, validates the output against your design schema, and assembles the UI.
Cache assembled layouts in Redis with a semantic key. When a user asks for "last week's sales data," your system checks the cache first. If the same query was made 5 minutes ago, the pre-assembled layout renders instantly. No model call. No assembly overhead. Just instant UI.
Scaling Runtime UIs Without Breaking the Bank on AI Costs
Here's the fear that stops most teams: "AI costs will eat us alive." And they're right if you do it wrong.
Route simple UI compositions to small, cheap models. A card layout with three fields? A small model can handle that for pennies. A complex dashboard with nested tables, conditional charts, and role-based visibility? That needs a high-end model. By routing intelligently, teams cut costs by up to 70%.
Use pgvector for hybrid relational-vector storage. Your design system data lives in PostgreSQL with vector embeddings for semantic search. This scales to millions of components without dedicated vector infrastructure. Only migrate to specialized stores when you exceed that threshold.
Stream token-based UI assembly to users. Instead of making them wait for the full layout to compile, stream the tokens as they're assembled. Users see the skeleton appear, then the content fills in. It feels instant even on complex layouts.
The Debugging Playbook for Runtime-Assembled Interfaces
When something breaks in a runtime-assembled UI, you can't just "check the code." The code is assembled on the fly. You need a different approach.
Log every assembly decision. Which model was called? Which components were selected? Why did the orchestrator choose a table over a card? Every decision gets a log entry with a trace ID.
Use Langfuse or LangSmith to trace token spend and catch drift in design compliance. These tools show you when the AI starts deviating from your design system. If a component variant disappears from the output, you catch it before users do.
Implement a visual inspector overlay. Click any rendered element and see its design token source. "This card uses 'primary-bg' from the design system registry, version 2.3. The orchestrator selected it because the user's query was classified as 'summary'." This turns debugging from guessing into investigation.
Your First Runtime-Assembled Component in 15 Minutes
You don't need a massive infrastructure project to start. Here's the smallest possible implementation that proves the pattern works.
Step 1: Set up a design token API endpoint serving your primary colors, spacing, and typography. A simple JSON endpoint on your existing backend. No new infrastructure.
Step 2: Build a simple orchestrator that picks a card or table layout based on a query parameter. A switch statement and two component templates. That's it.
Step 3: Wire it into your Nuxt or Laravel app with a single async component. The component fetches the token data, calls the orchestrator, and renders the result. No redeploy needed.
That's your first runtime-assembled UI. It takes 15 minutes. It proves the concept. And it opens the door to a system where your UI adapts to your users instead of the other way around.
The core takeaway in one sentence: Runtime-assembled UI lets your design system live as an API, not a static file, so your interfaces adapt to user intent without redeploying.
Your next action: Set up that token API endpoint today. One route. Three colors. Two spacing values. See how it feels when your CSS comes from a live source instead of a compiled file.
Which approach are you using? The tradeoffs between static generation and runtime assembly are real. Drop your experience below. I want to hear what broke when you tried this and what surprisingly worked.