AI Can Generate More UI. Who Keeps It Consistent?

Vellira — Sat, 19 Sep 2026 16:12:38 +0000

AI can now generate UI faster than many teams can review it.

Describe a component to a coding model and, a few minutes later, you may have:

an implementation,
types,
tests,
documentation,
several variations,
and a refactor of the surrounding code.

That is a real productivity improvement.

But it changes the bottleneck.

The difficult question is becoming less:

How quickly can we create another component?

And more:

How do we keep the whole UI system coherent when humans and AI can change it this quickly?

That is one of the problems we are building Vellira around.

Generation is getting cheaper. Fragmentation is not.

Imagine an AI-generated component that looks correct, compiles, and works in isolation.

That still leaves a lot unanswered.

Does the component duplicate something that already exists?

Does its API follow the same conventions as similar components?

Does it use the same design tokens?

Does the React Native version represent the same product capability correctly?

Are accessibility expectations covered?

Were Storybook, documentation, exports, metadata, and tests updated with the implementation?

A component can be locally correct while making the system around it less consistent.

And the faster we produce UI, the faster these small differences can accumulate.

You start seeing things like:

similar components with slightly different APIs,
local colors and spacing bypassing shared tokens,
Web and React Native implementations drifting unintentionally,
accessibility behavior changing between components,
documentation falling behind the actual API,
duplicate capabilities appearing under different names,
tests encoding different expectations for equivalent behavior.

AI did not invent these problems.

It increases the rate at which they can appear.

A component library is necessary, but it is not enough

A traditional design system gives you components, tokens, guidelines, and documentation.

Those are still essential.

But a catalog can tell you that Button, Select, or Tabs exists.

It cannot automatically answer:

whether a new implementation should exist at all,
whether it follows the established API model,
whether its platform differences are intentional,
whether its documentation still matches the code,
whether it satisfies the same quality expectations as the rest of the system.

This becomes especially important when developers and coding agents work in the same repository.

A coding model can produce perfectly reasonable code that does not quite belong to the system around it.

The question becomes bigger than:

Does this component work?

It becomes:

Does this change still belong to the same product and engineering system?

The system around generation becomes more important

Coding models are getting better quickly.

We should assume they will become better at:

implementing components,
modifying large codebases,
writing tests,
refactoring APIs,
generating documentation,
making coordinated multi-file changes.

That is good.

The goal should not be to slow them down.

But faster production means the repository needs stronger boundaries.

If an agent changes ten components in one pass, the project still needs to know whether:

their APIs remain coherent,
accessibility behavior remains correct,
public exports remain synchronized,
documentation still reflects reality,
design tokens are still authoritative,
React and React Native only diverge where they are supposed to.

The better generation becomes, the more useful explicit and deterministic project contracts become.

What we are building into Vellira

Vellira started as a cross-platform design system for React and React Native.

The foundation is still familiar:

reusable components,
shared design tokens,
Storybook,
documentation,
platform-specific implementations behind shared product intent.

But while building the component catalog, another requirement became obvious.

Creating the component is only one stage of its lifecycle.

A production component also needs:

metadata,
public types,
exports,
tests,
accessibility coverage,
Storybook examples,
website documentation,
platform validation,
completeness checks,
quality checks.

So we started making those expectations machine-readable and repeatable.

For example, instead of asking a reviewer to remember every required artifact, the project can check whether a component has the expected implementation, tests, documentation, metadata, exports, and platform support.

Instead of treating component creation as:

generate file → done

we are moving toward something closer to:

intent
  ↓
component production
  ↓
implementation
  ↓
tests / accessibility / metadata / docs
  ↓
quality and completeness validation
  ↓
review
  ↓
canonical component

The important part is not any single checker or generator.

It is that the lifecycle becomes explicit.

The author matters less than the resulting state

I do not think AI-generated code needs to live in a completely separate category.

A human can introduce an inconsistent API.

A coding agent can follow an existing convention perfectly.

A developer can forget to update documentation.

Automation can keep it synchronized.

Once code enters the repository, the important question is not who typed it.

The important question is whether the resulting state of the project is valid.

That is why we are more interested in lifecycle tooling than in trying to distinguish “human code” from “AI code.”

Both humans and AI benefit when more of the consistency burden belongs to the system itself.

Cross-platform UI makes this harder

Vellira targets both React and React Native.

And “the same component” does not necessarily mean “the same implementation.”

Web and native platforms have different:

primitives,
accessibility APIs,
keyboard and focus models,
interaction patterns,
layout constraints.

Some behavior should be shared.

Some behavior should intentionally diverge.

So a good cross-platform system cannot simply copy the Web implementation into React Native and call that consistency.

It needs to preserve the same product intent while allowing each runtime to behave appropriately.

AI can generate both implementations quickly.

The harder problem is determining whether those implementations still represent one coherent component.

The bottleneck is moving toward coordination

This is probably the most interesting consequence of AI-assisted frontend development.

When producing UI becomes cheaper, teams can produce more of it.

More experiments.

More parallel changes.

More automated contributions.

More components.

The limiting resource moves away from typing speed.

It moves toward:

coordination,
consistency,
review,
maintenance.

That changes what useful developer tooling looks like.

If ten UI changes can be produced in the time it previously took to produce one, tooling that helps those ten changes remain part of the same system becomes much more valuable.

That is the direction we are exploring with Vellira:

AI can generate more UI. Vellira is being built to help keep that UI coherent.

Where Vellira is today

We are still proving this inside Vellira itself.

The immediate work is concrete:

grow the React and React Native component catalog,
make component production more repeatable,
strengthen accessibility and quality validation,
improve documentation,
make the public project easier to install and use.

We are deliberately making these workflows reliable inside one real design system before claiming that they can manage arbitrary external repositories.

But the direction is clear.

Frontend teams are going to work with more generated code, not less.

The answer should not be to make generation slower.

It should be to make the system around generation stronger.

Vellira is an open-source React and React Native design system being built in public.

DEV Community: Vellira