AI prototyping with your design system: 4 ways

Axolo Design Manager, a design tool built on a team's own design system

You can prototype with AI on top of your design system in four ways today: put your tokens in the prompt, imitate the system with shadcn/ui, import your repository or component folder into a tool, or connect an agent to your components through a connector with usage rules. Each way gives the model a different share of your real system. This guide shows where each one breaks and what a team can check before choosing. Tool facts are dated October 2026 and link to the pages we read.

Axolo makes one of the tools in the fourth group, so we say where it fits and where it does not.

What does prototyping with your design system require?

A prototype counts as built on your design system when three things hold. Screens import your existing components instead of recreating them. Colors, type and spacing come from your tokens. The result runs in your target environment. These are the success criteria in a ChatPRD walkthrough on connecting a design system to an AI code editor. The same page names the usual failure: the model recreates a component with similar CSS. We use these three checks on each way below.

Way 1: paste tokens or a style guide into the prompt

This is the fastest start. You give the model your colors, fonts, radii and spacing as text, sometimes with a screenshot, and ask for a screen.

Vercel's team says in a 2025 post that you do not need a perfect system to begin, because models can infer a theme from screenshots or partial data. That matches what this way does well: look and feel.

Where it breaks: the model has your values and no component source. It writes buttons and cards from scratch, styled to match. The screen looks close, and none of it imports from your package. A developer then rebuilds it. If your goal is a quick visual direction, this is enough. If your goal is code that survives review, it fails the first of the three checks.

Way 2: imitate your system with shadcn/ui

Many AI tools start from shadcn/ui components by default. So some teams map their tokens onto a shadcn theme and build a small registry of branded components. Vercel's post recommends this path: start with tokens in a shadcn/ui theme, build blocks, then publish a registry that opens in v0 and connects to tools such as Cursor through MCP.

Where it breaks: the output matches the shadcn version of your system, not the system itself. v0's legacy registry guide states that v0 is trained on default shadcn implementations, so heavily customized primitives can give unexpected results. If your production library is not built on shadcn/ui, you maintain a second copy and keep the two in sync. Also note the source: the Vercel post promotes Vercel's own stack and says "we've seen this approach work" without data. The benefit is claimed, not measured.

As of October 2026, v0 labels that registry guide as legacy and points to a newer workflow, covered in the next section.

Way 3: import your repository or component folder

Here the tool reads your real code. Four examples, with what each source says as of October 2026:

v0 (Design Systems 2.0). You add sources such as GitHub repositories, Figma frames, Storybook links or ZIP archives. v0 saves the result as a skill that points to where your source lives. It asks for an installable package, and per its docs it will not use components, props or tokens it cannot verify from the sources. Existing chats keep the version of the skill they were built with. Source.
Lovable. A design system is its own project. You bring a React library from an npm package, a public Git repository or uploaded files, then release a version. Generations are scanned for raw colors, one-off styles and local copies of design system components, and Lovable retries when it finds them. Limits: one design system per project, React only today, and wrapping an existing npm package needs an Enterprise plan. Source.
Builder.io. Its index-repo command maps components, tokens and icon libraries to your code. Builder states that automated discovery typically reaches 70% mapping accuracy, and the command needs an Enterprise plan. Source.
UXPin Merge. It imports React components from Git, Storybook or npm into a design canvas. UXPin says it works only with JavaScript libraries and frameworks, and that Git has the most features. The post we read does not describe AI features in Merge. Source.

Where this way is stronger than the first two: the tool sees your component names, props and tokens, so the first check (importing existing components) becomes possible. Lovable's automatic scan for local copies is a good example of a built-in guardrail.

Where it breaks: the result depends on how readable your repository is. A 70% mapping rate means roughly three in ten components may need manual mapping or may be misused. Updates are another weak point, since a library change does not always reach prototypes already generated. And a component that does not exist yet has no good outcome: the tool either invents one or stops.

Way 4: connect an agent to your components with usage rules

In this way the agent queries your system while it works. The ChatPRD walkthrough describes a component server the editor can ask about available components and their correct usage, plus custom rules telling the editor when to use them. Storybook's MCP server works along similar lines: its docs toolset lists documented components and shows props and examples from a components manifest.

Where it breaks: setup and upkeep sit with your team. Storybook labels its AI capabilities a preview that may change, and the manifest is available for React frameworks and Angular with Vite, with other frameworks unsupported for the docs toolset. A rules file is text the agent reads. The sources above do not describe a server-side check on what the agent writes, so you still review every output. For why on-demand loading of the system matters, see our write-up of Atlassian's measurement; for the rules themselves, see three rules against hallucinated components.

Where Axolo fits

Per the Axolo Design Manager page, the product is in private beta with a waitlist. Teams and AI agents work on one canvas with your components and rules. Agents build only with your components and tokens, and each change is a typed operation checked by the server. Four freedom levels (Strict, Guided, Exploratory, Free) are set per prompt and per branch. In Strict, a missing component becomes a request for developers, and library changes go out as pull requests reviewed in GitHub. You can also connect Claude, Cursor or another MCP client instead of the built-in agent.

Axolo is not the right choice in several cases, based on that page:

You have no component library in code, and you do not want to start from the ready-made Axolo UI library or build one from Figma variables.
Your stack is Vue or Angular. React and Web Components are supported today, and the others are listed as next.
Your code lives on GitLab. Only GitHub is listed today, with GitLab, npm, Storybook and EU hosting marked as coming soon.
You want to keep editing the design system in Figma. In Axolo the system is edited in Axolo, with Figma variables imported to get started.
You need a public price. Pricing is shared with the waitlist, and the built-in agent has a monthly cap per workspace.

How do the four ways compare?

Summary of the sources above, as of October 2026.
Way	What the model gets	Where it breaks	Check first
1. Tokens in the prompt	Your values as text or screenshots	Lookalike components, no imports	Does any generated file import from your package?
2. shadcn/ui imitation	A shadcn theme and registry built from your tokens	A second copy of your system; customized primitives	How far is your library from default shadcn?
3. Repository import	Your component code, props and tokens	Mapping gaps, updates, missing components	Which frameworks, hosts and plans are supported?
4. Connector with rules	Live answers about components and their usage	Setup upkeep, preview-stage tools, unchecked output	What happens when a component is missing?

What should a team check before choosing?

Run the same test on every candidate. Pick one real screen from your product and ask each tool to build it. Then check:

Does the generated code import your components, or does it contain lookalikes?
Do colors, type and spacing come from tokens, or from raw values?
What happens when the screen needs a component you do not have? Does the tool invent one, stop, or file a request?
Which frameworks and code hosts does it support today, and which are only announced?
When your library changes, do existing prototypes update, and who decides?
Can a developer review the change as a pull request?
Which plan do you need for the feature you tested?

If a tool passes the first three, it is a candidate for production-bound work. If it fails them, it may still serve for early exploration. For a readiness check of the system itself, see readable by humans, silent to an LLM.

Frequently asked questions

Can ChatGPT or Claude prototype with my design system?

Any chat model can start with way 1. To reuse your real components, you need way 3 or way 4, because the model must see your component code or query it.

Do I need shadcn/ui to use my design system with AI?

No. v0's newer workflow asks for an installable package, and Lovable supports React component libraries. shadcn/ui matters mostly for way 2.

Is the v0 shadcn registry still the way to connect a design system?

As of October 2026, v0's documentation calls the registry guide legacy and describes Design Systems 2.0 as the current workflow.

Can a product manager prototype without breaking the design system?

It depends on what the tool allows. Look for a mode that restricts output to your components and tokens, as Axolo's Strict level does, and check imports in the generated code.

AI prototyping with your design system: four ways to try it today