AI-powered Design System workflow
Making the Design System readable by AI agents.
At WorkJam, our Design System spans 4 libraries: Figma for design, Storybook for web and Native libraries for iOS and Android.
The artifacts are there: components, variants, tokens. What's not there is the reasoning: when to use this component over another, why a pattern was chosen, what edge cases broke previous implementations, what rules a new variant has to respect and so on. That knowledge lives in designer's heads and it creates multiple problems:
Drift between the libraries => Without a shared source of truth for intent, each library drifts.
Devs blocked on Slack => Every implementation question routes back to a designer on Slack.
Slow onboarding => New designers and devs spend weeks absorbing knowledge.
Figma holds visuals. Storybook holds web code. The native libraries hold mobile code. None of them are built to hold decisions, rules, and rationale, and just as importantly, none of them are easily consumable by AI tools.
Devs work with AI assistants in their IDEs. Designers use AI to draft, iterate, and document. If your design system can't be read by an AI agent, you're forcing every AI-assisted workflow on the team to either reinvent the rules or skip them. Both outcomes produce drift.
Attending the Into Design Systems AI conference in March 2026 sharpened the direction. The initiative I proposed: a centralized, AI-consumable knowledge layer that sits alongside the three libraries and holds what they don't.
We're building it as a Bitbucket repo "workjam-design-system" containing MD and JSON files for every component, pattern, and guideline. Plain text. Version-controlled. Queryable. Accessible to any designer or developer, and more importantly accessible to AI agents.
'workjam-design-system' repo's structure
Three concrete roles, not one:
Accelerated documentation. We use the Figma MCP server with Claude to extract component metadata and draft documentation faster than writing it by hand. This is what makes populating the repo at scale realistic for a small working group.
Self-serve guidance for developers. Because the repo lives in Bitbucket alongside our codebases, devs can query it directly through their AI tools while implementing. The expected outcome: fewer Slack interruptions, faster implementation, less guesswork.
AI-generated component scaffolds. With structured documentation as input, AI can generate scaffold code for new component implementations across Storybook and native, reducing the manual translation step that's a major source of drift today.
I proposed this initiative and run a bi-weekly working group: the design team plus 3 developers from across web and mobile. We're intentionally small while we validate the process. Broader rollout follows once the core workflow holds up under real use.
My role in practice: defining the architecture of the repo, setting documentation standards, running the working sessions, building the first wave of component docs myself to pressure-test the format, and coordinating with the 3 devs to validate that what we're producing actually answers their questions when they're implementing.
Too early for results. The metrics we're set up to track:
Drift incidents between Figma, Storybook, and native libraries.
Time to ship a new component end-to-end across the three platforms.
Designer and developer onboarding time to productive contribution.
Volume of design system questions flowing through Slack.
Near-term: Finish the first wave of component documentation, expand the working group, validate that the AI scaffolding workflow holds up across all three platforms.
Longer-term: Connect this back to the design tokens pipeline so the full system; tokens, components, patterns is consumable as one coherent layer by both humans and AI agents.