Field note · 2026 tooling

Design system tooling in 2026.

Storybook vs Ladle vs Histoire. Tokens Studio vs Figma Variables. Zeroheight vs Supernova vs DIY. Cursor vs Claude Code vs v0. The Reddit favorites, treated as a real decision. Six categories, six concrete picks, the anti-patterns to avoid, and the shifts since 2023 that changed every answer.

Going AI-native? See the MCP + agent pipeline deep-dive.

01 / The TL;DR

Six picks. six things to skip.

If you came for the answer and don’t want the reasoning, here it is. Six categories that cover the tooling decisions every design system makes — what to pick, and what to specifically avoid.

The full sections below explain why. The anti-recommendations are doing as much work as the recommendations: most teams ship with the wrong choice in 1-2 categories because the wrong choice looks reasonable at the time.

CategoryPickSkip

Component docs
PickLadle (new builds) · Storybook (existing)
SkipStorybook for greenfield · React Cosmos · Add-on jungles
Tokens
PickTokens Studio + GitHub sync · Style Dictionary · W3C format
SkipFigma Variables w/o Enterprise · proprietary token formats
Docs hosting
PickDIY (Next.js / Astro / Fumadocs)
SkipZeroheight if you can DIY · Notion · GitHub Wiki
Component distribution
PickRegistry endpoint (shadcn-style) · Internal npm if mature
SkipCopy-paste from Storybook · mixed distribution models
Figma ↔ code
PickFigma Dev Mode + Code Connect
SkipBuilder.io for system components · custom plugins
AI coding tools
PickClaude Code · Cursor · v0 (for prototyping)
SkipSingle-tool lock-in · inline-only completion · custom in-house AI

02 / Six categories

Each category, the options ranked, the recommendation, why.

Each section ranks the realistic options (Pick · Solid · Skip), names the recommendation, walks through the reasoning, and flags what to specifically avoid. The Solid options aren’t bad — they’re the second-best answer for most teams, or the right answer for an edge case.

Component documentation

Where do your components get explored, demoed, and reviewed?

OptionVerdictNote

Storybook
Solid
Industry default. Heavy, slow to set up, but the integration surface area is unmatched.
Ladle
Pick
Vite-native, ~10× faster start-up. Story-format compatible with Storybook. Default for new builds.
Histoire
Solid
Vue-first; the best option if you're not in React. Also handles Svelte.
DIY (Next/Astro + MDX)
Solid
If your docs site is already in Next or Astro, a custom <ComponentPreview> primitive beats any add-on jungle.
React Cosmos
Skip
Solid but momentum has stalled. Storybook absorbed the niche.

Recommendation

Ladle for new builds. Storybook only if you already have it and the migration cost outweighs the velocity gain.

Why this

Ladle starts in <1 second on a typical component library. Storybook takes 8–20. That delta compounds across every developer's day.
Ladle uses Vite directly — no parallel bundler config, no add-on dependency tree, no version-pinning chess.
Story format is shared: stories you write today work in both. Migration risk is low.

Specifically avoid

Storybook for greenfield. The setup tax is real and the velocity advantage of Ladle is real.
Storybook 6 → 8 mid-migration. Cumulative API churn has burned more teams than the feature gains justify.
Add-on jungles. If you're installing 12 Storybook add-ons, you're paying for complexity that a custom MDX preview avoids.

Design tokens

Where do tokens live, and how do they get from Figma to code?

OptionVerdictNote

Tokens Studio + GitHub sync
Pick
The default in 2026. Designers edit in Figma; tokens land in the repo via PR.
Figma Variables (Enterprise)
Solid
Native. Has a REST API for code-sync — but the API is Enterprise-only.
Figma Variables (non-Enterprise)
Skip
Without the API, you're back to manual export. Don't commit to a workflow you can't automate.
Style Dictionary
Pick
The transformer. Reads .tokens.json (any source), writes CSS / iOS / Android. Pair with whichever editor you pick.
W3C raw + custom pipeline
Solid
If you have one full-time DS engineer, this is the cleanest. Otherwise overkill.

Recommendation

Tokens Studio + GitHub for editing. Style Dictionary for transformation. W3C-spec .tokens.json as the canonical format.

Why this

Designers stay in Figma. Tokens land in the repo as W3C JSON. CI runs Style Dictionary and emits CSS / iOS / Android.
W3C-spec format means you can swap any layer of the pipeline without rewriting your token catalog.
GitHub PRs become the design-review surface — every token change is reviewable like code.

Specifically avoid

Committing to Figma Variables without the Enterprise plan. Manual export is not a workflow.
Style Dictionary as a single source of truth. Use it as a transformer; keep the raw tokens in W3C format.
Proprietary token formats (Zeroheight, Supernova internal schemas). They lock you in; W3C doesn't.

Docs hosting

Where does the design-system site itself live?

OptionVerdictNote

DIY (Next.js / Astro / Fumadocs)
Pick
Lower long-term cost than any SaaS. You own the design. Migrate-out cost: zero.
Zeroheight
Solid
Strong if your team is design-heavy and the docs are the artifact. Pricey ($1.5–6k/yr typical) and proprietary.
Supernova
Solid
Better dev integration than Zeroheight. Same proprietary trade-off.
Knapsack
Solid
Strongest cross-platform docs (iOS / Android / web side-by-side). Niche but real value.
GitHub Wiki / Notion
Skip
What teams do before they admit they need real docs. Stop here at your peril.

Recommendation

DIY. Almost always. The compounding wins on customization, integration, and migrate-out cost beat any SaaS on a 3-year horizon.

Why this

DIY docs sites take 1–2 weeks to set up in Next.js or Astro. Zeroheight takes 6 weeks to configure to your brand and ~6 weeks more to integrate with code.
Owning the docs site means you can ship custom features (interactive demos, MCP buttons, AI Q&A) that proprietary platforms won't build for you.
When the SaaS pricing changes or the company gets acquired, your docs aren't held hostage.

Specifically avoid

Zeroheight if your engineers can stand up an MDX site in a week. The SaaS only wins when your team genuinely can't.
Multi-tenant SaaS for systems that have proprietary IP in the docs (component decisions, internal patterns). Self-hosted is the only defensible position.
Notion or GitHub Wiki as long-term docs. Both kill discoverability and search; both burn trust within a year.

Component distribution

How do other teams install your components?

OptionVerdictNote

shadcn-style registry endpoint
Pick
Components ship as JSON; consumers pull them into their repo. No version-pinning hell.
Internal npm registry
Solid
The traditional path. Works at scale but requires versioning discipline (semver, codemods, deprecation timelines).
Monorepo workspace (pnpm/turbo)
Solid
Best for orgs with full code-sharing. Worst for orgs that want isolation between product teams.
Public npm package
Solid
For open-source systems. Adoption-friendly but governance-difficult.
Copy-paste from Storybook
Skip
Looks like distribution. Isn't. Drift starts immediately.

Recommendation

Registry endpoint for new builds. Internal npm if you're already there and the discipline is mature.

Why this

Registry-style distribution (shadcn pattern) ships TSX into the consumer's repo. They modify it freely; you push updates as suggestions, not forced upgrades.
No version-pinning means no “we're stuck on v2.4 because v3 breaks the modal” conversations.
Type-checked at the consumer end. Drift surfaces as a type error, not a runtime bug.

Specifically avoid

Public npm + private SemVer enforcement. Pick one model; mixing them creates the worst of both.
Multiple distribution mechanisms for the same components. One way in, or governance becomes impossible.
Linking via npm link / workspace symlinks in production. Fine for dev; never in CI.

Figma ↔ code bridge

How do design intent and code stay in sync?

OptionVerdictNote

Figma Dev Mode + Code Connect
Pick
Native. Free with Figma Pro. Maps your Figma components to your code components by name + props.
Anima
Solid
Stronger code generation than Dev Mode for non-system surfaces (marketing, one-offs). Worse for systematic work.
Builder.io
Solid
Generates working code from a Figma frame. Best for marketing pages, not design-system components.
Manual pairing (designers + engineers sync weekly)
Solid
Sometimes the right answer. Tools fail when the team practice fails.
Custom Figma plugin
Skip
The siren song. Six months in, you're maintaining a tool nobody else uses.

Recommendation

Figma Dev Mode + Code Connect. Add Anima or Builder.io only for the marketing surface, where bespoke code generation has more upside.

Why this

Code Connect is the only tool that gets the design-system case right: it doesn't generate code; it maps Figma components to existing code components.
Free with Figma Pro. No vendor risk. Maintained by Figma directly.
When the design changes, Dev Mode shows the diff to the developer. When the code changes, Code Connect requires updating the mapping — keeping the two layers honest.

Specifically avoid

Builder.io for system components. It generates fresh code every time; you want to use existing components, not generate new ones.
Anything that auto-generates components from Figma into production. The component library is curated; auto-generation creates the duplication problem you built the system to solve.
Building your own Figma plugin unless you have a full-time designer who wants to maintain it.

AI coding tools

Which AI coding assistant should consume your design system?

OptionVerdictNote

Claude Code (Anthropic)
Pick
MCP-native. Strongest multi-file reasoning. Best for systematic refactors and following your DS conventions across hundreds of files.
Cursor
Pick
MCP-capable, best Tab completion in the category, mature codebase indexing. The editor most teams default to.
v0 (Vercel)
Pick
Browser-based UI generator. Native shadcn/Tailwind ecosystem. Best for prototyping new screens — point it at your registry endpoint.
Cline
Solid
Open-source MCP-capable agent inside VS Code. Free, self-hostable model choice. Less polished UX than Cursor / Claude Code.
Lovable
Solid
Rising browser-based generator with full-stack scaffolding. Strong for greenfield projects; weaker for editing existing DS-consuming codebases.
OpenAI Codex CLI
Solid
Terminal-first. Useful for batch operations on a repo. Less interactive than Cursor / Claude Code; not where most design-system work happens.
GitHub Copilot
Solid
Ubiquitous inline completion. No MCP. Will autocomplete from any pattern in your codebase — including the bad ones you're trying to deprecate.
Windsurf
Solid
Cursor-shaped alternative from Codeium. Same workflow, smaller mindshare. Reasonable second-choice if Cursor's pricing breaks for you.
Aider
Solid
Terminal-based, git-native, batch-refactor friendly. Excellent for migrations; not for interactive design work.
Custom in-house AI
Skip
Don't build your own. The base-model and tooling ecosystem moves on a 3-month cycle; whatever you build will be obsolete before it ships.

Recommendation

Claude Code + Cursor for repo work. v0 for browser-based UI prototyping. All three benefit dramatically from a well-built MCP server (see /ai-ready/mcp).

Why this

The MCP-capable tools (Claude Code, Cursor, Cline) compound with the AI-ready hub investment. Without MCP, the agent guesses your tokens; with it, the agent queries the right answer at edit time.
Different tools win at different jobs. Cursor: inline edits + Tab. Claude Code: multi-file reasoning + refactors. v0: greenfield UI generation. Most serious teams run 2-3 of these in parallel.
The space moves fast (3-6 month cycles). Don't lock in to one tool; treat them as commodity consumers of your design system's MCP / registry interfaces.
OpenAI's Codex CLI and Anthropic's Claude Code both ship as installable CLIs and pair well with terminal-driven workflows. If a team is split between editor-resident (Cursor / Cline) and terminal-resident (Codex / Claude Code), that's healthy.

Specifically avoid

Locking in to a single AI tool. The leader changed three times in 24 months; treat the agent layer as commodity.
Inline-only completion (Copilot vintage) for design-system work. Without MCP it has no way to know which tokens or components exist — it pattern-matches what's already in the file.
Custom in-house AI integrations until the ecosystem stabilizes. Use MCP, which every major agent supports, instead of building tool-specific plugins.
Treating browser generators (v0, Lovable, Figma Make) as production code generators. They're prototyping tools; the output lands in a repo where Cursor or Claude Code refactors it into your system.

03 / What changed since 2023

Seven shifts that moved every category.

The 2026 picks aren’t the 2022 picks. Here’s what shifted underneath each category — bundler choice, distribution shape, token formats, the new Figma↔code workflow, and the AI coding tools that became a daily-driver category in their own right. If your tooling decisions were made in 2022, this is your audit list.

01
Vite ate Webpack
By 2024, Vite was the default bundler for new React / Vue / Svelte projects. That cascaded into the tooling layer: Ladle (Vite-native) became viable competition for Storybook (Webpack-default), and component docs that take 8 seconds to hot-reload feel two generations old.
02
shadcn changed distribution
The shipped-into-your-repo model proved out across hundreds of thousands of installs. Registry endpoints — components served as JSON, installed via npx — are now the dominant distribution shape for new design systems. npm packages still ship, but the curve has bent.
03
W3C tokens stabilized
The W3C Design Tokens Community Group spec hit useful maturity in 2024. Tokens Studio, Figma, Style Dictionary, and most modern tools now read and write it. Proprietary token formats are a legacy choice.
04
Figma Variables shipped but stayed paywalled
The API for code-sync — what would have made Figma Variables a real Tokens Studio alternative — stayed behind the Enterprise plan. For most teams, Tokens Studio + GitHub remained the better choice through 2025-26.
05
AI coding tools rewarded code-first systems
Cursor, Claude Code, v0, Lovable can read TSX. They can't read Figma. Systems where the source of truth is in the repo (shadcn, registry-style) shipped 2-3x faster with AI assistance than systems gated behind Storybook URLs or proprietary docs.
06
Code Connect went GA
Figma Code Connect went generally available in late 2024. For the first time, mapping Figma components to existing code components became a first-class workflow — not a custom-plugin science project. The Figma↔code bridge category got an honest default.
07
AI coding tools became a tooling category
Through 2025, Claude Code, Cursor, Cline, Codex CLI, and v0 all became serious daily-driver tools for production work. MCP — Anthropic's Model Context Protocol — emerged as the shared interface every major editor adopted. The 'AI coding tools' category is no longer optional in a 2026 tooling stack; treating it as such is how teams get out-shipped by competitors who didn't.

04 / What I’d actually do

The opinionated stack.

If you put me in a room with a director who has to make this decision today, here’s the stack. It’s the same one used by the teams I’ve watched ship the smoothest in 2025–26. Boring on purpose — every line is a deliberate “not the trendy choice, the durable one.”

Component docs: Ladle
1-second startup, story-format compatible, no add-on tax. If you already have Storybook in production, leave it — but don’t start there in 2026.
Tokens: Tokens Studio + Style Dictionary + W3C format
Designers edit in Figma; tokens land in the repo as W3C JSON; CI emits CSS / iOS / Android. Token Studio handles the design side; Style Dictionary handles the transformation; W3C format keeps you portable.
Docs site: Next.js / Astro with MDX
Custom <ComponentPreview> primitive. Interactive demos inline. AI Q&A. MCP buttons. No SaaS can ship the features you actually want; ship them yourself.
Distribution: Registry endpoint (shadcn-style)
Components ship as JSON. Consumers npx shadcn add them into their repos. No version-pinning, no forced upgrades, no escape-hatch forks.
Figma ↔ code: Dev Mode + Code Connect
Native, free with Pro, maintained by Figma. Map your components once; let Code Connect surface the right snippet in Dev Mode every time a designer opens it.
AI agents: Claude Code + Cursor + v0
Repo work in Claude Code (multi-file refactors) and Cursor (inline edits + Tab). New-screen prototyping in v0. All three point at the same MCP server you ship alongside your registry. Treat the agent layer as commodity — the leader changes every six months.
AI integration: MCP server
Ship a Model Context Protocol server alongside the registry. Any MCP-capable agent (Claude Code, Cursor, Cline, Codex CLI) can query your tokens, components, and patterns at edit time instead of hallucinating them. The 2026 hard requirement.

Total bill: $0/month in proprietary tooling. Everything above is either open-source or included with Figma Pro. The cost is in the team — and that’s where it should be.

Tooling is downstream of two earlier decisions.

Which base library you build on, and how AI-ready you make the result, drive most of these tooling picks. The pair of pieces that come before this one set the constraints; this piece names the tools that satisfy them.

Which design system to build on Make yours AI-ready Why adoption stalls

AI coding tools

Which AI coding assistant should consume your design system?

OptionVerdictNote

Claude Code (Anthropic)
Pick
MCP-native. Strongest multi-file reasoning. Best for systematic refactors and following your DS conventions across hundreds of files.
Cursor
Pick
MCP-capable, best Tab completion in the category, mature codebase indexing. The editor most teams default to.
v0 (Vercel)
Pick
Browser-based UI generator. Native shadcn/Tailwind ecosystem. Best for prototyping new screens — point it at your registry endpoint.
Cline
Solid
Open-source MCP-capable agent inside VS Code. Free, self-hostable model choice. Less polished UX than Cursor / Claude Code.
Lovable
Solid
Rising browser-based generator with full-stack scaffolding. Strong for greenfield projects; weaker for editing existing DS-consuming codebases.
OpenAI Codex CLI
Solid
Terminal-first. Useful for batch operations on a repo. Less interactive than Cursor / Claude Code; not where most design-system work happens.
GitHub Copilot
Solid
Ubiquitous inline completion. No MCP. Will autocomplete from any pattern in your codebase — including the bad ones you're trying to deprecate.
Windsurf
Solid
Cursor-shaped alternative from Codeium. Same workflow, smaller mindshare. Reasonable second-choice if Cursor's pricing breaks for you.
Aider
Solid
Terminal-based, git-native, batch-refactor friendly. Excellent for migrations; not for interactive design work.
Custom in-house AI
Skip
Don't build your own. The base-model and tooling ecosystem moves on a 3-month cycle; whatever you build will be obsolete before it ships.

Recommendation

Claude Code + Cursor for repo work. v0 for browser-based UI prototyping. All three benefit dramatically from a well-built MCP server (see /ai-ready/mcp).

Why this

The MCP-capable tools (Claude Code, Cursor, Cline) compound with the AI-ready hub investment. Without MCP, the agent guesses your tokens; with it, the agent queries the right answer at edit time.
Different tools win at different jobs. Cursor: inline edits + Tab. Claude Code: multi-file reasoning + refactors. v0: greenfield UI generation. Most serious teams run 2-3 of these in parallel.
The space moves fast (3-6 month cycles). Don't lock in to one tool; treat them as commodity consumers of your design system's MCP / registry interfaces.
OpenAI's Codex CLI and Anthropic's Claude Code both ship as installable CLIs and pair well with terminal-driven workflows. If a team is split between editor-resident (Cursor / Cline) and terminal-resident (Codex / Claude Code), that's healthy.

Specifically avoid

Locking in to a single AI tool. The leader changed three times in 24 months; treat the agent layer as commodity.
Inline-only completion (Copilot vintage) for design-system work. Without MCP it has no way to know which tokens or components exist — it pattern-matches what's already in the file.
Custom in-house AI integrations until the ecosystem stabilizes. Use MCP, which every major agent supports, instead of building tool-specific plugins.
Treating browser generators (v0, Lovable, Figma Make) as production code generators. They're prototyping tools; the output lands in a repo where Cursor or Claude Code refactors it into your system.