Why Every AI-Generated UI Looks the Same

Published August 17, 2026 · 10 min read · by the CSS DNA team

Quick answer: A language model asked to build a page with no constraints returns the statistical median of its training data. That median is Tailwind's default palette, Inter, and a three-card grid. The fix is not a better adjective in your prompt — it is giving the agent your actual values as data it can read.

You already know the look

Indigo-to-purple gradient across the hero. Inter. Three rounded cards in a row, each with a small icon in a tinted square. A pill-shaped badge above the headline saying something like "Now in beta". Generous vertical padding. A dark section near the bottom with a centred call to action.

It is competent. Nothing is broken. And it is indistinguishable from ten thousand other pages, which for a product trying to be remembered is its own kind of broken.

The indigo has a specific origin

The most-cited version of this story is not a theory. In August 2025, Adam Wathan — co-founder of Tailwind CSS — posted:

I'd like to formally apologize for making every button in Tailwind UI use bg-indigo-500 five years ago, which caused every AI-generated interface on Earth to turn indigo. Adam Wathan, co-founder of Tailwind CSS, August 2025

The mechanism is mundane and worth spelling out, because it explains far more than the color:

1. Tailwind UI shipped its example components with bg-indigo-500 buttons and indigo-600 headings.
2. Those examples were the reference for years of tutorials, starter templates, YouTube walkthroughs and open-source projects.
3. All of that landed on GitHub, Stack Overflow and blog posts — an enormous volume of public code with the same accent color.
4. Models trained on that corpus. Indigo is not a preference they have. It is the mode of the distribution they learned.

Then the loop closes: AI-generated indigo pages get published, become training data, and reinforce the same peak. Tool defaults became habits, habits became data, data became outputs, outputs became data again.

The real problem is not the color

Fixating on indigo misses the point, because the same averaging is happening on every axis at once. Change the accent to green and you still get an AI-generated page — just a green one.

Here is the full fingerprint, and what the averaging did to each decision:

The card grid is the most damaging of these and the least discussed. Three same-size cards assert that three things are equally important. Real products almost never have three equally important things — they have one that matters and two that support it. The layout is a hierarchy decision made by default, and defaults are exactly what an averaging process produces.

Why better prompts don't fix it

The instinct is to prompt harder: "make it modern", "make it premium", "don't make it look AI-generated". This mostly fails, for a reason worth understanding.

Adjectives are not constraints. "Premium" has no agreed referent, so the model resolves it the only way it can — by sampling what "premium" co-occurred with in training. That is another median. You have asked it to average a different, slightly smaller pile.

"Don't use purple" performs a little better because it is a negation over a specific token, but it just moves the output to the next most common accent. You have not supplied information; you have removed one option.

The pattern that works is different in kind:

The right column is checkable. An agent can satisfy it or fail it, and so can you. The left column can only be argued about.

The fix: constraints as data, not adjectives

Agents are good at following specifications and bad at inventing taste. So supply the specification. Three layers, in the order they pay off:

1. A token file the agent can read

Colors with their roles, the spacing scale, the type scale, radii and shadows — as values, in the repo. Whether that is CSS custom properties, a Tailwind theme, or a design tokens JSON file matters less than that it exists and is unambiguous.

This is the single highest-leverage step, because it converts every future "use our colors" into a lookup rather than a guess.

2. A DESIGN.md stating the rules a token file can't hold

Tokens carry values. They cannot say "never put three equal cards in a row" or "emphasis comes from weight, not gradient". Those are prose rules, and agents follow them well when they are specific and phrased as constraints. We cover the structure in DESIGN.md for AI coding agents, including where Cursor, Claude Code, Copilot and Windsurf each look for it.

Write the bans you actually mean. A short list of "we never do this" outperforms a long list of aspirations.

3. A reference system to start from

The hardest part of step 1 is having values at all. If you are pre-brand, the fastest honest route is to take a product whose visual language you respect, read its actual system — not its screenshot — and use that as a starting structure while you replace the specifics with your own.

CSS DNA exists for this step: it scans any live page's computed styles and returns colors ranked by usage, the real type scale, spacing, radii and shadows, then exports them as CSS variables, a Tailwind theme, JSON, or a DESIGN.md brief you can hand straight to an agent. The point is not to clone the site — see how to rebuild a design without cloning it — it is to start from a real system instead of from the median of the internet.

The check that catches it anyway

Even with all three layers, output drifts. A five-minute review catches most of it:

• Count the accent colors. More than one accent usually means the agent invented a second.
• Check the card count. Three equal cards? Ask whether those three things are genuinely equal. Usually one is the point.
• Look for gradient text and glowing borders. Both are near-perfect markers of unconstrained generation.
• Read the type scale. If the h1 and the body differ by less than about 2×, no hierarchy was designed.
• Check contrast in both themes. Generated dark modes routinely keep light-mode text colors. Ours has an APCA and WCAG audit for exactly this.
• Look at it at 400px. The card grid that justified itself on desktop is a stack on mobile, and usually a bad one.

What no amount of tooling fixes

Tokens and rules make an agent consistent. They do not make it interesting. Deciding that your product should feel severe rather than friendly, or dense rather than airy, is a judgement about who you are talking to — and that judgement is the part with no median to fall back on.

Which is the actual good news here. The homogeneity is not evidence that design is being automated. It is evidence that the un-automatable part is now the only part that distinguishes anything.