AI builders keep choosing React before you do

v0 commonly produces dashboards with Next.js, using React components from shadcn/ui. Lovable's prototypes use React with Vite; TypeScript supplies the types, while Tailwind handles styling. Bolt.new supports several frameworks. Its default is React.

These defaults mean an AI builder can make the first framework decision before the developer has considered it. Repeated suggestions can turn that initial choice into the stack a team inherits.

The default in my dashboard project

I noticed the pattern while building a freelance dashboard. My request specified a responsive layout without naming libraries. The result used React with Tailwind styling on shadcn/ui components. I accepted the stack, then had a working first draft within a couple of hours.

After that project, I began noticing similar output from other AI builders. Requests that left the framework unspecified often produced closely related React stacks.

The surrounding adoption figures also grew. Tailwind exceeded 75 million monthly downloads in early 2026. In late 2025, shadcn/ui passed 100,000 GitHub stars, reaching the top of the UI-library rankings even though it distributes component source code.

Local styling is easy to inspect

Tailwind's structure offers one explanation for its frequent appearance. Its utility classes put much of a component's styling beside the markup, reducing the amount of separate CSS a model needs to inspect for that edit.

Classes like px-4 flex gap-2 specify spacing and layout in the same element. Their exact effect still depends on project configuration. Keeping them near the markup can reduce the need to infer a separate class-naming scheme or trace rules across files.

A large public collection of Tailwind code may also help models produce familiar patterns. Testing that explanation would require access to the model's training data.

A styling fix can then appear as a small class change in a pull request. Reviewing it may take less investigation than tracing a themed component through several layers of overrides.

MUI or Chakra can still fit a project with custom theming. That configuration gives an assistant more project-specific behavior to understand before it changes a component correctly.

Copied components expose the implementation

shadcn/ui distributes component source that developers can edit inside their own projects.

Copying JSX with Tailwind classes gives the team ownership of the implementation. It also gives the team responsibility for maintaining that copy.

The assistant can inspect the component in the repository before editing it. That reduces its dependence on a separate component API for understanding the markup. The local implementation still needs review against any dependencies it uses.

This distribution method happens to suit repository-aware editing. An assistant can modify the same component source a developer would read by hand, regardless of whether that was the original reason for distributing it this way.

Shared patterns reduce some setup work

Repeated defaults can help teams exchange fixes across projects.

When projects use similar component structures, developers can reuse debugging knowledge. A new teammate may find examples close to the code they're maintaining. Customization techniques can transfer too, reducing the amount of unfamiliar code they need to learn.

React projects using this combination have a recognizable starting point. That can make shared examples easier to apply.

Check the default against the project

My concern begins when the generated stack becomes the architecture without a separate decision.

A model's ability to generate a stack tells us something about its output. Choosing that stack for a project also requires checking it against the project's requirements. Familiarity can make that second step easy to skip.

There is a possible feedback loop: popular code gives models more examples, their suggestions produce more code in the same style, then some of that code may enter later training sets. That could reinforce an existing choice without establishing that it fits a particular application.

An alternative with fewer public examples may receive fewer suggestions even when it suits the work. The quality of a future approach cannot be inferred from how frequently today's builders generate it.

The immediate risk is a team inheriting decisions nobody can explain. A performance constraint may expose the problem later. Accessibility requirements or a design system with different styling assumptions can also force the team to revisit the stack.

Make the choice explicit

A prototype can justify using a familiar generated stack to reach a working draft quickly. Internal tools may have the same need, as can an MVP whose immediate purpose is to test an idea. The team still needs to understand what it accepted.

Specify constraints that could change the choice before generation begins. A non-React platform rules out the default directly. Heavy theming may favor a different component system; a bundle budget needs measurement. Accessibility requirements need inspection of the components' behavior, even when their markup looks familiar.

Record why the chosen stack fits the problem. If React with Tailwind suits the team, that is a reason the next maintainer can evaluate. The builder's first output alone leaves them without that explanation.

An assistant can produce a working draft before anyone has made an architectural decision. Someone on the team still needs to own that decision.

I help teams review inherited frontend stacks, assess their performance, then decide which architectural changes the application needs.