Design Systems need a new Paradigm

Recently, I joined a startup as a Founding Designer and made a few observations.

• Agents are writing a lot of our code, in fact almost all of it.
• Understanding is the bottleneck

In the industry, software engineers have mostly solved how to create skills and guardrails that keep code quality high. Progress at the frontier of this problem is extremely quick, because top class engineers who are AI-pilled are desperate to solve it. When we look at design however, the standard has not been set. This is because ultimately, design systems have always been owned by designers but implemented by engineers.

What is a Design System

A design system is a creativity pipeline that starts in the designer's mind and ends in all external surfaces. When a designer decides to modify a primary color in the system, the pipeline must carry that through and ensure that all systems update accordingly and accept this as a new source of truth from that point onward.

In code bases, design systems create a living, breathing library of intentional design decisions written as code.

A button isn't a specific blue because that blue looked nice on a Tuesday. It's that specific shade because someone wanted to convey emotion, emphasize visual identity, increase accessibility and much more. It's the system's job to structure that intent into something machine digestable.

Taste is a context problem (sort of)

For most of the last decade, the handoff workflow paradigm was this: designer makes a decision in Figma, engineer reads the file, engineer writes the code. It was slow and lossy, but there layer of human judgement that could ask the write questions. That human is mostly gone now, and the new implementer is an agent.

The next paradigm was source control. Figma offered a great feature for designers to use token variables, which could be exported as .json. This simplified things, as now designers had a way to ensure the developers received their work properly.

Agents don't sit in design crits. They don't absorb taste by osmosis over six months of Slack threads. They read what is in the repo and they act on it. If a design decision isn't written down in a place the agent can see, it doesn't exist. And if it's written down loosely, the agent will fill the gaps with the most average version of a UI it has ever seen.

This is why understanding is the bottleneck. The agent can write the code in seconds. What it can't do is understand why the code should look a certain way, unless we tell it.

Design Systems Need to Be Fluid

At a startup, the product changes every week. The design system has to change with it.

The old model treated a design system like a monument. You spent a quarter building it, published v1, and then defended it. That works when change is expensive. When an agent can rebuild a whole surface in an afternoon, a rigid system becomes the thing everyone works around instead of with. Fluid doesn't mean loose. It means the system is cheap to change in the right places. Updating a token should ripple everywhere in one commit. Adding a new pattern should take minutes, not a review cycle. The system should feel less like a rulebook and more like a shared vocabulary that grows as the product does.

Design Systems Need to Be Bidirectional

The pipeline I described earlier only flows one way: designer to code. That's no longer enough.

Agents and engineers are creating UI faster than any designer can review it. Some of what they make is drift, a hardcoded hex value or a one-off margin. But some of it is genuinely good. A new empty state, a better loading pattern, a table layout that solves a real problem. If the system only flows downstream, those good ideas stay stranded in one corner of the codebase.

A bidirectional system flows back up. It notices when something new appears in code, surfaces it to the designer, and asks a simple question: is this a mistake, or is this the new standard? If it's a mistake, it gets fixed. If it's the standard, it gets promoted into the system and becomes available everywhere.

This changes the designer's role. Instead of being the only source of decisions, the designer becomes the editor of decisions. Code becomes a source of truth the design tool reflects, not just the other way around.

Guardrails Without Killing Creativity

Here's the tension. Give an agent no rules and every screen looks like a different product. Give it too many and every screen looks like the same template. The way I think about it: constrain the vocabulary, not the sentence. The vocabulary is visual styling. Color, type scale, spacing, radius, elevation, motion. These should be locked down hard. An agent should never invent a new shade of grey or a 13px margin. If it reaches for a raw value, something should catch it before it ships. The sentence is composition. How a page is laid out, how a flow is sequenced, how information is prioritized on a screen. This is where agents should have room to try things. Some of their attempts will be bad. Some will be better than what I would have drawn. Either way, because they're built from the same vocabulary, they'll still feel like they belong to the same product. Guardrails also need to explain themselves. "Use color.accent" is a rule. "Accent is reserved for the single most important action on a screen" is intent. Agents follow rules, but they generalize from intent. The second version is what keeps an agent from putting three accent buttons on one page. What This Looks Like in Practice This is still early, and we're figuring it out as we go. But a few things have worked for us so far. • Tokens are the only source of visual values. No raw hex, px, or font sizes in component code. A lint rule flags anything that slips through. • A design skill the agents read before touching UI. It explains the why behind the system: what each color means, when to use which density, what our product should feel like. Short and opinionated beats long and exhaustive. • Screenshots in every UI change. If an agent changes something visual, the PR includes before and after. I review pixels, not diffs. • A drift report. Periodically, an agent scans the codebase for new patterns and one-offs and lists them for me. I mark each one as fix or promote. • A fast promotion path. When something gets promoted, it becomes a real component with tokens and docs in the same day, so the next agent can use it.

Understanding Is Still the Bottleneck

Engineers figured out that the way to get great code from agents is to give them great context. Design is no different. The difference is that design context has always lived in people's heads, in Figma comments, in the conversation after the meeting.

The job of a designer in this world is not to draw every screen. It's to encode intent so clearly that an agent can draw a screen I would have been proud of, and to keep that intent alive as the product moves.

A design system that is fluid, bidirectional, and opinionated about style but open about composition is how we get there. We haven't set the standard yet. But the designers who figure this out first are going to shape what every product looks like for the next decade.