The Room After the Talk

I built it. Figma MCP + Code Connect + design tokens as structured JSON. The design system is the bridge — not a plugin someone else maintains. If you're waiting for Figma to solve this for you, you'll be waiting a long time. Build the connection yourself and own it.

Neither. The design system IS the context file. CLAUDE.md contains the brand, the tokens, the voice, the methodology. The agent reads it directly. No Figma file needed. No separate guidelines document. The system is the guideline.

Not technical — political. The tooling works. The integration works. What doesn't work is an organisation that measures velocity in tickets closed, not capability gained. The biggest challenge is getting delivery-oriented teams to value infrastructure that makes tomorrow faster, not just shipping today's feature. I've written more on this.

Completely feasible. CLAUDE.md doesn't care if the codebase is React 19 or jQuery spaghetti. It describes the intent — the brand, the rules, the domain. Start with one context file. One token file. One component. The system grows from the inside. You don't need a rewrite. You need a starting point.

Invert the question. Code is the source of truth. Figma is a downstream output, not the origin. Code Connect + Figma MCP means Figma reflects code, not the other way around. Stop “keeping Figma in sync” — make code the source and let Figma follow. The headless DS approach explains the architecture.

Figma MCP server connects Figma desktop to your editor. Query a component, get its properties, ask the agent to implement it using the design system context. The agent reads the token values, the component API, and the CLAUDE.md — then writes code that's correct from the first render.

The review process IS the design system. Tokens constrain the output — the agent can't invent a button variant that isn't in the system. That's automated governance. Human review is for intent and quality, not brand compliance. Engineering buys in because the system reduces their review burden, not increases it. The Stakeholder Simulator covers how to pitch this internally.

The context files ARE the redundancy. If Claude Code goes down, the CLAUDE.md still works with Cursor, Copilot, or any LLM that reads markdown. If Figma MCP breaks, the tokens are still CSS custom properties. The intelligence is in the context layer, not the tool. Tool-agnostic by design. This question came from a DS lead at a major European retailer — and it's the right question. Your system should survive any single tool failure without losing the design intent.

This is the gap the industry needs to fill. MCP is powerful but enterprise security patterns are still emerging. OAuth handshakes, scoped access, audit trails — these need to become standard. For now, local MCP servers with controlled access. For corporate: treat MCP like any other API gateway. The design system MCP should sit behind the same auth as your component library. The tooling is ready. The enterprise security wrapper is still being written.

Platform-specific components — iOS contextual menus, Android bottom sheets — are where the design system's abstraction layer matters most. The token values and interaction patterns are platform-agnostic. The rendering is platform-specific. The agent needs to know both — which means the context file needs platform variants, not just web defaults. Build the abstraction first. Then let the platform-specific implementation derive from it.

You hire both. Or rather — you hire the person who is both. The 50/30/20 split (Designer / Developer / Product Owner) isn't a compromise. It's the job description for a design systems architect in the agentic era. The question assumes a binary that the discipline has outgrown.

This is the question nobody on stage wants to answer. Here's what I think: the positions don't vanish — they transform. A design systems architect with agentic tooling isn't replacing five people. They're doing work that five people couldn't do before — because the system handles execution and the human handles vision, judgement, and narrative. The team shrinks in headcount and expands in capability. That's not a loss. It's a shift. But it requires the architect to be the Design Communicator, not just the component librarian.

In my case: one. One person, four AI agents, one CLAUDE.md, and the design system as infrastructure. This portfolio site — every page, every component, every thoughts essay — was built by one person directing agents. That's the thesis in practice.

Claude Code. Not close. Cursor is an AI-enhanced editor. Claude Code is an agent that happens to write code. The difference matters: I don't want autocomplete — I want a collaborator that reads my CLAUDE.md, understands my design system, and builds entire pages from intent. Voice Mode means I can speak the intent and the agent writes the code. That's not an editor feature.

The INC framework IS the prompting structure. Ideate — describe what you want to explore, not what you want to build. Narrate — give the agent context: CLAUDE.md, tokens, brand voice, constraints. Create — let the agent build. The quality of the output equals the quality of the context. A vague prompt with rich context beats a detailed prompt with no context every time.

CLAUDE.md IS the living project rules. It starts as a few lines — name, stack, voice. It grows with every decision: brand positioning, design tokens, writing style, component patterns. Each conversation with the agent adds context. The rules aren't maintained separately from the work — they're a byproduct of it. My CLAUDE.md is public — you can see exactly how it evolved.

CSS custom properties on :root with theme overrides. One token file, multiple theme layers. The agent reads the base tokens and applies the theme variant. I built exactly this at Fun Lab (Dentsu/Merkle) — multi-brand token architecture with Chakra UI. The pattern is: semantic tokens reference primitive tokens, themes swap the primitives, components stay untouched.

No. And anyone who says yes is lying. But that's the wrong metric. The question is: does the context quality improve the output quality? Yes, dramatically. A well-structured CLAUDE.md gets you to 85-90% on the first pass. The remaining 10-15% is human judgement — which is exactly the part you should be doing. 100% automation isn't the goal. Removing the mechanical work so you can focus on the creative work is.

Yesenia's answer was sharp: measure how many tokens it takes to query something without documentation, then with documentation. Tokens = money. I'd add two more: time-to-first-component (how fast can a new engineer ship a compliant component?) and brand consistency across outputs (does the social post look like it came from the same brand as the product UI?). The second one is what Beyond the Screen is about.

The opposite of overkill — it's the minimum viable use case. CLAUDE.md already does this. A new joiner reads the context file and understands the brand, the tokens, the methodology, the voice. An agent trained on that context can answer “which button variant do I use here?” without bothering anyone on the team. This is on my roadmap too — an AI avatar on my portfolio that talks to visitors about my work, trained on the same CLAUDE.md that built the site.

Selected parts. Always. A context dump is worse than no context — it drowns the signal in noise. CLAUDE.md is curated: brand positioning, design tokens, writing voice, key decisions, methodology. Not every component prop. Not every colour value. The system needs to know why you chose blue, not just that blue is #2563eb. Quality of context beats quantity every time.

Already done. I run four specialised agents: UI Designer (visual decisions), Frontend Developer (React/TypeScript implementation), UX Researcher (domain analysis, content), and Content Strategist (thought leadership, LinkedIn, conference abstracts). Plus a Stakeholder Simulator that role-plays executive conversations. Same CLAUDE.md, different agent definitions. The System section shows all of them.

My System section is exactly this. The CLAUDE.md is public. The agent definitions are public. The build process is documented. The site IS the documentation — it demonstrates the methodology it describes. That's the whole point of proof-of-practice.

This is the Approved in Theory problem in real-time. The answer: stop asking for a migration. Start showing what's possible alongside MUI. Build a NorthStar prototype that makes the current state look dated. “Show and not just tell” — as one audience member put it. The prototype argues better than any proposal deck. And if you truly can't replace MUI, the agentic layer sits on top — CLAUDE.md doesn't care what component library is underneath.

Mine looks like this: one person. 50% Designer, 30% Developer, 20% Product Owner. Four AI agents. One design system. The composition isn't about headcount anymore — it's about capability per person multiplied by the quality of the system they're directing. A senior architect with agentic tooling ships more than a team of five without it.

You don't need to learn markdown. You need to know what to say. The syntax is trivial — headings, bullets, bold. That's 90% of it. The hard part is knowing what context the agent needs, and that comes from doing the work. You don't write the .md in one sitting. You build it through practice. Start with positioning, tokens, and voice. Then every time the agent gets something wrong, that's a missing context entry. The .md is a living document that gets sharper with every session. This site is the proof — CLAUDE.md built this, and this built CLAUDE.md.

I've worked in heavily regulated environments — healthcare (Helix, PenCS), government, enterprise. The reality: you can't use half the software you want, let alone AI. And as teams get smaller, you have fewer people to fight procurement battles. The answer: use everything in discovery. The NorthStar prototype doesn't touch production data, doesn't ship to users, doesn't need security clearance. It's an idea expressed in the fastest way possible. Delivery is the regulated environment— and that's fine. The NorthStar already told you what to build. Discovery stays fast and unconstrained. Delivery stays safe and compliant.

Because AI needs direction and approval. It doesn't act autonomously — it proposes, the human confirms. That requires a surface to communicate through. But here's the thing: that surface doesn't have to be buttons and forms. It could be voice, visual, conversational — any medium where the human can understand what the AI is proposing and say yes or no. The UI becomes a communication layer between human and AI, not a control panel. The design system still governs it — consistency, brand, accessibility — but the form factor shifts. The UI isn't going away. It's changing form.

Users adapt. We already accept UI changes — app updates, A/B tests, responsive layouts. AI-generated surfaces are the same muscle, just faster. And with MCP, the AI is surfacing screens from apps you already know — it's routing you there by intent instead of navigation. You're not learning a new UI, you're being shown parts of the existing one you didn't know existed. The key: the escape hatch. Close the generated surface, return to the known state. No stress. The design system documents both — the adaptive surfaces and the stable base state you return to. That's the safety net.

Get clear. More input — understand the domain, its users, their context, their current use of the software. Unclear intent isn't a failure of the system, it's insufficient context. And it's not a permanent state — it's per-user, per-moment. The same doctor might have clear intent for a chronic disease review but unclear intent for an unfamiliar condition. When intent is unclear, fall back to directive UI — the structured, predictable interface. When intent is clear, generate adaptive surfaces. Both coexist. The system doesn't guess — it either knows enough to adapt, or it shows you the safe default.

That's exactly the right question. And it's the one the talk didn't need to answer, because Freya's context is her own work. But yours isn't. The answer is a design system. Not a Figma library — a machine-readable context layer that every agent reads before it writes a single line. When five designers are each prompting their own AI, the consistency doesn't come from them. It comes from the shared system they're all referencing. CLAUDE.md, design tokens, component contracts. The agents converge on the same output because they're reading the same instructions. Without that layer, you don't have five designers shipping code. You have five separate codebases that happen to look similar on a Tuesday.

Yes. I've been both sides of that conversation. Here's the honest version: AI-generated code from a designer without system context is often structurally fine and semantically fragile. It works. It doesn't compose. The variable names are arbitrary, the component boundaries are wrong, and the styling is inline. An engineer can use it — but they're essentially rewriting it while pretending to extend it. The fix isn't “designers should code better.” The fix is a design system that constrains what the AI produces. When the agent is reading a token file and a component API, it generates code that an engineer recognises. Same naming conventions. Same component structure. Same styling approach. The design system is the shared language. Without it, you're shipping dialects.

It matters, but not in the way people think. Freya's point is liberating: you don't need an engineering identity to produce engineering outputs. That's true. What she's doing in discovery — exploring, prototyping, validating ideas fast — is the exact work AI was built to amplify. Go crazy there. Ship everything. The hybrid identity matters when you cross into delivery. When your prototype needs to become a component in a living design system. When your token choices affect a production build. When your naming conventions have to match the team's existing architecture. That's not gatekeeping. That's the INC framework doing its job — Ideate freely, then Narrate carefully so that Create is consistent. Freya's doing brilliant Ideate work. The design system is what makes it repeatable.

No. Start without one. That's the point of NorthStar Prototyping. Explore first. Ship the idea. Prove the value. A prototype that works is better evidence than a proposal for a design system that doesn't exist yet. Freya's approach is exactly right for this moment — move fast, show the possibility, don't wait for infrastructure permission. But here's what I'd say to do in parallel: as you're prototyping, notice what decisions you're making repeatedly. Colour choices. Button behaviour. Type scale. Spacing. Those repeated decisions are your design system waiting to be written down. The system doesn't precede the work — it emerges from it. Start the CLAUDE.md on day one. Even if it's three lines. That's the seed. Every decision you make consciously is a constraint you won't have to re-argue tomorrow. By the time you've shipped five prototypes, you have a design system. You just need to name it. Here's what mine looks like.

The skills are worth more than ever. The delivery mechanism has changed. Research still tells you what to build. The difference is you can now prototype the answer in the same session as the insight, instead of waiting three sprints. Wireframes still test information architecture — but you can generate five variants in twenty minutes instead of one in a day. Handoff still communicates intent to engineering — but increasingly the handoff IS the code, not a Figma file with a red-line spec. What's gone: the artificial distance between thinking and making. The UX process was stretched over weeks partly because the tools made it slow. AI collapses that distance. The research and prototyping still happen. They just happen faster, and closer together. Freya is doing exactly this — compressing the loop from idea to shipped output. That's not the end of the UX process. That's what the UX process always wanted to be. The design system is what keeps it honest at scale — so that the faster loop doesn't produce faster chaos.

The design system handles this. Semantic HTML, ARIA patterns, colour contrast ratios — these are encoded in the component contracts and token values, not left to the individual prompt. When the agent reads the system, it generates accessible code by default. When it doesn't, that's a missing constraint in the system, not a failure of the designer. Fix the system, not the output. Accessibility isn't a checklist you run after shipping. It's a constraint you encode before prompting.

Yes. Always. That's not a weakness of the approach — that's how software works. Every engineer's code gets reviewed. The question is what the reviewer is checking. Without a design system, they're checking everything: naming, structure, accessibility, brand compliance. With a design system constraining the agent, they're checking intent and edge cases. The review burden shrinks because the system already handled the mechanical correctness.

All three are true, depending on where you sit. For delivery teams, it's compressing — AI makes execution faster. For discovery, it's expanding — AI lets you explore more possibilities than you ever could manually. The people who say it's dead are watching the diamond from the delivery side, where the gap between idea and output has collapsed. But the divergent phase — the exploration, the “what if” — that 's wider than ever. NorthStar Prototyping lives in that expansion. Freya's work proves it. The diamond isn't dead. It's asymmetric now.

Today, not without engineering infrastructure underneath. Vibe-coded apps are discovery artefacts. They prove the idea, validate the interaction, test the flow. Production requires auth, databases, CI/CD, error handling, security — the boring stuff that AI doesn't add unless you ask for it. But here's the shift: the prototype IS the spec. Instead of handing off a Figma file, you hand off working code that an engineer refactors into production. The gap between prototype and product shrinks every month.

Not in discovery. Discovery prototypes don't need test suites — they need to be fast and disposable. But the moment code moves toward production, yes. Claude Code writes Playwright tests for this portfolio site. The design system's component contracts define what to test. The agent knows the expected behaviour because the context file describes it. Testing isn't opposed to vibe coding — it's what happens when vibe coding crosses into delivery.

This is the most important question in the list. The risk is real — if you let “I can ship code” become “I am the developer,” you've traded your most valuable skill for your least differentiated one. The guardrail is the INC framework: Ideate is YOUR job. Create is the AGENT'S job. The design system — the Narrate layer — is the bridge between them. You stay in discovery. The system handles delivery. The moment you're debugging CSS for three hours, you've lost the plot.

I directed it. The AI created it with my design and code direction. And in delivery, a UI designer refines it — in Figma, in code, wherever they work best. That's the point: the design system starts in discovery as intent and tokens, then gets polished by specialists who contribute back to the shared context. Everyone contributes to the narrative layer — designer, engineer, product owner. And anyone with an idea can draw from it. The system is a commons, not a deliverable. Figma isn't where it begins. It's where it gets refined.

The handoff IS the code. Not a Figma file with annotations. Not a Confluence page with screenshots. Working code in a branch, built against the design system's tokens and components. The engineer reviews it like any other PR. The prototype and the handoff are the same artefact. No translation layer. No “the design said X but the build does Y.”

Figma isn't going away — but its role is changing. Figma becomes a downstream output, not the origin of truth. Code is the source. Figma reflects it via Code Connect and MCP. I still use Figma for spatial thinking, flow mapping, and stakeholder communication. But the component library lives in code, the tokens live in CSS custom properties, and the agent reads the code — not the Figma file. Explore wherever you think best. Just make sure the system of record is code.

CLAUDE.md lives in the repo. It's version-controlled. Every team member reads the same context. Every agent reads the same context. That's the collaboration model — not a shared Google Doc, but a shared source of truth co-located with the code it describes. PRs to CLAUDE.md are design decisions. And here's the reframe: everyone contributes to the narrative. The designer adds voice guidelines. The engineer adds component contracts. The PO adds domain language. The system grows because the whole team feeds it.

Curation, not documentation. A context dump is worse than no context — it drowns the signal. CLAUDE.md contains positioning, tokens, voice, methodology, key decisions. Not every component prop. Not every colour value. The agent needs to know WHY you chose blue, not just that blue is #2563eb. When the file gets too long, that's a smell — split it, or delete the parts the agent never uses. Quality of context beats quantity every time.

Claude Code has a free tier. VS Code is free. CSS custom properties are free. A CLAUDE.md file costs nothing. The most expensive part of this workflow is the thinking, not the tooling. Start with what you have. The context file approach works with any LLM that reads markdown — that's the whole point of tool-agnostic infrastructure. The system doesn't require premium tools. It requires clear intent.

Yes — but not the way she means. My Claude agents are the team. They do the work — design, code, research, content — all reading the same CLAUDE.md, all embedded in the design system. Other models are the opposition. I throw the output at GPT or Gemini and say “what's wrong with this?” They don't know my system, my brand, my context — which makes them perfect critics. They spot what my own agents are blind to precisely because they're NOT embedded in the narrative. It's like having an in-house team and an external reviewer. The team builds. The outsider stress-tests. Same principle as Freya's — productive disagreement — but the disagreement comes from different contexts, not just different models.

Jesse's framing says it directly: context over probability. The design system isn't a library of buttons — it's a body of knowledge. Component names, token values, accessibility rules, usage guidelines, anti-patterns. When that knowledge is structured so an AI can query it, the system stops being a resource you consult and becomes infrastructure the agent runs on. My CLAUDE.md does this through prose and markdown. Jesse's MCP server does it through typed tool definitions. Different form, same function: giving the AI the WHY so it doesn't have to guess.

It means the system has two audiences: humans and machines. Most design systems are built for one. The human audience needs Storybook, docs sites, Figma libraries — all good. The machine audience needs structured, queryable, predictable interfaces. Jesse built validate_component_api for exactly this reason — so the AI can check its own output against the system's rules before it ships. That's governance automated. When I talk about agentic design systems, this is precisely what I mean: a system that enforces itself, not one that relies on human review to catch every deviation.

Jesse went the TypeScript MCP route — tool definitions with structured inputs and outputs, served to Claude Code. I went the CLAUDE.md route — prose, structured headings, decisions captured in plain language. Both work, and they're complementary not competing. The real cost isn't technical — it's curatorial. You have to decide what the system knows. Jesse's team spent real time encoding component usage rules, accessibility notes, and token semantics. I spent time encoding brand voice, design decisions, and methodology. Machine-readability isn't a format — it's a commitment to making your implicit knowledge explicit. That's the hard part.

Jesse answered this well: Figma MCP pulls structured component data from a designer's Figma file — properties, variants, auto-layout. A custom MCP server lets AI build anything that follows your design system's rules, with no Figma file required. I'd add a third dimension: CLAUDE.md sits between both. Figma MCP knows the visual specification. Custom MCP validates the code. CLAUDE.md explains the intent — why this component exists, what problem it solves, when not to use it. You need all three for a complete picture.

Jesse said roughly a month, with ongoing refinement — and that sounds right. Confidence in this kind of infrastructure isn't a threshold you cross, it's a gradient you climb. The first week you're fixing tool schemas. The second week you're tuning which context gets passed. A month in you trust the core loop. Six months in you're refining edge cases. My experience with CLAUDE.md was identical — the first version was 20 lines and got things wrong constantly. The current version is hundreds of lines and gets things right most of the time. The process doesn't end. It compounds.

Treat content as a first-class token. Jesse's system encodes component documentation alongside component APIs — that's content as infrastructure. Most design systems separate content guidelines into a document nobody reads. Fold it in. Write rules the AI can consume: “headings use sentence case,” “error messages name the field and tell the user what to do,” “button labels are verbs.” The agent reads those rules exactly as it reads spacing tokens. Content governance scales the same way visual governance does — through machine-readable constraints, not style guides in a PDF.

Jesse served dozens of New York State agencies. I've worked in healthcare — Helix at Telstra Health, PenCS. The answer is the same in both contexts: separate discovery from delivery. In discovery — NorthStar prototyping, early exploration, stakeholder alignment — you can move fast and use the best tools available. No production data, no compliance risk. In delivery — the code that ships to real users — you're constrained, and rightly so. Jesse's validate_component_api is delivery infrastructure: it exists precisely because the output needs to be trustworthy. Build the wall between environments deliberately and you can move quickly on both sides.

Jesse's “curators, not innovators” framing is the key. The team's job isn't to invent new patterns — it's to evaluate whether AI-generated patterns hold up against existing user research, accessibility standards, and brand guidelines. That's a quality gate, not a creative brief. In INC terms, this is N's role: the Narrate layer encodes what good looks like. The agent generates against those constraints. The human reviews for intent and edge cases, not basic compliance. Don't try to automate both — you'll get efficient outputs that miss the point.

Jesse said his team is working on a shared repo where the whole team can update agents, skills, and a CLAUDE.md — still TBD. That's exactly the right direction. The sync problem is a governance problem wearing a technical costume. The real question is: who owns the source of truth? In Jesse's case, the MCP server is the delivery source of truth. In mine, CLAUDE.md is the discovery source of truth. When design changes, the token file updates. When methodology changes, CLAUDE.md updates. The tooling reflects the decision — not the other way around. That's the N layer in INC.

Jesse has six people serving dozens of government agencies. I have one person plus agents serving this entire site. The question assumes shrinking is the problem. I think the capability expansion is the story. A six-person team that serves the scope of a sixty-person team isn't a tragedy — it's proof the infrastructure works. What gets harder is the invisible cost: when a small team carries the knowledge of a large one, the N layer has to be genuinely robust. Verbal knowledge dies when someone leaves. CLAUDE.md doesn't. The answer to team shrinking isn't to resist it — it's to build the context infrastructure so deeply that the knowledge outlasts the headcount. That's The Middleware Problem.

Cristian's answer is right: ownership. When you understand the technical layer, you can own the quality of what gets implemented — not just what gets designed. But I'd go further. The value isn't knowing how to write JavaScript. It's knowing how the system works well enough to encode your decisions into it. When I write a CLAUDE.md, I'm not writing code — I'm encoding intent so precisely that the system produces the right code without me touching it. That's a design skill, not a development skill. The designer who can do that has removed the interpretation gap entirely.

Cristian doesn't — plan mode and subagents are enough for his scale, and that's a sensible call. I do. I run named agents with persistent memory committed to git: UI Designer, UX Researcher, Frontend Developer, Content Strategist. Each reads the same CLAUDE.md but carries its own specialisation and memory of past decisions. The difference matters at scale. Cristian acknowledged “a lot of stuff lives on my head” — that's the problem named agents with written memory solve. The knowledge doesn't leave with the person. It lives in the agent definition, in git, readable by anyone — or any agent — who inherits the work. The System section shows how I've structured this.

Cristian's approach is the right one: build a skill that knows what correct looks like, then run it as a linter across the legacy codebase. His scaffold-component skill generates components against current standards. His token-auditor detects drift. Both work without a full rewrite. I'd add one thing: before you build the linter, write the CLAUDE.md. Define correct. Not as a document nobody reads — as structured context an agent can query. The linter is only as good as the definition of correctness it enforces. Start there. Build the audit skill second. The headless DS architecture explains how I structure that definition layer.

Cristian put it perfectly: he can't write a proper JavaScript function and built agentic infrastructure anyway. That's the honest answer, and I respect it. My answer is different because my context is different. Deep React experience is 30% of my identity — not because it made me a better designer, but because it made me a better architect. When I specify a component contract, I know what I'm asking the agent to build. When the agent gets it wrong, I know why. But here's the reframe: you don't need to learn React to direct an agent that writes React. You need to understand the system well enough to know when the output is wrong. The bar isn't “can you write it.” It's “can you evaluate it.”

Not fully automated. Not soon. Cristian is honest about this: he refactors his rules every few weeks for overlaps and contradictions, his pipeline is around 80k tokens, and whatever he said at the conference might be wrong by next week. That's not a weakness — it's the discipline being young. The future isn't a pipeline where nobody makes decisions. It's a pipeline where the mechanical decisions are automated and the consequential ones are human. “Should this component exist at all?” is a human question. “Does it use the right token?” is an automated one. Sustainability beats velocity every time.

Cristian's answer is careful and right: the bottleneck moves, and going faster indefinitely is not sustainable. I'd add what he left implicit. The team shrinks in headcount and expands in capability — but only if the N layer is robust. A small team carrying large-team knowledge is only viable if that knowledge is externalised. When it lives in someone's head, it leaves with them. When it lives in CLAUDE.md, in agent definitions, in version-controlled rules, it's institutional. Cristian admitted “a lot lives on my head.” That's the vulnerability. The answer isn't to resist shrinking — it's to encode the knowledge so thoroughly that the work doesn't depend on any one person. That's The Middleware Problem.

Cristian hasn't — and he said so directly, which I respect. I have. Fun Lab at Dentsu/Merkle was exactly this: multi-brand token architecture across a portfolio of clients, with Chakra UI as the component layer. The pattern: semantic tokens reference primitive tokens, themes swap the primitives, components stay untouched. One button component. Many brand expressions of it. The agent reads the active theme and generates against those values. What makes multi-brand hard isn't the token architecture — it's the governance. Who decides when Brand A's “primary” diverges from Brand B's? That decision needs to be encoded, not left to interpretation.

This question came up and nobody answered it. Treat content as a first-class token. Voice guidelines, microcopy rules, error message conventions, heading hierarchies — these belong in the same context layer as your colour tokens and spacing scale. Most design systems put content guidelines in a PDF nobody reads. Fold them into the machine-readable layer instead. Write rules the agent can consume: “button labels are verbs,” “error messages name the field and tell the user what to do,” “headings use sentence case.” The agent reads those rules exactly as it reads spacing tokens. Content governance scales the same way visual governance does — through encoded constraints, not style guides. My CLAUDE.md carries voice as structured rules. Every word on this site was generated against them.

Jan's answer is right: colocated with the component. One folder, one component, one set of rules. Everything the agent needs to work with that component lives next to it. But I'd make the principle explicit. Documentation that lives in a separate docs site is documentation for humans who go looking. Documentation that lives next to the code is context the agent finds automatically. The distinction isn't cosmetic — it changes what gets consumed and when. When I structure a headless DS, the rule is simple: if the agent has to navigate away to find it, it won't.

Jan said he can't answer yet — he hasn't compared them properly. I'll give you an opinionated view from experience. Markdown is better for rules and rationale. JSON is better for contracts and data. A component specification has both: the what (JSON — props, variants, token mappings, accessibility requirements) and the why (markdown — when to use it, what it replaces, how it behaves across contexts). Nathan Curtis called this “components as data” and he's right. The agent reads the JSON to build it. It reads the markdown to understand the intent. Both matter. The answer isn't markdown or JSON — it's a specification format that carries both.

Start with third-party MCPs to validate the workflow. The Tokens Studio MCP, when it ships, will give you brand tokens as queryable infrastructure with no build cost. Use it. If you reach a point where the off-the-shelf MCP can't express something central to your system — a custom naming convention, a proprietary component API, a domain-specific rule set — then build your own. The decision criteria is specificity: if your system has knowledge that generic tooling can't represent, encode that knowledge yourself. My CLAUDE.md is, in effect, a lightweight MCP — structured context the agent reads before it touches anything. That costs nothing to build and captures the things a generic tool won't know.

Jan gave the clearest answer of the conference on this: always use multiple rules files, and let the AGENTS.md act as a router. I'd add the layer above that. Rules files govern component-level decisions. Skills govern task-level repeatable actions — scaffold this component, audit these tokens, generate this story. Agents govern context-level specialisation — the UI Designer agent that knows visual rules, the Content Strategist agent that knows voice rules. The question to ask at each level: is this a constraint, a procedure, or a perspective? Constraints belong in rules. Procedures belong in skills. Perspectives belong in agents. The System section shows how I've structured this.

Jan put it well: CLI agents can do more, and desktop tools are catching up. The practical difference right now is scope. An IDE agent sees the file you're in, the files you've opened, the project context you've loaded. A CLI agent sees the whole repository — it can run audits, refactor across files, commit changes, and iterate on the output of its own previous run. That matters for design systems work specifically. Token audits, component scaffolding, cross-file consistency checks — these need repository-wide vision. Claude Code operates at that scope. If your workflow involves touching multiple files and evaluating the output holistically, CLI is still the right environment.

Generic AI output looks the same because it draws from the same training distribution — the entire internet, averaged. Your design system is the antidote. When the agent has your token file, your component contracts, your naming conventions, and your voice rules as context, the output space narrows dramatically. It's not generating from the average — it's generating within your constraints. Jan's architecture makes this concrete: AGENTS.md routes to your rules files, which constrain the agent's decisions before it touches a line of code. The brand becomes the prior. The result looks like you, not like every other shadcn site.

This is the question the whole conference was circling. Jan's architecture gives a strong answer for the delivery layer — rules files by domain, AGENTS.md as the router, docs colocated with components. I'd add the temporal dimension, which Jan touched on and nobody else did: structure context for past, present, and future. Past context is what exists — the tokens, the components, the established patterns. Present context is the task — what the agent is being asked to do right now, with what constraints. Future context is intent — the NorthStar, the direction, the decisions that haven't been encoded yet but should be. Most systems only give the agent past context. The most powerful context structures give it all three.

Jan covered three viable approaches: a central MCP server that all repositories query, a spanning context folder that multiple repos reference, or a dedicated context repository that agents pull from. All three work. The choice comes down to who owns the source of truth and how it gets updated. My preference is the MCP model at scale, because it separates the knowledge layer from the implementation layer cleanly. Any agent, in any repo, in any stack, can query the brand tokens, the component contracts, the voice rules — without those rules being duplicated across repositories. The N layer lives once. Everyone draws from it.

Jan said designers who prototype with AI are in higher demand at GitHub. That's a data point, not a rubric. Here's my read on the emerging rubric. The new bar isn't “can you code” — it's “can you direct a system.” Can you write specifications precise enough for an agent to implement correctly? Can you evaluate the output and know when it's wrong? Can you encode intent into context files that outlast any single conversation? Those are design skills applied to a new medium. The boundary that's blurring isn't between design and engineering. It's between authorship and specification.

Jan's framing here is genuinely exciting. Most teams use Storybook as documentation — a catalogue of components in their permitted states. Jan is proposing something different: Storybook as the place where designers build, explore, and test new directions inside the live system. Not a handoff tool. Not a reference library. An active design surface. When Storybook is connected to a CLI agent with the full design system as context, it becomes generative. You can prompt a new component variant, have the agent scaffold it, see it render in Storybook in real time, and evaluate it against the existing system — all without leaving the design environment. That's not vibe coding. It's directed creation inside a constrained, principled system.

Mr. Biscuit's multiplexing technique — routing through brand packs to break Figma's 4-mode limit — is clever for colour and spacing. But multi-brand at scale means different component APIs, different interaction patterns, different content rules, different accessibility requirements per brand. Colour swaps are the easy part. The hard part is when Brand A's button has an icon slot and Brand B's doesn't. When the navigation pattern changes entirely between verticals. When the voice rules mean the same component needs different microcopy. Those differences live in the narrative layer, not the token layer. Tokens give you the what. You need context files that give the agent the why and the when.

The Variable Visualiser graph is beautiful at demo scale — a few collections, a dozen connections. At enterprise scale, with hundreds of components each binding dozens of variables across multiple brands, themes, and density modes, the visual graph becomes unreadable. The same problem hits the resolver: runtime resolution of deeply nested aliases has performance implications. The parametric approach is correct in principle. But the tooling needs to evolve from visual graph to queryable infrastructure — which is exactly what Jan Six's MCP approach and Jesse Gardner's custom MCP server solve. The graph is for understanding. The MCP is for operating at scale.

This is the question Mr. Biscuit's demo inadvertently answered. Each component generation took 30 minutes in Cursor. Context ran out mid-session, requiring a fresh chat. The prompt template had to be re-fed every time. That's the cost of not having persistent context. The parametric variable setup is front-loaded work that pays off in consistency. But the real time cost isn't in Figma — it's in the AI workflow. A persistent context file that the agent loads automatically eliminates the 30-minute rediscovery cycle. The setup cost isn't variables versus no variables. It's persistent context versus ephemeral prompting.

When a parametric component's variable bindings change — a new token added, a mode renamed, an alias chain restructured — the code must sync. Mr. Biscuit acknowledged this: everything except binding changes can be iterated by re-exporting JSON. But binding changes require code updates. This is the same versioning problem every design system faces, parametric or not. The difference is visibility. In a parametric system, the Variable Visualiser graph shows you exactly which connections changed. In a variant-based system, you're hunting through 600 components hoping to find the inconsistency. Parametric doesn't eliminate breaking changes. It makes them traceable.

Mr. Biscuit's answer is the resolver: export the JSON, the resolver reads it, done. That works for token values. But the deeper sync problem is structural. When Cursor AI generates a component from a Figma link, it interprets the design through the MCP's lens. It might miss a layout constraint. It might not stretch children correctly. It might misread which mode applies where. The video showed all of these happening. The sync mechanism isn't the JSON export. It's the prompt that tells the AI how to interpret the design. That prompt — compDesignToCode.md — is doing the real work. And it needs to be as carefully maintained as the tokens themselves.

This is the gap in every “Figma to code” pipeline, not just Mr. Biscuit's. Figma variables control visual properties: colours, spacing, radii, typography. They don't encode ARIA attributes, keyboard navigation patterns, focus management, screen reader announcements, or semantic HTML structure. The generated React component gets the styling right but says nothing about whether the button uses a <button> element or a styled <div>. Whether it has aria-pressed for toggle states. Whether focus is trapped correctly in a modal context. Accessibility lives in the component contract, not the token layer. It belongs in the context files the agent reads before it generates anything — not as an afterthought once the visual output looks right.

Yes, and this is the realistic migration path for most teams. You don't burn down your existing component library to go parametric. You start with the highest-maintenance components — buttons, inputs, cards — where the combinatorial explosion hurts most. Convert those to parametric variables. Leave simpler components as variants until the cost of maintaining them manually exceeds the cost of converting them. Mr. Biscuit's “600 variants for one button” argument is compelling precisely because buttons are the worst case. Not every component has six independent axes of variation. Pick the ones that do.

This is the question Mr. Biscuit's framing invites but doesn't address. “Figma as source of truth” works for teams with Figma. It doesn't work for solo practitioners, startups without design tooling budgets, or code-first teams where the codebase IS the design system. Mr. Biscuit briefly acknowledged this in his IDS talk: “for startups and personal projects, code-first without Figma is fine.” That throwaway line is actually a different philosophy. If your tokens live in CSS custom properties rather than Figma variables, the AI reads them directly from the codebase. No export step. No resolver. No plugin dependency. No 4-mode limitation. The “shortest path” isn't Figma to code. It's removing the steps between intent and implementation.

Mr. Biscuit's strongest argument is that parametric variables eliminate the human errors inherent in maintaining 600 variants. He's right. But the demo introduced a different class of error: AI misinterpretation. The LLM didn't stretch children correctly. It misread mode names. It needed manual corrections for layout, visibility, and state logic. It ran out of context. These aren't human errors — they're prompt errors. The quality of AI output is bounded by the quality of context it receives. A detailed prompt template improves consistency. Persistent context that the agent loads automatically improves it further. The error surface hasn't disappeared. It's moved from maintaining variants to maintaining context.

Mr. Biscuit's demo shows the architect's new role clearly, even if he doesn't name it. The architect builds the parametric variable structure. Defines the collections, modes, and aliasing chains. Writes the prompt template that tells the AI how to interpret the design. Debugs the visual graph when something looks wrong. Decides which properties are parametric and which aren't. Evaluates whether the AI output matches the design intent. None of that is “writing CSS.” All of it is design systems architecture. The job hasn't been automated. The medium has changed. You're still making the structural decisions. You're just encoding them differently.