What I Heard at Into Design Systems AI 2026

Four themes from eighteen talks — and the through-line nobody named on stage but everyone was circling.

I just sat through eighteen talks at Into Design Systems — AI 2026, and I want to write down what landed before the residue fades. There's a particular kind of signal you only get at a conference like this one, and it isn't in any single talk. It's the consensus. When practitioners who don't know each other's work, in companies as different as Indeed, GitHub, Spotify, WhatsApp, NY State ITS, Miro, Adobe, and a handful of small studios, all spend forty minutes converging on the same handful of moves — that's the part worth writing down. Not the demos. The agreement.

What follows isn't a recap of eighteen talks; the conference's own summary index does that better than I could. It's four themes that came up in nearly every session, with the talks I'd point at if you only had time for the highlights. At the end I name the through-line nobody put on a slide but everyone was circling.

Theme 1 — AI is a new user of your design system, and it reads differently than you do

The single most universal idea across the conference, and the one that quietly reframes what design systems are for. Diana Olozin from Indeed put it most plainly: AI is a new user. Her team treated that claim like an engineering problem and ran an actual benchmark — 1,056 prompts across eight MCP configurations and several formats — and found that JSON beat Markdown with roughly 80% fewer tokens, higher accuracy, and about 5× lower cost at scale. The line from her talk that stuck: "JSON is a contract." Diana's earned conclusion was the cleanest formulation of the whole conference: JSON for MCP, Markdown for rules.

Jesse Gardner from New York State ITS told the same story from the other end. His title — Context > Probability — is the framing I've already started borrowing. AI alone produces the most probable answer, which on the modern internet means Tailwind plus shadcn plus a vaguely Stripe-ish look. A design system, in his framing, is the infrastructure that makes AI output trustworthy, on-brand, and accessible. Jesse's team built that infrastructure for a state government, accessibility-tested with native screen-reader users, and cut their context cost from 50–80k tokens down to a fraction of that through Code Connect and JSDoc usage guidance.

TJ Pitre from South Left pushed the same idea into a process claim — everyone is a context engineer now — and Laura from Figma into a language one: "vibes don't translate, but structure does." Both lines hit harder than they should, because both are saying the same thing in different rooms.

The unifying observation is that the design system is no longer just a product designers and engineers consume. It is now also infrastructure — an API that lets a non-human collaborator build your product safely. That's a meaningful demotion of the role of beautiful documentation and a meaningful promotion of structured, semantically-named, machine-readable artifacts. Several teams said, on stage, that if they were starting today they'd build JSON-first and treat the human-readable docs as a render of that source. I think they're right.

Theme 2 — The designer–engineer line is dissolving, and human judgment is becoming more valuable, not less

The old "should designers code?" debate showed up in maybe a third of the talks, and the answers were remarkably consistent. Freya Stockman from Relevance AI gave one of the more memorable framings — "I'm not an engineer, but I ship code" — describing how she went from a designer with zero engineering background to 39 PRs since being given seven days to design and ship an onboarding flow. Her unlock was a sentence I've already stolen: "everything is text files. I can't code, but I can write prompts and docs." Her 70-20-10 split (70% planning, 20% generation, 10% review) is the discipline behind it.

Jan Jancs from GitHub, co-creator of Token Studio, made the more measured version of the same point: you need to read code, not necessarily write it. Own more of the outcome. Sebastian Russo from WhatsApp showed what that looks like at the production end — bringing the full WhatsApp design system to a ten-year-old web app, with a team of about two, reaching 64% mobile parity and WCAG 2.2 compliance. "A design system is not what your guidelines say — it's what your code says," he told the room, which was the most quietly devastating line of the day.

But — and this is the part that gets undersold in the "everyone is a designer-engineer now" version of the story — every talk that touched the role question also pointed at the work that isn't dissolving. Jesse Gardner: "When things are fast, reflection is the first thing to go." Andresa and Eddie from Miro framed it as "AI is a new hire to onboard" — meaning the agent isn't a magic box, it's a junior colleague whose mistakes are usually your documentation gaps. Romina, from designsystem.guide, formalized the idea into trust levels: the agent is an intern, then a junior, then more, gated by risk × confidence, with humans in the review loop on anything consequential.

So the move isn't "designers become engineers." It's that the line between describing and executing a piece of work is dissolving, while the line between judgment and execution is widening. The taste calls, the accessibility floor, the "is this even the right shape" decision — those are getting more visible, not less, as everything around them speeds up. The talks that stuck with me hardest were the ones that named both halves of that move at once.

Theme 3 — The new move is to shrink what has to be reasoned about

The counter-intuitive pattern I kept seeing — and the one I now believe most strongly — is that the systems that work best with AI are not the bigger ones. They're the smaller-bubble ones.

Spotify's Encore team presented their layered architecture as the most concrete version of this: split components into foundation / style / behavior layers on top of headless systems (React Aria, Base UI), so designers can tweak without waiting on the platform team and so agents get smaller context bubbles to reason about. With 220k+ style uses and 86k component placements, Encore had earned its complexity. The choice to layer was a choice to un-bundle it.

"Mr. Biscuit" — who gave two of the more memorable talks of the conference — pushed the idea further with contextual-aware components that morph. Categorize components by function, merge same-function variants, stack contextual collections (mode → state → panel). The goal is to make it impossible for either a human or an LLM to pick the wrong one because the choice has been encoded in context, not in a variant grid. His "Pit of Death" framing for what happens when vibe coding meets an undocumented system is the most useful diagnostic vocabulary I picked up all day.

Yesenia Perez-Cruz, formerly of Shopify Polaris and the author of Expressive Design Systems, made the most ambitious version of the same argument. Today's UI is a form, and design systems answer "what component?" instead of "what's the best experience for this user, now?" Her proposal — product primitives + surfaces — treats the product object (a discount, an order) as the underlying material, not the components rendered around it. Her demo, with Claude generating a coherent novel component to fit a brief, was the moment in the conference that felt furthest into the future.

Romina from designsystem.guide compressed all of this into the line I think will outlast the conference: "Plant seeds, not trees. Structure before automation." Nate Baldwin from Adobe Spectrum (creator of Leonardo) said it with a different metaphor — "Find the path before you pave the road" — and showed his Branch & Burn method of sloppy throwaway AI exploration to surface the questions you didn't know to ask.

The thread under all of this is the same. The discipline isn't to give the agent more. It's to give it less, in a shape it can actually use.

Theme 4 — Governance stopped being a luxury and became an output

The framing shift that hit me hardest came from Cristian Mendez at Nara: governance used to be a luxury, and now it's an output. He cited Zero Height's data — most design system teams have 3–5 people, 60% have no token automation — to make the structural point that governance has historically been the first thing dropped because the budget doesn't survive contact with reality. AI changes the math. Cristian ran a full Claude-based design system health report for twenty cents, against a comparable tool costing $169 a month. The point isn't the savings. It's that something that used to be quarterly is now ambient.

Andresa and Eddie at Miro told a sharper version of the same story. Their leadership rated their docs work "4/10 impact" — until they translated that work into numbers leadership felt. One of their skills compressed an icon-search workflow from 33,000 tokens to 410. Their Aura MCP dropped support questions by 70–80%. "You don't need a perfect system — one legible enough to teach." That last line is the cleanest statement of design-system maturity I've heard in years.

The closing session — Brad Frost, Ian Frost, and TJ Pitre — was the conference's loudest argument that this is structural, not incidental. Their FigmaLint demo moved a file from 26% to 100% on its design contract with one-click fixes, and then exported that contract as Markdown and JSON for the next step in the pipeline. Their Figma Console MCP reads and writes Figma — they generated a "Lavender" theme across React Native, Storybook, and Figma in minutes; ran a design-↔-code parity check that produced a ticket where the source-of-truth disagreed with itself. "Connected systems turn multi-million-dollar rebrands into a finger-snap."

The phrase that bridged Theme 1 and Theme 4 — said almost identically by Jesse Gardner and the Brad/Ian/TJ closing — was this: code generation is a commodity; trustworthy implementation is not. That's the line I keep returning to. The thing the conference was quietly building, across all four themes, is the infrastructure of trustworthiness. Tokens, docs, contracts, audits, MCPs, skills, rules. Most of it boring. All of it, finally, load-bearing.

The through-line nobody named on stage

The theme everyone was circling but nobody quite put on a slide is this: AI is forcing the discipline of design systems to finally live up to what it always claimed to be. Structured. Documented. Tokenized. Versioned. Governed. The line that came back to me in different mouths all day was a variant of "don't fight AI — onboard it. You wrote the rules." Said by Andresa, by Romina, by Diana, in different words.

Which is, if you sit with it, a strangely tender claim. Every shortcut your team got away with for ten years — the undocumented decisions, the rules that lived only in muscle memory, the tokens that drifted from their source, the components nobody owned anymore — is now amplified by a tireless, literal, fast machine that will do exactly what you actually documented, not what you meant. The conference was, in a real sense, a love letter to the boring work. The structured docs. The named tokens. The explicit rules. The unglamorous discipline nobody ever got promoted for.

The teams winning at this aren't the ones with the cleverest prompts or the most exotic agents. They're the ones who quietly went back and did the work the discipline has been claiming to do since Atomic Design — and built the muscle to keep doing it as the system breathes. Eighteen talks. Four themes. One conclusion arrived at independently across companies that have no reason to agree with each other:

AI will faithfully build whatever you actually built. That fact changes everything, and almost nothing.