On building systems

Design is no longer just about screens. The current state of technology requires designers to think about systems.

I said before that we now need to treat code as the medium. That’s not the end of it.

With AI, our users are no longer only humans. Humans are still the most important part, of course. But agents need to be accounted for just as much. They read our files, build our screens and make choices we used to make by hand. If we design only for the person looking at the result, we leave the thing producing the result to guess.

But speed multiplies whatever is underneath it. Without a foundation, an agent scales the defaults it learned from everyone else. Anthropic’s frontend-design skill keeps a list of these and calls them “the commonest tells of a generated page.” You’ve seen them: the same fonts, the same cards inside cards, the same gradients. It works, but it doesn’t feel built.¹

AI still needs structure, grammar, taste, rules and guidelines to produce something that really feels built. That’s the job now.

Linear is a good example. When they redesigned their app, the goal was to “reduce visual noise, maintain visual alignment, and increase the hierarchy and density of navigation elements.” That isn’t a screen. It’s a rule that every screen has to follow. Karri Saarinen describes the “inverted L-shape” of the global chrome that controls the main view. Once that shape exists, new views don’t have to reinvent it.²

Stripe does the same thing in writing. Their guidance for full-page apps says: “Lead with a high-level overview and let users discover details at their own pace.” One sentence, and a hundred pages come out consistent.³

That’s what a system gives you. Not more components, but fewer decisions left to chance.

Emil Kowalski puts it simply: “Almost every ‘taste’ decision has a logical reason.” If you can explain why, you can write it down. If you can write it down, an agent can follow it.⁴

Karl Koch shows how. He turns a vague preference into three parts: when the rule applies, what he usually chooses, and how to check that it worked. He pairs each rule with the way it fails, which he calls “One principle, one test.” “Make it feel polished” becomes something you can actually test.⁵

I’ve been doing this in my own work. My design system has a grammar layer, a set of lessons about how parts combine. The first line says it plainly: “Components are the nouns. Grammar is how they combine, and why.” One lesson is about nested corners: the inner radius is the outer radius minus the padding, and a component does the maths, so nobody picks it by eye. Small rule, but it’s the kind of detail that separates built from generated. And “Agents read the same lesson files” that people do.⁶

Lauren Tan, who built pstack, says “The most critical skill to have in your toolbox is a high quality verification skill.”⁷

Her guide is blunt about it: “‘It compiles’ is not evidence.” What keeps her agents on track isn’t clever prompting. It’s structure: clear steps, small principles, and proof at the end.⁸

For design, proof means looking. Jakub Krehel built a skill that “renders any component you want in all of its states on a throwaway page with mock data.” Empty, loading, error, too long. Most bugs in an interface live in the states nobody opened.⁹

v0 takes the same approach with design systems. Their docs say a design system skill “is not a copy of your docs; it is an adapter that tells v0 where your source lives.” And they set a hard line: “If a component, prop, or token cannot be verified from the sources, v0 should not use it.” That’s a system that checks itself.¹⁰

Matt Pocock has a rule I like for working with agents: “Finding facts is your job, never the user’s.” The agent finds the facts. The decisions stay with the person. In design, that means the agent can build five directions, test every state and check every rule. Choosing which direction is right is still ours.¹¹

So the work changes. Less time pushing pixels on one screen. More time deciding what should be true on every screen, writing it down, and making sure it can be checked.

If we want software that feels built, we have to build the thing underneath: the structure, the grammar, the rules and the checks. Agents will scale whatever we give them. That’s why systems matter so much now. Give them something worth scaling.