What matters in a design system for AI coding

Most design system comparisons ask how the components look. When a coding agent writes most of your UI, a different set of questions decides whether the system helps. Here are nine, each with a test you can run in a few minutes.

1. Is the code yours?

Agents read and change code in your repo. A system that installs as source, one file per component, gives them something to read and you something to fix. A compiled package hides the implementation and pushes the agent toward wrapping and overriding.

Test: install one component and open the file. Can you change its padding in one place?

2. Are the tokens semantic?

bg-card and text-muted-foreground tell an agent what a value is for. bg-zinc-50 invites it to pick a neighbor. Semantic tokens are what make a theme change or dark mode a single switch instead of a hunt through screens.

Test: search the components for raw palette classes or hex values. There should be none.

3. Can an agent read the rules?

Docs for people are not enough. Look for guidance written as instructions, per component, in a form an agent can fetch: an llms.txt file, plain text per component or an MCP server.

Test: ask your agent which variant of a component to use for a destructive action. Does the system tell it, or does it guess?

4. Does it cover whole screens?

Most inconsistency lives in composition, not in buttons. A system with complete screens (a dashboard, a settings area, a billing page) gives the agent a pattern to copy.

Test: count how many of your product's next five screens could start from something in the system.

5. Are states designed?

Empty, loading, error, no access and over the limit. Agents rarely add them unprompted, and they are where products feel unfinished.

Test: open a full screen in the system and look for its error state.

6. Is accessibility built in?

Focus management, keyboard support and labels should come from tested primitives such as Base UI or Radix, not from the agent remembering them. Rules should cover what primitives cannot, such as labels on icon buttons.

Test: tab through a dialog and a menu. Then check whether the docs tell agents what accessibility each component needs.

7. Can you theme it without forking?

You will want your brand. Good systems expose a theme as data (palette, radius, font, density) and generate the rest with contrast checked. Forking components to change colors defeats the point.

Test: change the brand color. How many files did you touch?

8. Is there a check?

Rules get skipped. A check that reads the agent's code and reports raw colors, duplicate components and nested containers closes the loop, ideally one the agent can run itself.

Test: ask the agent to review a screen against the system. Does it have a tool for that, or only its judgment?

9. Is the licensing clear to an agent?

If part of the system is paid, the agent needs a clear answer when it tries to install a paid item without access, not a cryptic error, and a free alternative to offer.

Test: try to install a paid item without a license and read what comes back.

How Prodular UI answers these

Honestly, so you can compare:

• Yes: source in your repo; semantic tokens with ten themes, density, radius and font switches, each theme checked for WCAG AA contrast; rules per component in the docs, llms.txt and an MCP server; complete screens with their states; components on Base UI; a check_ui tool the agent runs itself; a clear license answer with a free alternative.
• Limits: it is React only and needs Tailwind CSS v4. It is new, with a small community compared with shadcn/ui. The application screens, AI workflow components and Figma library are part of Pro, which is paid. Its look is opinionated, so a product with a very different visual language will fight it.

If those limits rule it out, the checklist still applies to whatever you choose. See also How to keep AI-generated React interfaces consistent.