What Is An AI-Native Design System?
Fantasy built one for Eliza, BNY's enterprise AI platform. The brand's design team now ships production code from their IDE.
What is an AI-native design system?
An AI-native design system treats a machine as its primary user. Design tokens exist as code, components are built to production quality, and documentation is written for AI coding tools to read and apply. That combination lets an AI generate interface code that matches the system on the first pass.
Traditional design systems serve as reference material for people: a Figma library with usage guidelines, interpreted by hand. AI-native systems serve as the source material AI tools build from directly. That directness closes the gap between designing an interface and shipping one.
Why do static design systems break down in AI-assisted development?
Static design systems were built for a handoff that AI-assisted development skips. The old pipeline ran design file to spec to engineer to rebuild, and every step introduced drift: components that almost match, tokens applied from memory, while the documentation trails further behind the code every sprint.
AI coding tools make the problem sharper. Given a screenshot and a vague instruction, they generate something that looks close and matches nothing. The discipline has to come from the source material: when the rules exist as machine-readable code, the tool applies them directly, with nothing left to guess.
We saw the difference directly before BNY. Fantasy tested whether a well-structured Figma design system could drive AI component generation on another client's system, extracting tokens and components into a machine-readable file and prompting from it. The output worked, and it was responsive, but it read as vibe-coded rather than production craft.
The lesson: build the system for AI first, then ask AI to build from it.
How Fantasy built one for BNY's Eliza platform
Eliza is BNY's internal AI platform, the one OpenAI featured in its own customer story and Fortune has covered. The brand reports that 20,000 employees actively build AI agents on it, across more than 125 live use cases.
Fantasy shaped Eliza's future vision, then delivered the design system behind the platform: an AI-native system in Angular with a three-layer token architecture and a library of more than 60 production-ready components, every one of them documented for AI code generation instead of a handoff deck.
Around the system, Fantasy built a git-native way of working: instruction files that encode the design system's knowledge for AI coding tools, versioned in the repo alongside the code they govern. BNY's design team moved into their development environment and now ships production code directly.
The system changed how the bank's own designers work day to day.
What does a three-layer token architecture do?
Tokens are the smallest decisions in the system: color, type, spacing. A three-layer architecture resolves them in stages: primitive values at the base (the palette, the type scale), semantic tokens in the middle (what a color means: surface, warning, emphasis), and component tokens at the top (what this button uses).
The layering is what lets the system scale without fragmenting. A rebrand changes the base layer and cascades cleanly. A new component composes from the semantic layer instead of inventing values. And because every layer is code, an AI tool resolving "the primary action color" gets one answer, every time, instead of sampling a pixel and guessing.
How do you document components for AI code generation?
Write the documentation for the reader that will actually build with it. Each of Eliza's 60+ components carries its purpose, props, states, and correct-usage examples in a form an AI coding tool can parse and apply. If a constraint matters, it lives in the repo as text a machine can read, instead of surviving as tribal knowledge in a designer's head or a wiki nobody updates.
The repo becomes the single source of truth for design and engineering, with history tracked and conventions versioned like any other code. Fantasy has since productized this model into an internal toolchain that handles both remediation of existing design systems and greenfield builds.
The repo's so well structured, the history's so well tracked, everything's so well documented. I have had almost zero issue to date when I've pulled it to come through to do something or to learn something or iterate something or try to use it.
What changes when designers work IDE-native?
The design team's output becomes software itself. Working on the coded system, BNY's designers build fully functioning prototypes directly in the development environment, on the system's components and tokens, at production performance. Multiple prototypes responding to codified research run in parallel to test competing ideas at once.
BNY's design team went entirely IDE-native on the foundation Fantasy delivered, and the bank's engineering team builds on the same system. The scale is on the record: BNY's own engineers, writing Angular themselves, have shipped more than 600 production deployments across 14 micro-frontends built on the system, with a bench of 25+ active frontend contributors. Design and engineering now share one medium; the handoff negotiation is gone.
Weeks went by without anyone opening a design file. The product's craft didn't suffer, because the craft lives in the system.
The results BNY reports on Eliza follow from that foundation: client-plan preparation time down 60%, contract review handled in one hour instead of four.
How do you build one? Start here.
Start with the token architecture: primitives, then semantics, then component tokens, in code from day one. Build in the client's production stack. Take a small set of components to production quality before scaling the library, and write the documentation and instruction files for machine consumption as you go. Then pilot with one designer shipping one working prototype from the IDE; the workflow change is the product.
An AI-native design system gets judged on throughput: how fast a correct idea becomes a working, on-system prototype. Consistency comes with the architecture, because the coded system enforces it by default. BNY's designers already work this way, and Fantasy is building the same foundation on new enterprise engagements now.
How to build an AI-native design system
Inventory the current system's tokens, components, and rules, and note which of them exist anywhere besides a design file. That gap sets the scope.
Primitives (palette, scale), semantics (meaning), component tokens (application), each layer in code, each resolving through the one below.
Build to production quality in the framework the team ships (Eliza: Angular).
For every component: purpose, props, states, correct-usage examples, in a structure an AI coding tool can parse and apply.
Git-native instruction files carry conventions and constraints for AI coding tools, versioned alongside the code they govern.
One designer, one working prototype, shipped from the development environment. Fix what breaks, then scale the workflow along with the library.
Frequently asked questions
A design system delivered as production code and documented for AI coding tools rather than static handoff. Tokens, components, and usage rules are machine-readable, so AI tools generate interface code that matches the system instead of approximating it.
A traditional system is a human reference: a component library in a design tool plus written guidelines, applied by engineers during rebuild. An AI-native system is the build material itself: coded tokens and components with documentation machines can parse, removing the rebuild step and the drift it creates.
Design tokens organized as primitives (raw values), semantic tokens (what a value means in the interface), and component tokens (what a specific component uses). Each layer resolves through the one below, which keeps a scaling product consistent and gives AI tools one unambiguous answer for every design decision.
Yes, when the design system is built for it. On BNY's Eliza platform, designers build fully functioning, performant prototypes directly in the IDE on the coded design system Fantasy delivered, running multiple prototypes in parallel, and BNY's design team moved to a fully IDE-native workflow.
Structured and explicit: each component's purpose, props, states, and correct-usage examples in parseable form, plus repo-level instruction files that encode conventions and constraints. Every rule that governs the system lives somewhere a machine can read it, in the repo, in parseable form.
Fantasy delivered one for Eliza, the enterprise AI platform at BNY, in Angular with a three-layer token architecture and 60+ production components. BNY reports 20,000 employees building AI agents on Eliza across 125+ live use cases; the design system is the foundation the bank's design and engineering teams build on.