When your AI system generates a button, it works. When it generates a button that respects your design tokens, enforces your brand, and adheres to your accessibility standards—that's different. One is AI making it work. The other is AI making it good.
Most teams are stuck on the first. Their AI systems generate code that ignores design tokens entirely. Buttons don't match the color palette. Spacing breaks the system. Brand consistency falls apart at scale. The problem isn't the AI—it's that design tokens are invisible infrastructure to AI systems. They don't know tokens exist, and they have no incentive to enforce them.
This is the core challenge facing product and engineering teams right now: How do you keep systematic design choices intact when AI is generating your product?
The W3C Design Tokens Community Group released the first stable specification last October to answer this. But a standard existing and engineering teams actually using it to enforce design intent are two different things. That's why we're hosting a webinar with Kaelig Deloumeau-Prigent, co-chair of the W3C Design Tokens Community Group, and Chris Bloom, principal engineer at Knapsack who built our architecture for tokens-as-AI-enforcement.
The problem engineering teams face
Your design system contains decisions. Colors. Spacing. Typography. Shadow depths. Interaction patterns. These aren't decorative—they're business logic. They represent years of user research, brand decisions, and accessibility choices.
When humans write code, you can enforce these decisions through code review. When AI generates code, you can't review every token. You need tokens embedded in your AI's decision-making from the start.
Right now, most teams have no way to do this. They document tokens in Figma or a design tool. They generate code from Style Dictionary or Token Studio. But their AI systems? They operate independently. The result: AI-generated features violate your design system by default.
This is happening at companies like yours. Engineers tell us:
- "Our AI generates buttons that don't match our design tokens"
- "We can't scale brand consistency when AI is writing half the code"
- "We need a way to make design tokens mandatory, not optional, for AI systems"
What the W3C standard actually enables
The Design Tokens specification (v2025.10) provides a vendor-neutral way to define tokens so machines can consume and enforce them. Not just documents. Not optional suggestions. Actual structured data that AI systems can treat as mandatory constraints.
This changes what's possible. Instead of hoping AI respects your design system, you can architect systems where tokens are non-negotiable. AI systems can validate their output against tokens. Design governance becomes architectural, not aspirational.
But knowing the spec exists and actually building systems that enforce it are different problems. Kaelig will cover what the specification enables. Chris will cover how to actually architect tokens so your AI systems enforce them.
What you'll learn
The W3C tokens primer (Kaelig)
What the stable specification provides, how it solves the fragmentation problem, and what "enforced tokens" actually means architecturally. You'll understand why this matters for AI systems specifically—this isn't about consistency across platforms (important, but not enough). This is about AI systems treating tokens as mandatory.
How to architect tokens for AI enforcement (Chris Bloom)
How Knapsack built the Tokens Engine to support tokens that AI systems can actually read and enforce. You'll see:
- How to structure tokens so AI systems treat them as constraints, not suggestions
- How design, engineering, and product can collaborate on token governance when AI is generating code
- Real examples of tokens enforcing brand, accessibility, and design intent in AI-generated UI
Why this matters now
Design systems were built for humans reading code. AI changes that. If your tokens are static docs that AI can't see, you're going to lose consistency. If tokens are architectural constraints AI systems enforce, you scale design faster. This isn't a future problem—it's happening now.
Who should join
This webinar is for engineering leaders, product managers, design system executives, and CDOs who are asking: "How do I keep design intent intact when AI is generating code?" It's for teams building AI features and wondering why they're not respecting the design system. It's for organizations trying to scale systematic design choices in an AI-augmented world.
If you're responsible for design systems, product consistency, or AI feature quality—you need to understand how tokens work in this new world.
Register and get involved
The webinar is free, virtual, and limited to 200 attendees to keep the conversation focused and real. We'll leave time for implementation questions and real-world scenarios from teams building this now.
Kaelig and Chris are also open to conversations with teams exploring how to architect design tokens for AI. If your organization is scaling AI features and wants to keep systematic design choices intact—reach out. We'd like to talk.
Register for the webinar
August 26 1pm EST
(or watch the recording after by clicking this link)
For a technical primer on design tokens before the webinar, watch Kaelig's lightning talk at CascadiaJS: https://lnkd.in/gg6c6Q2U
.jpeg)