Generative UI Without Chaos: Stick to Your Design System, Not Random HTML

Short answer: Generative UI works when the model fills slots in YOUR component catalog—Button, Card, FormField—not when it invents HTML and CSS. Tools like json-render constrain the AI to a schema, stream JSON, and render your real React components. Optional shadcn-oriented packages give you a head start with dozens of ready building blocks.

The messy way most teams try generative UI

Someone pastes a screenshot into a chat model and asks for “the same dashboard in code.” The model returns HTML that looks fine in a preview and fails in production: uneven spacing, weak contrast, missing labels for screen readers, and colors that ignore your brand. Designers reject it. Engineers rewrite it. A week disappears.

The root problem is freeform output. Large models are good at plausible markup. They are bad at remembering your radius tokens, your focus rings, and your Arabic typography rules unless you force those rules into a machine-checkable catalog.

The better pattern: catalog, then compose

Publish a list of components the agent may use. Define props with a schema (many teams use Zod). The model returns JSON that only names those components. Your server validates the JSON. Your React app maps JSON to real components. json-render documents this as catalog → constrained JSON → progressive render, with React support and shadcn-style packs when you want a ready kit.

Treat the agent as a composer, not a freehand illustrator. It may only place bricks you already approved in Storybook. If a brick is missing, a human adds it once. Then every future agent session can reuse it safely.

Why the design system must come first

• Brand stays consistent because color and type come from tokens, not from model taste.
• Accessibility ships inside the component instead of being bolted on later.
• Server validation rejects unknown component types before anything paints.
• Streaming feels fast: cards and forms appear as the model answers.

For Webdivs work we keep an ocean palette—navy, cyan, amber. We do not let generative sessions invent purple themes that fight the brand. Your tokens should be just as strict.

Rollout checklist

• List 10–20 components the agent may call.
• Write schemas: required props, enums, max lengths.
• Validate on the server. Reject unknown types and huge payloads.
• Render inside your existing React tree with your tokens.
• Require human accept/edit before customer-facing screens go live.
• Keep Storybook or a gallery page as the visual source of truth.

Prompting patterns that waste less time

Bad prompt: “Build a beautiful analytics dashboard.” Good prompt: “Using only Card, Metric, and BarChart from the catalog, show orders today, orders this week, and top three products. Use Arabic labels.” The second prompt names tools and constraints. The model stops inventing widgets you do not have.

Version your catalog. When you rename a prop, keep a short migration note in the system prompt for one sprint so old JSON does not fail silently. Log every generated tree for debugging and for training better prompts later.

RTL and Arabic realities

Fix direction and logical CSS in the design system before you turn on generative UI. Agents will not magically repair a left-only kit. Every catalog component should already respect dir, margins, and icon mirroring. Test generative output in Arabic on day one of the pilot, not as an afterthought.

Also watch number and date formatting. Catalog components that format currency should accept a locale prop. Otherwise the model will hard-code English formats into Arabic screens.

Practical tips from real projects

Start with internal tools—admin filters, report layouts, empty states—before marketing pages. Internal users forgive rough edges; customers do not. Add a safe mode that only allows read-only components for junior agents or public prompts. Reserve delete, charge, and publish actions for sessions with a human in the loop.

When a layout stops changing, export it to normal React code if your stack supports export. You should not need a generative runtime forever for a settled screen. That keeps performance predictable and code review normal.

A 30-day adoption sketch

Week 1: inventory components and pick the first ten for the catalog. Week 2: schema, server validation, and a Storybook page. Week 3: pilot on one internal screen with human accept. Week 4: measure edit rate—how often humans rewrite the agent’s layout. If edit rate stays high, improve the catalog and prompts before expanding.

Success is not “the agent designs everything.” Success is “the agent drafts within brand, and humans finish faster.” Track that metric explicitly on the pilot.

How Webdivs helps

We build bilingual design systems on Next.js and wire guarded generative-UI catalogs with validation and human review. If you want registry-first UI instead of gambling on freeform HTML, talk to us at webdivs.com/contact.

Governance without slowing the team

Write a one-page policy: which environments allow generative UI, who can approve customer-facing screens, and how long generated JSON is retained in logs. Put the policy next to the catalog README so engineers do not hunt for it. Review the policy when you add a component that can delete data or move money.

Run a monthly gallery review with design and engineering. Look at the weirdest agent outputs from the last sprint. Either tighten the schema or add a missing component. That meeting is cheaper than letting brand drift accumulate.

If you use multiple products—marketing site, admin, mobile web—share one catalog package via your monorepo. Divergent catalogs recreate the freeform problem inside the company.

What “done” looks like for a pilot

You have ten validated components, one internal screen drafted mostly by an agent, human edit time under your agreed threshold, Arabic RTL rendering without manual CSS hacks, and a documented rollback that disables generative routes if validation fails open. When those are true, expand carefully to a second surface.