Design Systems Without Figma: Our AI-Powered, Code-First Approach

At Inverse Studio, we are breaking new ground in how design systems are built and maintained. We have successfully completed multiple complex projects, establishing comprehensive design systems from the ground up without ever touching Figma or Tokens Studio. This journey has not only redefined our workflow but has also fundamentally shifted our perspective on the role of artificial intelligence in design and development.

Our biggest discovery is where AI creates its value for us. It earns far more deep in the development process, writing and reviewing the underlying code, than it does generating initial design concepts. And that value serves one goal: ownership. We use AI so a design-rooted team can own the production frontend end to end, from the first token to the shipped interface, with the consistency of a governed system behind every decision.

The Workflow in Practice

What began as a loose set of scripts has grown into Studio, our in-house toolchain for code-first design systems. It gives every project the same spine: tokens and components living in the repository, agents that know the system’s rules, and a small set of focused surfaces for the moments where a human needs to see, decide, and govern.

In-Editor Enforcement

As our developers write code, AI agents are embedded directly within the editor. These agents actively enforce design system reuse and consistent token application. For example, when a developer describes an intent such as creating a primary action button, our AI identifies and suggests the exact PrimaryButton component from our system. This prevents the creation of one-off, inconsistent elements and ensures that every component used adheres to our established guidelines and token definitions.

The same awareness extends into the running product. A browser extension lets us inspect any element of the live interface, see which tokens produced it, and adjust those tokens in place. The distance between noticing something and correcting it at the source shrinks to almost nothing.

Automatic Guardrails and Drift Detection

Upon saving and committing changes, an automated set of guardrails springs into action. These systems are designed to detect and flag any design drift or hardcoded styles that deviate from our system’s rules. If a developer attempts to use a specific hex color value instead of a defined color token, or introduces spacing that falls outside our established scale, the system immediately flags the inconsistency. This proactive approach stops changes that would compromise the integrity of the design system before they ever land in the main codebase.

Merge Review, Governed in Code

The merge is where the system either holds or erodes, so it gets its own surface. Every proposed change to the design system runs through a review tool that diffs the draft against the baseline and renders both sides of every affected component. A reviewer can compare them side by side, as an onion skin, or as a computed visual difference, in both themes. Breaking changes are counted and must be resolved one by one. A reviewer can accept a change, or merge it with a deferral and a recorded reason, so the decision and its rationale travel with the system instead of dying in a chat thread.

AI prepares all of this: the diff, the previews, the classification of what breaks. A person decides. Nothing lands as a silent auto-fix, because a design system survives on decisions its contributors can see and trust.

The Contract Layer

Underpinning all of this is a contract layer: every rule, token, and component definition lives in the repository as structured, committed files that both the agents and the surfaces read. Tokens ship as plain CSS custom properties. Components ship as a versioned package. And the rules about what the system may become are contracts of their own.

Our colour pairing surface is the clearest example. The system showcase documents what the design system is, while the pairing surface decides what it is allowed to be. Which foreground may sit on which background is an authored, reviewable decision, written to a contract file in the repo, with contrast computed at build time so nothing downstream ever has to guess. As we refine the system, the contracts evolve in the same commits, under the same review, and every agent and surface reads the improved rules immediately. The system grows more consistent over time, not less.

Embracing Rapid Iteration and Learning

We did not anticipate reaching this level of sophisticated tooling and workflow so quickly. In fact, our initial plan with a client for a Figma-less project was scheduled for later this year. The rapid progress we have made comes from an intense period of learning and iteration. We are, to put it plainly, failing and improving at rapid speed.

What truly helps us navigate this accelerated learning curve is our deep, extensive knowledge of design systems and our highly structured approach to design. We are constantly fine-tuning our AI prompts, refining the conditions for our guardrails, and sharpening the context our agents work from. This iterative process, fueled by real-world project challenges, is what truly accelerates our capabilities and allows us to create what feels exceptional for both our team and our clients.

Why Traditional Tools Fall Short

Our journey has also clarified why traditional tools, including Figma and Tokens Studio, or newer AI-driven tools like Pencil or Claude Design, do not fit our specific needs. While tools like Figma are excellent for visual design collaboration and prototyping, they fundamentally operate on a visual canvas metaphor. They lack the native, code-centric understanding and programmatic control essential for a design system that is authored, governed, and shipped in code.

Similarly, while AI tools like Pencil or Claude Design show promise, they still fall short in providing the deep integration with our specific codebases and the granular, rule-based automation that our workflow demands. We need tools that can not only understand design intent but also directly manipulate and enforce it within code, at a level of precision that visual tools simply cannot offer.

We are curious to see where this approach ultimately leads us. We have forged a path that works exceptionally well for Inverse Studio and our clients, building a system that is robust, consistent, and highly efficient. We are keen to understand if other design systems specialists share this perspective. Are you also pursuing a custom, code-first approach, or do you find established tools sufficiently meet your needs for advanced design system implementation?