AI design tools for developers, sorted by what they replace

The standard roundup lists twenty tools in one ranked table, which implies they are alternatives. Most of them are not. Sorting by job first makes the actual choices much clearer.

The first two rows are the ones most often confused. A screen generator and an in-repo agent do genuinely different jobs, and the choice is not about quality — it is about whether the code has to live alongside code you already have.

We read the current documentation for six major AI builders and agents, specifically looking at what their design-system features do. The pattern is consistent enough to be worth stating as a finding.

Not one of them produces a design system. All of them assume you arrive holding one. Two put the feature behind a paid or enterprise tier, which tells you they consider it valuable, and none of them offers to create the thing it wants.

This matters for evaluation. If you are choosing between tools partly on "which one keeps my UI on-brand", the answer is none of them, on their own. The variable that determines that outcome is what you feed them, and it is the same variable across all six.

Every tool in this space, given an unconstrained prompt, produces a recognisable house style: a dark hero, a gradient, a widely-used geometric sans, three feature cards with generous radii. People attribute this to the tools. It is not the tools.

A model asked for an interface with no constraints produces the most probable interface. The most probable interface is the centre of its training distribution, and every model has broadly the same centre because they were trained on broadly the same web. The mechanism in full.

Which means switching tools does not fix it. Adding constraints does — and we have some measurements on how well people currently do that. We sampled 299 DESIGN.md files published to give AI tools design guidance:

"Clean" appears in 39% of these files and "modern" in 36%. Both are words a model satisfies by producing exactly the average output people then complain about. The tool is doing what it was told.

The counter-example is worth seeing rather than asserting. Below is what the *other* half of the input looks like — a system stated as values instead of adjectives, applied across three unrelated surfaces. No tool in the list above produces this; every tool in the list above can consume it.

Within the first two rows the tools genuinely are alternatives, so it is worth being specific about how they differ. Everything here is the shape of the tool rather than a quality ranking, because quality in this category turns over faster than any article can track.

The shadcn registry line is the practical common denominator. All three can consume a registry item, which means a token set delivered that way works across the category without per-tool integration work. That is worth more when choosing than any feature comparison, because it is the part that does not change when you switch.

Notice that all three converge on the same shape: a file in the repository that the agent reads, optionally supplemented by MCP servers for things too large to hold in context. That convergence is the reason a tool-agnostic DESIGN.md is a better investment than any per-tool configuration.

Rarely covered in roundups and it dominates real adoption decisions, because the pricing shapes are genuinely different and they fail in different ways.

Demos are chosen to look good and every tool in this category has an impressive one. Five questions that separate them faster than a demo does.

1. 1

   Ask it for the second screen

   Every tool makes a good first screen. Ask for a related one and compare: same spacing rhythm? Same hierarchy? Same button treatment? Consistency between screens is the whole product, and it is never what a demo shows.

2. 2

   Give it your real constraints and see if they land

   Hand it a token file and a short list of prohibitions. Then check whether the output actually references the tokens or writes literal values next to them. This single test eliminates most of the field.

3. 3

   Ask for a dense screen, not a landing page

   A settings page, a data table, a form with twelve fields. Marketing layouts are heavily represented in training data; dense functional UI is where tools genuinely differ.

4. 4

   Check what it does with dark mode

   Ask for both themes. If it derives dark by inverting light, you will get dead shadows, muddy mid-greys and a glaring accent — and you will get them on every screen thereafter.

5. 5

   Look at how output leaves the tool

   For screen generators specifically: what arrives in your repository, in what shape, and how much rework does integrating it need? This is where the time actually goes, and no demo covers it.

Because every tool in the category consumes a design system and none supplies one, the highest-leverage move is upstream of the tool choice. Four things, none of which requires a designer.

1. Semantic colour roles, light and dark. Named by job — --primary, --muted-foreground, --border — not by hue. Without these the agent writes literals and your stylesheet learns nothing. Details.
2. A type and spacing scale with real numbers. Not "generous spacing". A list of permitted values, and a statement that anything else is a bug.
3. A prohibition list. The single highest-impact thing you can write, and the thing 76% of published guidance omits entirely. Five lines is enough to start.
4. All of it in a file in the repository. Not a wiki, not a documentation site, not a Figma comment. A file the tool reads before it writes anything. How to write it.

With those in place, most tools in this category produce noticeably better output and the differences between them shrink to ergonomics and integration. Without them, the best tool in the category produces the same generic screen as the worst.

One signal worth watching, because it comes from a direction that has no incentive to hype it. Three of the largest openly published enterprise design systems restructured within roughly eighteen months, each around the premise that the code consuming a design system is increasingly machine-written.

• IBM Carbon shipped an MCP server exposing its documentation and component code examples to agents.
• Salesforce Lightning rebuilt its CSS architecture to decouple structure from visual style, describing SLDS 2 as the foundation for its agentic design system, and shipped a linter to validate markup mechanically.
• Shopify Polaris deprecated its React library in favour of framework-agnostic web components served from a CDN.

Three different bets, one shared premise, no coordination. It suggests the durable part of this shift is not any particular generation tool — those turn over quickly — but the requirement that a design system be machine-readable, explicitly constrained, and separable from its implementation.