Jan Six opened with a question the industry keeps re-asking: should designers learn to code? He first asked it himself in 2017 — not to become an engineer, but because he wanted his designs to actually ship the way he intended them.
He is a principal product designer at GitHub and one of the co-creators of Tokens Studio. The answer he gave in Istanbul was less about designers writing code and more about something harder: making a brand legible to a machine.
Side projects, then tokens
Six learned to code the slow way — courses, self-teaching, and above all side projects. His advice on that is specific: rather than starting something new every time, return to an old project and extend it. Progress is harder to see, but the learning compounds.
When Figma plugins arrived he moved quickly, because for the first time he could remove a limitation inside his own design tool instead of waiting for someone else to fix it. That turned into Tokens Studio: design tokens defined in a neutral JSON structure, themed, pushed to Git, reviewed by engineers like any other change, and pulled back into the codebase.
A design token isn't a CSS value or a Figma style. It's a design decision written in a platform-agnostic format — defined once, applied anywhere.
That neutrality is the point. The same definition serves iOS, Android and web; engineers translate at the edges. And for the first time, a designer's change could propagate into what engineers actually build.
The shiftWho consumes the system has changed
Design systems were built for people: engineers, designers, product managers reading documentation and implementing it. That assumption no longer holds. Adoption of coding agents moved fast, and Six pointed at a detail worth sitting with — in a recent prototyping survey, the second most-used prototyping tool was a coding agent.
Meanwhile the generic AI-generated interface has become recognisable. Tools like Lovable, Bolt, v0 or a coding agent will get you something in minutes, and most of those somethings look alike. The differentiator is no longer speed; it's whether the output looks like your product.
Three problemsWhy systems aren't agent-ready
Drift
Old parts of the system nobody dares touch sit next to new ones. The agent reads both and has to guess which is the source of truth.
Tribal knowledge
The rules you absorbed when you joined the company live in your head. If it isn't written down, for an agent it doesn't exist.
Disconnected context
Brand values may be documented — in a wiki, in Slack, in a deck. If the agent isn't connected to that source, it might as well not exist.
The framing he offered for the second problem is the one worth stealing:
Imagine your agent as a contractor who rejoins the company every single week. What would you hand them so they can do good work on day one?
— Jan Six, GitHub · Principal Product DesignerAnswering that question honestly surfaces how much of the system is unwritten: naming conventions, why a component exists, when not to use it, which of five typography options fits which situation. And when the information is missing, agents don't stop — they infer. Whatever isn't explicit gets invented, usually toward the generic average of everything the model has seen.
A first fixBuild a prototyping playground close to production
Many designers can't point an agent at the production codebase — either because engineering won't allow it, or because production isn't a safe place to experiment. Six's answer is a middle ground he keeps seeing at companies: an environment that looks and behaves like the product but isn't it.
At GitHub a colleague uses one to explore new navigation patterns — issues, pull requests, the familiar surfaces, rebuilt in a space where changes are cheap. Elsewhere, a team rebuilt a close approximation of their product so designers could prompt their way to a testable flow in an hour and put it in front of a user the same day.
Less than you think
Components (ideally the real design-system ones, if you can use them), tokens for typography, spacing and colour, and a small set of rules for how a prototype should be scaffolded — navigation, shell, conventions. An agent can help you build the playground itself. The payoff compounds: once several designers prototype in the same environment, they can read, fork and remix each other's work.
A brand is more than tokens and components
Here is where the talk got harder, by Six's own admission. Tone of voice, imagery, patterns, the reasons behind decisions — none of that lives in a component library, and all of it is what makes output feel like your brand. He walked through the layers teams are using to close that gap, and was clear that nobody has solved it completely.
| Layer | What it does |
|---|---|
| Rules | High-level instructions the agent reads every time. The cheapest way to move knowledge out of your head and into the repository. |
| MCP / CLI | Makes the brand queryable rather than pasted. Tokens, components and documentation come from one source. |
| Skills | Knowledge of how to apply the brand in a specific codebase, packaged as a repeatable process — a design review skill, a brand validator. |
| Subagents | A specialist responsible for one job: reviewing output, or getting something right the first time with the right skills and tools attached. |
The subagent layer already has a working example at GitHub: an accessibility agent attached to every pull request. It reviews the code for accessibility issues and comes back with suggestions — knowledge the accessibility team spent years accumulating, now applied to every PR instead of the few someone had time to look at.
That last point matters more as output volume grows. Reviewing everything by hand stopped being realistic; the review itself has to be part of the system.
The hard partEverything lives somewhere else
Stack those layers and a new problem appears: rules here, skills there, plugins somewhere else, plus whatever context lives in your issue tracker or documentation. The definitions fragment across tools.
Six's experiment is a single point of contact — he calls it a brand MCP, or a brand guardian. One place your agent talks to, whatever the question. It sits between the coding agent and the brand: the user prompt goes in, the MCP enriches it with the tokens, components, documentation and brand definition needed, and the agent builds from there. It's what he's working on with Tokens Studio, so teams don't each have to assemble it themselves.
In the demo, a request for a dashboard came back not just structurally correct but styled in the brand — colours, typography, tone — with the agent iterating and returning suggestions.
Take-awaysThree things to do next
- Audit your system — especially if it's an older one. What still works, what has drifted, and which parts of the context need to be written into the system rather than remembered.
- Create a prototyping environment if you can't use production. Designers can produce code prototypes fast and hand them to engineers.
- Prepare for the cultural shift. Designers will ship more code, which means more pull requests landing on engineers' desks. That conversation — about roles and review — needs to happen before the volume arrives.
Asked afterwards how he works day to day, his answer was matter-of-fact: small changes go straight into code, because he can read CSS; Figma comes back out for big concepts, where its speed of exploration still wins. Not every change is worth handing to an agent.
