Aestheria vs shadcn/ui
shadcn/ui hands your agent components. Aestheria, the design context layer, hands it the decisions: which component this surface takes, what it looks like as your product, and whether the result followed. Different layers, and they stack.
The copy-in model was the right idea.
shadcn/ui changed how teams think about component libraries: you copy the component into your repository, so you own it, can edit it, and are never blocked by a maintainer. That model is correct, and Aestheria ships on the same premise. The kit is yours down to the token.
Its MCP server extends the same idea to agents, which is why an editor can now search a registry and install a component by name. Both of those are solved. What neither settles is the layer above the component.
The decisions a component does not contain.
Which of these four surfaces is a card and which is a table. What your product's border grey is, as opposed to the default. Whether this destructive action needs a confirm step, and which states this screen owes its user before it can ship. An agent generating your tenth screen makes those calls every time, and a registry of well-built components has no opinion on any of them.
That is also why so much AI-generated UI is recognisable on sight. A tool with no other reference generates the reference everyone shares, and the default becomes the visual language of your product by accident rather than by decision.
They stack.
Aestheria is plain CSS custom properties and classes, with no framework runtime, so it sits alongside a Tailwind and shadcn setup rather than replacing it. Teams commonly keep their primitives and point the tokens, patterns, and rules at Aestheria, so the components stay familiar and the product stops reading as the default.
| shadcn/ui | Aestheria | |
|---|---|---|
| What an agent gets | Components, registries, installs | The decisions that pick and shape them |
| Ownership | Yours, copied into the repo | Yours, editable down to the token |
| Theming | CSS variables you configure | 6 themes in light and dark, 405 tokens named by purpose |
| Usage rules | Docs and examples | Attached to each token and component, machine-readable |
| Pages | Blocks and examples | 63 page templates, each a working screen |
| Judgment | Your team supplies it | Six editable skills, loaded per task |
| Verification | Review, by a person | validate_snippet returns the specific violations |
- 405 tokens
- 6 themes
- 37 components
- 27 charts
- 63 templates
Questions
Do I have to replace shadcn/ui?
No. Aestheria is plain CSS tokens and classes with no framework runtime, so it layers over an existing Tailwind and shadcn setup. Keep your primitives and give them your product's decisions.
Why does AI-generated UI look the same across products?
Because every tool generates against the same defaults when it has no other reference. Supplying your own tokens, patterns, and rules is what makes the output resolve to your product instead of the shared baseline.
Is Aestheria a component library?
It ships one, and that is the starting point rather than the product. The library is 37 components with their states; the layer is the tokens, patterns, templates, and judgment that decide how they get used.
Which one should I start with?
If you have no system at all, start with Aestheria, because it ships complete and you edit it into your product. If you already run shadcn, keep it and add the layer above it.