UI Libraries That Work With AI-Generated Apps
In short
For apps written mostly by an agent, the deciding factor is not how the components look — it is how much of the library the agent can read, and how recently its API changed. Three properties predict success: component source that lives in your repo instead of node_modules, an official docs channel the agent can query at runtime (an MCP server, an llms.txt, or a packaged skill), and an API that has not been rewritten in the last year.
By that measure shadcn/ui is the safest default for greenfield React work as of July 2026 — the code is yours, and it ships both an MCP server and an agent skill. MUI is the strongest choice when you need a real data grid, and it now ships its own MCP server, but v9 removed a pile of deprecated props that models still emit. daisyUI wins on token economy because it is class names only. Base UI is now shadcn's default primitive, but it renamed its npm package at 1.0 — so agents confidently write an import that no longer exists.
Why the library choice matters more with an agent
When you write UI by hand, a library's quality is mostly about ergonomics. When an agent writes it, the library becomes part of the agent's context budget and part of its error surface.
Three things change:
The agent's knowledge is frozen; the library is not. A model's weights encode whatever the docs said at training time. Every breaking release since then is a landmine. This is not theoretical — it is the single most common cause of "the code looks right and does not compile."
Component source is context. If the components live in node_modules, the agent cannot cheaply read them, so it works from memory. If they live in src/components/ui/, it can grep them, match your existing conventions, and edit them. That is a genuine difference in output quality, and it costs tokens.
Consistency is not free. An agent will happily produce four different button treatments across four sessions unless the library constrains it. A library with a small, opinionated surface acts as a guardrail.
What makes a library agent-friendly
Five criteria, in the order they actually bite:
- API stability. How many breaking majors in the last 18 months? Every one is a chance for the model to write obsolete code.
- A machine-readable docs channel. An MCP server or an
llms.txtlets the agent fetch the current API instead of guessing. - Source in your repo. Readable, greppable, editable by the agent — and reviewable by you in a normal diff.
- Styling expressed as text. Tailwind class strings are a single-line edit an agent gets right. A nested theme object spread across a provider is a diffuse edit it often gets half right.
- Setup that survives a fresh session. Providers, CSS imports, and font wiring that the agent must remember are exactly what it forgets on file six.
The libraries compared
Versions below are the current npm latest as of July 2026. Prices are as of July 2026.
| Library | Source in your repo | Official agent channel | Recent breaking churn | Best when |
|---|---|---|---|---|
| shadcn/ui (CLI 4.x) | Yes — CLI copies components in | MCP server + shadcn skill |
Default primitive switched Radix → Base UI, July 2026 | Greenfield React + Tailwind, custom design |
| MUI Material 9.x | No — npm dependency | Official @mui/mcp server + llms.txt |
v9, April 2026: deprecated props removed | Dense data UIs, enterprise, you need MUI X |
| Base UI 1.x | No — headless dependency | Docs site, no dedicated MCP | Package renamed at 1.0 | You are building your own design system |
| Radix Primitives 1.x | No | None official | Very low | Existing shadcn projects, stability first |
| Mantine 9.x | No | None official | Majors roughly yearly | Hooks + components in one, forms-heavy apps |
| Chakra UI 3.x | No | None official | v3 was a full rewrite | Teams already on Chakra |
| daisyUI 5.x | No — Tailwind plugin, zero JS | None official | v5 renamed several classes | Token economy, non-React stacks |
| Ant Design 6.x | No | None official | v6 shipped a new design language | Admin panels, Chinese-market products |
Two entries deserve a footnote.
MUI X. The reason to accept MUI's weight is usually the data grid. The Community tier is MIT-licensed with 40+ components; on MUI's own pricing page as of July 2026, Pro is $299 per developer per year and Premium is $599. If your agent scaffolds a Premium-only feature you have not licensed, you find out at the watermark, not at the compile step.
daisyUI. It is a Tailwind plugin, so a "component" is a class name like btn btn-primary. That is the cheapest possible thing for an agent to emit and the easiest for you to review. The cost is that there is no accessible behavior underneath — no focus management, no combobox logic. For anything beyond forms and layout you end up hand-rolling it or pairing daisyUI with a headless library.
Wiring one into a Claude Code or Cursor project
The point of this step is to stop the agent guessing. Two mechanisms do most of the work.
Give it a live docs channel. shadcn ships an MCP server that lets the agent list, search, and install components from any configured registry:
npx shadcn@latest mcp init --client claude
MUI's equivalent, per its official MCP docs:
claude mcp add mui-mcp -- npx -y @mui/mcp@latest
Both are stdio servers. MUI's docs note something worth repeating: you may need an explicit rule telling the client to actually use the MCP, otherwise the model answers from memory anyway. If the claude mcp list output confuses you, our walkthrough of connecting an MCP server covers the failure modes.
Pin the rules in a file the agent always reads. CLAUDE.md, or AGENTS.md for cross-tool projects, or .cursor/rules for Cursor. Four lines are enough to prevent most of the damage:
UI rules:
- Components come from shadcn/ui in src/components/ui/. Add with `npx shadcn@latest add <name>`.
- Never install @radix-ui/* or @base-ui/* directly. Never hand-write a component that already exists there.
- Tailwind v4: config is CSS-first in src/app.css. Do NOT create tailwind.config.js.
- Before using a component, read its file. Match its variant names.
The third line matters more than it looks. Tailwind v4 moved configuration into CSS via @import "tailwindcss" and dropped auto-detection of tailwind.config.js, and models trained on years of v3 tutorials reach for the JS config reflexively. The official upgrade guide lists the rest of the renames.
shadcn also publishes a packaged agent skill in its own repository that teaches the CLI flags, the registry workflow, and both primitive sets. If your tool supports skills, it is a better lever than another paragraph of prose in CLAUDE.md.
Where agents still get the markup wrong
Even with docs wired in, four failures repeat.
Imports from renamed packages. Base UI shipped 1.0 in December 2025 and moved from @base-ui-components/react to @base-ui/react. Agents write the old one constantly. The quick start shows the current form: import { Popover } from '@base-ui/react/popover'.
Removed props. MUI v9 dropped deprecated component and componentsProps props and the old Grid item / xs / sm API, per the v9 announcement. A model that learned Grid in the v5 era writes <Grid item xs={6}>, which is now just wrong.
Re-implementing what already exists. Ask for "a dropdown" in a shadcn project and there is a real chance the agent writes a fresh one with useState and a div instead of using components/ui/dropdown-menu.tsx. It compiles. It has no keyboard handling, no portal, no focus trap. This is the failure class covered in when the AI says it is done but it isn't.
Accessibility that looks fine. Agents produce div with onClick where a button belongs, and drop aria-label on icon-only controls. Headless libraries prevent this only for the components you actually use from them.
The practical countermeasure is boring: keep a short list of components that already exist, put it in your agent instructions, and run an accessibility linter in CI so the failure surfaces without a human reading the diff. Our Russian-language field notes on UI libraries for vibe coders go deeper on the day-to-day workflow.
FAQ
What is the best UI library for AI-generated apps?
For React with Tailwind, shadcn/ui — because the component source ends up in your repo where the agent can read and edit it, and because it ships both an MCP server and an agent skill. If you need a serious data grid, MUI is the pragmatic answer despite the heavier API. If you are not on React at all, daisyUI works anywhere Tailwind works.
Is shadcn/ui or MUI better for Claude Code?
shadcn/ui, in most cases, for one structural reason: Claude Code can grep your components/ui/ directory and match what is already there. With MUI it has to recall the API, and MUI v9 removed props that older training data still contains. MUI closes part of that gap with its official MCP server, which is worth installing if you use MUI.
Do I still need Radix if shadcn switched to Base UI?
No, and you also do not need to migrate. shadcn made Base UI the default for new installs in July 2026 and stated explicitly that Radix is not deprecated; existing projects keep working. New projects can still opt into Radix with shadcn init -b radix. Pick one per project and say which in your agent instructions — mixing both is what actually causes trouble.
How do I stop the agent from inventing its own components?
Three things, in order of effect: list the existing components in CLAUDE.md or AGENTS.md and tell it to read the file before using one; forbid direct installs of the underlying primitives; and review diffs for new files under components/. A new Dropdown.tsx next to an existing dropdown-menu.tsx is the tell.
Does a headless library like Base UI work well with agents?
It works, but it shifts the burden. Headless means the agent generates all the styling, so output varies more between sessions unless you give it a token scale and examples to copy. It is a good choice when you are building a design system on purpose, and a poor one when you want consistent screens fast.