AI-generated UI still needs a design system

The default state is the least interesting thing to inspect in an AI-generated interface.

It will usually look good. The model has enough examples of polished screens to make a convincing screenshot. The harder question is whether the screen still makes sense when the data is missing, the request fails, the name is too long, or the user is not allowed to do the obvious thing.

That is where the design system earns its keep.

I want the system to define more than colors and components. It should carry product decisions:

• tables instead of cards for dense comparison
• a named object in destructive confirmation
• visible filters when results update
• one useful next action in an empty state
• a predictable keyboard path
• product nouns instead of vague copy such as “manage” and “explore”

Those rules give a generator a smaller target. “Make it modern” is an invitation to invent. “Use the existing table, toolbar, dialog, and form patterns; include loading, empty, error, disabled, and permission states” is a constraint the product can review.

The states are where I look first:

loading
empty
error
disabled
permission denied
partial data
long text
narrow viewport
keyboard focus
destructive confirmation

A generated screen that handles only the happy path is not a finished screen. It is a screenshot with a missing product.

I also review the interface interactively. Tab through it. Resize it. Fill it with long names. Remove every record. Simulate a failed request. Trigger the dangerous action. Check whether the user can tell what happened and how to recover.

AI is useful here because it can produce a first pass quickly. The design system makes that speed less random, and the review makes the result accountable.

The faster the interface can be generated, the more expensive an unreviewed pattern becomes. Every prompt is a potential fork in the product. Keep the forks inside rules the team can see.