When agents generate interfaces, taste becomes infrastructure.
That sounds like a slogan, so here is the concrete version. A design system used by humans can afford to be partly cultural: a Figma file, a few conventions, and a senior designer who notices when something looks off. A design system used by a generator cannot. Whatever is not written down explicitly will be filled in from the generator's defaults, and its defaults are the average of every website it has ever seen.
The drift problem
Generated UI drifts in a specific way. Each individual screen looks fine. Put four of them next to each other and they are clearly not from the same product — three shades of blue, four button heights, spacing that is close but never equal.
This is worse than ordinary inconsistency because it is fast. A team can generate a dozen screens in an afternoon and end up with a dozen small divergences that are individually not worth fixing and collectively make the product feel unfinished.
Tokens as inputs, not documentation
The fix is to stop treating the design system as a reference document and start treating it as an input to generation.
Evonx reads tokens — colour, type scale, spacing, radius — and the component patterns already present in your codebase, and treats them as constraints rather than suggestions. A generated screen composes what exists before it invents anything new. When it does need something new, that thing is built from the same primitives.
This is the same principle behind how the agent handles code: read the real thing first, follow the conventions that are actually there, and don't import habits from elsewhere.
Writing a system a generator can use
A few things distinguish design systems that survive contact with a generator:
- Name the decisions, not just the values. "Surface, elevated surface, border, muted border" travels further than four hex codes, because it tells the generator which to use where.
- Make the scale finite. An open-ended spacing scale gets treated as permission to interpolate. Eight steps that exist are better than infinite steps that might.
- Encode states, not just defaults. Hover, disabled, loading, empty, error. These are where drift concentrates, because they are the ones missing from the mockup.
- Prefer composition over new components. If the system can express a screen by combining what exists, the generator has no reason to invent a variant.
None of this is new advice for design systems. What changes is the cost of ignoring it: a gap that a human designer would quietly paper over becomes a gap that gets filled with something generic, at speed, across every screen.
Start from what already exists
Teams often assume this requires building a formal design system first, and then never start. It does not. The most valuable version of this work is usually extraction rather than creation: your codebase already contains the answers, distributed across components that were written at different times by different people.
Pulling those into an explicit set — these are the surfaces, this is the type scale, this is what a primary button is — takes an afternoon and immediately raises the floor on everything generated afterwards. It also surfaces the disagreements that were already there, which is uncomfortable and useful in equal measure.
Why this matters more as generation gets faster
The faster the generation loop gets, the more leverage the design system has — in both directions. A good one compounds: every new screen arrives already looking like your product, so review is about the flow rather than the styling. A weak one also compounds, and you pay for it in a slow, unglamorous cleanup later.
Investing in the system is not a detour from shipping. When screens can be produced in minutes, the system is the only thing keeping them a product rather than a pile of pages — which is also what makes a preview worth looking at in the first place.