Design Homogenization Is Real: Why Vibe-Coded Sites All Look Alike
By The WAALEE Team · · 4 min read
There's now a peer-reviewed name for the thing every founder notices the first week they start vibe coding: everything comes out looking the same. A March paper out of the University of Washington and Microsoft Research, "Interrogating Design Homogenization in Web Vibe Coding", walks the whole pipeline from prompt to deployed site and argues the sameness isn't an accident of any one tool. It's structural, and it shows up at every stage where the model gets to pick instead of you.
What the researchers actually found
The authors, Donghoon Shin, Alice Gao, Rock Yuren Pang, Jaewook Lee, Katharina Reinecke, and Emily Tseng, reviewed existing research plus a walkthrough of popular vibe coding tools, then ran a sociotechnical risk analysis adapting existing harm frameworks to the design pipeline. Their core claim is that vibe coding creates a direct line from a model's latent biases, the stuff baked into training data, straight to finished creative output, with nothing in between to interrupt it. They call the fix "productive friction": deliberate points where a non-expert has to make a real choice instead of letting the model default. Without that friction, speed wins and distinctiveness loses, every time.
Where the sameness actually creeps in
The paper breaks vibe coding into stages, from the first prompt through deployment, and the homogenization risk shows up at each one in a slightly different way:
- The prompt itself: "clean, modern, professional" means the same five or six things to every model, because those are the words every training example used.
- The scaffolding: most tools reach for the same component defaults (shadcn, Tailwind's default palette, Inter) because that's what's cheapest to generate correctly.
- The lack of a concrete target: without a real reference to match, the model fills the gap with its own average, which is the same average for everyone asking.
- No feedback loop: once the site looks "done enough," nothing in the workflow prompts you to check whether it looks like you or like everyone else who typed a similar prompt.
Friction is the diagnosis, a reference is the treatment
"Productive friction" is the right name for the problem, but it's abstract until you turn it into something you actually do differently. The friction that works in practice is simple: stop describing the look you want in adjectives, and start handing the model something concrete to match. A screenshot, a competitor's site, your own old site before the rebrand, whatever already carries the distinctiveness you're trying not to lose. The model doesn't need to be told what "modern and clean" means if it's working from your actual colors, your actual type scale, and your actual spacing instead of guessing at the category average.
A few tools are trying to make that one click
Pulling real values out of a reference used to mean opening DevTools and copying hex codes by hand. A handful of browser extensions now do a version of that automatically, with real tradeoffs worth knowing before you install one. Some stop at exporting raw CSS variables, which is a start but still leaves you to organize and name the tokens yourself before any AI tool can use them well.
Three ways to turn a reference into something a model can build from:
- PixelToToken: Chrome extension that pulls colors, type, and spacing off a live page or screenshot and exports to Figma, Tailwind, or CSS variables. Quick, but output is raw, unorganized values you still have to structure.
- Design Token Extractor: Similar one-click capture from any URL. Good for a fast palette check; doesn't produce the full W3C token format most AI coding tools read best.
- WAALEE: Extracts the full system, colors, type, spacing, as proper W3C design tokens, then turns it into ready prompts for Claude, Lovable, v0, Cursor, and Bolt in one pass.
None of this makes the paper's point go away. Even with a perfect reference, a model can still smooth your edges toward the average if you let it. But the friction that actually moves the needle isn't adding more steps to the workflow, it's adding the one step that matters: give the model a real target before it starts generating, not a paragraph of adjectives it has to interpret. That's the difference between a site that looks like yours and a site that looks like the fourth shadcn template someone shipped this week.