v0 is very good at the first version of a screen and, by design, has no memory of your design system. That is not a criticism: generating a plausible layout from a sentence is the product, and it is genuinely the fastest way from nothing to something you can react to.
The mistake is treating that output as the destination rather than as the sketch.
What generation is good at
Exploring shapes. Four versions of a settings screen in ten minutes is faster than any other method, and looking at four is how you find out what you actually wanted.
Filling a blank page. The hardest part of a new screen is the first arrangement. Generation removes it.
Throwaway surfaces. An internal tool, a demo, a one-off page nobody will maintain. Generated output is fine there, and refining it further is wasted effort.
What it is not good at
Your components. It writes from its own vocabulary. Anything generated is a new component, and in an existing codebase that is a duplicate rather than a contribution, which the duplication guide covers.
The states beyond the happy path. Loading, empty, error and permission are almost never in generated output, and the review checklist lists what else is usually missing.
Consistency across screens. Each generation makes its own choices about spacing and radii, so three generated screens are three near-misses of the same design.
The workflow that works
Generate, then replace. Concretely:
Generate the layout, keep the structure and the arrangement, and throw away the components. Then bring in the real ones - from your own registry if you have one, from a catalogue if not - so the screen ends up with your button, your card and your tokens inside a layout you did not have to invent.
That split works because the two halves have different economics. Arrangement is cheap to generate and expensive to think about from scratch. Components are cheap to install and expensive to duplicate.
Bringing the real components in
Two routes, depending on where you are.
In the editor. Connect a catalogue through MCP and ask the agent to replace the generated primitives with real ones. This is where an agent is genuinely good: mechanical substitution across a file with the imports handled.
By hand. npx shadcn add for each real component, then a pass replacing the generated ones. Slower and completely predictable.
Either way the last step is the same: normalise the tokens, so the screen uses your radius, your spacing and your colours rather than the generator's defaults. Doing that while the file is fresh takes minutes, as the customisation guide argues.
What to keep from the generated version
Usually three things: the layout, the responsive breakpoints, and the copy structure. Usually none of the components, none of the colours and none of the spacing values.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| v0 and similar builders | The first arrangement, fast | Its components, not yours |
| 21st MCP | Replacing generated primitives with real ones | Installs need a membership |
| Templates | A whole coherent app rather than one screen | Someone else's structure |
| A team registry | Your components in the substitution step | Somebody has to publish them |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- Should generated UI go straight into production?
- For throwaway surfaces, yes. For anything maintained, treat it as a sketch: keep the layout and the responsive breakpoints, replace the components with real ones, and normalise the tokens. The two halves have different economics, which is why the split works.
- What is generated UI genuinely good at?
- Exploring shapes, since four versions of a screen in ten minutes is how you find out what you wanted, and filling a blank page, since the first arrangement is the hardest part of a new screen. Both are about arrangement rather than about components.
- What does generated output usually miss?
- The states beyond the happy path, consistency between screens, and any connection to components you already own. Each generation makes its own spacing and radius decisions, so three generated screens are three near-misses of the same design.
- How do you replace generated components efficiently?
- In the editor with a catalogue connected through MCP, asking the agent to substitute real components for the generated primitives, which is mechanical work it does well. Or by hand with the shadcn CLI. Either way, finish by normalising radius, spacing and colour to your tokens while the files are fresh.