AI Can Generate React UI. The Real Problem Starts on Page Two.

AI-generated UI is pretty convincing when you’re building the first screen.

Ask for a SaaS dashboard and you’ll usually get something decent within minutes: sidebar, cards, tables, forms, buttons.

The trouble starts once you keep going.

By page two or three, the project already has components worth reusing, and that’s where AI coding agents often start inventing alternatives.

There’s already a Button, but another one appears.

There’s a Card, but the new page gets a slightly different implementation.

The project uses spacing tokens, yet an 18px value suddenly shows up in a component.

A few screens later, there’s another modal implementation.

Nothing is obviously broken. The app still runs and the UI may look perfectly fine.

But the codebase is slowly turning into several slightly different versions of the same UI system.

Greenfield demos hide a lot of this

AI UI generators have a much easier job in an empty project.

There’s no existing component library to understand, no design tokens to respect, no established variants, and no previous decisions to work around.

A real React product is different.

It may already have reusable React components, props, variants, a UI kit, semantic design tokens, themes, accessibility behavior, and project conventions that have accumulated over time.

Now ask Claude Code, Codex, or another AI coding agent:

Add a billing page.

The difficult part isn’t generating JSX for a billing page.

The difficult part is knowing what already exists and fitting the new page into it.

If the project already has a suitable Button, use it.

If it’s almost right but needs another variant, extend it.

If there’s already a Dialog, use that instead of building another modal locally.

If a semantic token already exists, don’t hardcode a replacement beside it.

Writing the code isn’t really the issue.

Understanding the system the code belongs to is.

You can keep fixing this in the prompt

A lot of this can be managed manually.

I’ve written plenty of prompts like

Check the existing components first.
Reuse the current UI kit.
Don't create duplicate components.
Use semantic design tokens.
Extend existing variants where possible.

That helps.

But after doing this for a while, I realized I was spending a surprising amount of my prompts policing the design system.

I was supposed to be thinking about the product.

Instead I was deciding whether the agent was allowed to create another component, whether it had checked the current variants, and whether it was about to hardcode something that already existed as a token.

The manual work hadn’t disappeared.

It had just moved into the prompt.

I’d rather think about the product, not the UI plumbing

In practice, my prompts should stay focused on the product: build the dashboard, add Projects, work on Project Details, create onboarding, or rethink Settings using a visual reference.

I shouldn’t have to stop every time and decide whether the agent needs to reuse a component, add a variant, or extend the token system.

That should happen underneath the product work.

The rough rule is simple:

reuse → extend → create → validate

If something already exists, reuse it.

If it’s close, extend it.

Only create something new when the product actually introduces a new reusable pattern.

The important part is that I don’t want to manually enforce those rules in every prompt.

Starting from scratch creates the opposite problem

There’s another version of this problem with new products.

You can build a complete design system before designing the actual application, but you don’t yet know every pattern the product will need.

Or you can generate twenty screens first and clean everything up afterwards.

Then you’re left deciding which of the five similar buttons should become the real one, which spacing values should turn into tokens, and which repeated patterns belong in the UI kit.

A better flow, at least for me, is to let the system grow from the product.

The Dashboard introduces the first reusable components.

Projects reuses them.

Project Details needs another Badge state, so the existing component changes.

Settings introduces a new repeating pattern, so that becomes reusable.

Billing needs another semantic state, so the token system grows.

After several pages, you don’t have a pile of unrelated AI-generated screens.

You have one React product with a component system that has evolved alongside it.

The design system matters, but it isn’t the thing I want to design all day

I absolutely want reusable components, predictable variants, and consistent design tokens.

But those are infrastructure.

When I’m working on a product, I’d rather spend my time deciding what the user sees, how a flow works, which screens are needed, and how the product behaves.

The design system should support that work.

It shouldn’t become a second product I have to micromanage every time AI generates a page.

I also don’t want a separate design-to-code step

Even if an AI design tool generates a great interface, if the result is still a canvas or mockup, I still need to turn it into the actual React application.

The workflow is still roughly:

idea
→ design
→ mockup
→ handoff
→ React implementation
→ component cleanup
→ design system cleanup
→ business logic

AI can make that pipeline faster, but it’s still a pipeline.

I’d rather work more like this:

describe the product
→ design directly in React
→ components, variants, tokens, and UI kit evolve with it
→ continue building the product

At that point, there isn’t a separate
now convert the design to React” phase.

You’re already working in the React implementation.

Code stays the source of truth

This is probably the part I care about most.

If the production app already runs on React components, I don’t really want another representation of the same UI system living somewhere else.

The real Button is already in the repository.

Its props are there.

Its variants are there.

The real design tokens are there.

The actual interaction states are there.

The component library used by the product is there.

So it makes more sense to me for the AI design workflow to operate directly on that system.

Code stays the source of truth.

That’s what pushed me to build Varelyo

This is the problem that led me to build Varelyo.

I’m the developer behind it, so this is obviously not an independent review of the tool. It came out of a workflow I wanted for myself.

I wasn’t trying to build another model that writes React better than Claude Code or Codex.

Those tools are already good at writing code.

What I wanted was a different layer around them: a harness that lets me stay focused on the product.

The model still writes the code.

The Varelyo harness gives it the product context, the structure of the existing UI system, and the rules for how components, variants, tokens, and the UI kit should be reused and extended.

So instead of writing:

Add a Settings page.

Check the existing components.
Don't create another Button.
Use semantic tokens.
Extend existing variants.
Keep the UI kit consistent.

I should be able to write:

Add a Settings page.

The rest belongs in the system around the agent.

That doesn’t mean the agent never creates anything new. It means new things should be created deliberately, as part of the product’s component system, rather than as one-off JSX inside the latest page.

Existing project or new product

In an existing React codebase, the goal is to understand and extend what’s already there.

In a new product, the same system can emerge gradually.

For example:

Build a project management product with Dashboard, Projects, Task Details, Team, and Settings. Use this reference as the visual direction.

Then I can work page by page.

Components appear when the product actually needs them.

Variants change as new cases appear.

The UI kit grows.

Design tokens are introduced as the visual language becomes clearer.

Each new page has something real to build on.

I don’t need to fully define the design system before I start, and I don’t need to reverse-engineer one from twenty generated screens afterwards.

What comes out the other end?

For me, an AI design tool for React should produce more than screenshots or disconnected JSX.

I want actual React product code that already belongs to a coherent system:

reusable React components
consistent props and variants
shared design tokens
an evolving UI kit
pages that build on the same component library

Then normal development continues.

APIs, state management, permissions, data fetching, business logic.

There shouldn’t be a separate stage where the team has to turn the AI design into the real React application.

They should already be working in it.

The question I keep coming back to

AI can already make a good-looking dashboard.

That part isn’t especially interesting anymore.

The question I keep coming back to is:

What does the project look like after page ten?

Is the agent still using the existing React component library?

Does it extend components instead of quietly duplicating them?

Are the design tokens still consistent?

Has the UI kit evolved with the product?

And can I keep thinking about the product itself instead of supervising the design system underneath it?

That’s what I’m trying to solve with Varelyo.

If you’ve run into the same issue with Claude Code, Codex, or other AI coding tools, I’d be interested to hear how you’re handling it.

You can also check out Varelyo to see the approach in practice.