Every AI Tool Builds the Same React App

Ask v0 for a dashboard and you get Next.js, React and shadcn/ui. Ask Lovable for a prototype and you get React, Vite, TypeScript and Tailwind. Open Bolt.new, which genuinely supports several frameworks, and React is still what comes out by default.

Nobody voted on this. There was no RFC, no committee, no conference talk that settled it. But somewhere in the last two years the industry acquired a default frontend stack, and it was chosen by language models rather than by us.

Six tools, one answer

I noticed this on a freelance dashboard. I asked for a responsive layout without naming any libraries, and got back React with Tailwind and shadcn/ui components. I stopped fighting it, went with the grain, and had a working first draft in a couple of hours.

Then I started paying attention, and the pattern is everywhere. The major AI builders converge on close variants of the same stack, and they do it whether or not you ask.

The adoption numbers moved with it. Tailwind crossed 75 million monthly downloads in early 2026. shadcn/ui passed 100,000 GitHub stars in late 2025, making it the most-starred UI library on GitHub - which is remarkable for something that is technically not a library at all.

Why Tailwind specifically

The usual explanation is that Tailwind is simply better, and I do not think that is it. Plenty of good CSS approaches exist. What Tailwind has is a shape that suits how models write code.

Utility classes are deterministic and local. px-4 flex gap-2 means the same thing in every file, in every project, forever. There is no cascade to reason about, no naming scheme to infer, no separate file the model has to hold in its head. The styling lives inches from the markup it styles.

Then there is the training corpus. Tailwind has been publicly written more than any other modern styling approach, so models have simply seen more of it. Fluency compounds.

And when the model gets it wrong, the fix is a class diff you can eyeball in a pull request. Compare that to debugging a themed component library where the actual style is assembled from four layers of overrides.

Try asking for MUI or Chakra with deep custom theming. You will get there. It will take more nudges, and there are more places for the model to invent something plausible and wrong.

Why shadcn specifically

shadcn is the more interesting half, because it succeeded by not being a dependency.

You do not install shadcn components, you copy them into your project as plain JSX with Tailwind classes. For a human that is a trade-off: you own the code, and you own the maintenance.

For a model it is close to ideal. The component is right there in the repo, in the same idiom as everything else, with no abstraction layer between the request and the markup. The model reads it, edits it, ships it. No documentation lookup, no version-specific prop API, no black box.

A copy-paste distribution model turned out to be an AI-native distribution model, and I am fairly sure that was not the original plan.

What this actually buys you

I want to be fair to the outcome, because standardisation is not automatically bad.

When every tool emits the same patterns, the ecosystem develops shared debugging knowledge, shared customisation techniques, and shared answers. A junior developer hitting a problem now finds a solution written against roughly the code they have, rather than a close relative of it. Onboarding gets faster. Snippets port between projects.

The React component world has never really had a common baseline before. Now it approximately does. That has genuine value.

The part that should bother you

Here is my actual concern, and it is not about Tailwind.

A default arrived at because models are fluent in it is not the same as a default arrived at because it fits the problem. Those two things overlap most of the time, which is exactly what makes the gap easy to miss.

Fluency is a property of the training data, and training data reflects what was popular two years ago. So the feedback loop is: what was popular becomes what models suggest, what models suggest becomes what gets built, what gets built becomes the next training corpus. Popularity compounds into inevitability without anything having to be better.

That loop is very good at entrenching a decent choice and very bad at surfacing a better one. Whatever the right answer for 2028 is, it will have a smaller corpus than React and Tailwind, and it will therefore be suggested less, and therefore written less.

The practical version of this risk is smaller and more immediate: teams shipping a stack nobody on the team chose, and nobody on the team can fully explain. That is fine until the day it is not - a performance problem, an accessibility requirement, a design system that does not map onto utility classes.

When to go with it, and when not to

Go with the grain when speed is the point. Prototypes, internal tools, MVPs, anything where getting to a working draft this afternoon beats getting to the perfect architecture this month. The stack is genuinely good and the model velocity is real. Take the free lunch.

Push back when you have a constraint the default does not serve. A serious design system with heavy theming, strict bundle budgets, a non-React platform requirement, or an accessibility bar that needs real component primitives rather than copied markup. In those cases the AI-fluent path will fight you quietly the whole way, and you will not notice until the rewrite.

And in every case, make it a decision. "We chose React and Tailwind because it suits this problem and our team" is a fine sentence. "It is what came out" is not a technical strategy, even when the result happens to be the same.

The tools are good enough now that the danger is not bad code. It is architecture by autocomplete.

---

I help teams who inherited a stack rather than chose one - performance audits, architecture reviews, and the technical decisions that are hard to reverse later. More here.