The future-proof design system

It goes something like this: I make the next product/design decision → AI reads the relevant rules and documentation → It checks the existing system → It builds or extends the component (take Google’s Material 3 principles, apply my tokens, use Base UI, use Lucide icons, implement React + Tailwind component) → It documents the change → It composes the component into the product → Automated checks run → I inspect the result in Storybook and the real browser → I give targeted feedback → AI fixes the underlying cause → PR → CI → merge → next sprint

The component stays in-review until I approve it. This creates a continuous feedback loop: the product continuously stress-tests the design system and the design system continuously constrains the product.

A SELF-EVOLVING CONSTITUTION 

Whenever the project exposes a gap, I turn the gap into a rule. For example, a token missing from Figma became a Figma backfill ledger; a security issue became a requirement for security audits at the end of every sprint; repeated product decisions became documented UI patterns. The principle is simple: if the system doesn't know how to handle something, we fix the system. Whenever something went wrong, I could ask: “why did this happen?”. If the answer was “because the system doesn't have a rule for this”, then the fix becomes: new system rule → documentation → future enforcement. 

WHAT AI DIDN’T DO FOR ME

This part here is my actual manifesto. Everyone knows AI is excellent at local consistency. Once a rule is clear, AI can apply that rule relentlessly: implementing components and states, creating the .tsx, Storybook story, tests and documentation, running type checks, linting, unit tests, migration checks and builds, debugging (tracing implementation problems back to their source). And sometimes it catches things I didn't ask for or have no idea about: my AI agent is a great second pair of technical eyes.

But AI definitely didn’t design the product for me. It can make a super good component, but it doesn't necessarily know whether the component should exist. 

My highest-value contribution remained: information architecture (what’s the user’s mental model?), cognitive load (what can we remove?), product policy (is a declined application the same as a ban?), responsive behavior (what should the mobile experience actually be?), interaction heuristics (what’s an error, or a warning, or neither?), system strategy (should a missing token become a new token, an existing token, or a change to the underlying scale?). I found AI is strongest below the level of judgment.

MYSELF: intent, constraints, product policy, UX rationale, design knowledge, system-level trade-offs, approval.

AI: implementation, consistency, repetition, documentation, testing, investigation, speed.

I like this division of labour. The designer's role moves up the abstraction stack: instead of spending most of my time manually drawing every state, I'm spending more time defining the system that determines how those states should be created.

YET TO BE SEEN: RISKS TO MITIGATE

The system can become too specific to Cabbin. Every new product requirement adds to the design system, so the system can slowly become a catalogue of historical requests. That's why every new component begged the question: is this a reusable design decision, or just a solution to today's problem? 

Figma falls behind code. In my workflow, a token can exist in implementation before it exists in the visual source of truth. My project does have an explicit mechanism for tracking this “debt” (a Figma backfill ledger). But is it even necessary anymore?

AI can make a bad decision very consistently. That's why the governance layer matters so much.

The system hasn't been stress-tested by another product. I cannot yet claim that it is truly platform-agnostic or broadly reusable. However, it is architected toward portability, and it is Cabbin's design system after all.