The point of a system is fewer decisions

I’ve been building a design system with an AI agent lately, and every now and then I have a slightly uncomfortable thought: why are they paying me to do this?

I’ll spend some time deciding how I want something structured, explain it to the agent, and watch it do an amount of work that would have taken me considerably longer a couple of years ago. Create the variables, bind everything correctly, generate reference pages, rename a hundred things, check for broken aliases. Done.

It can feel suspiciously easy. Usually the feeling passes as soon as I start reviewing the choices the agent has made. Some are perfectly reasonable. Some are wrong in ways that would be hard to spot without having done this work for a long time.

That distinction has made me think differently about what the work actually is.

A design system is really a decision system

AI can produce a surprising amount of the visible system now. Components, tokens, documentation, reference pages. But most of the difficult work happens before any of that gets built.

Are these two components actually different, or have they just drifted apart over time? Does this use case deserve another variant? Should this token describe a color or an intention? Is this flexibility useful, or are we preserving an exception simply because it already exists? And perhaps most importantly: should this thing be part of the system at all?

I’ve started thinking that consistency is less the purpose of a design system than a consequence of one. The real point is to reduce the number of decisions people and agents have to make repeatedly.

If every designer has to remember which green means success, the system hasn’t done its job. If an engineer has to inspect three nearly identical components and decide which one is appropriate, the system hasn’t done its job either. A good system takes a decision that shouldn’t need to be made repeatedly and makes it once.

Not everything needs to become a component

This matters even more now because AI makes systemization cheap. You can take almost anything on a page and turn it into a component, then create its properties, variants, tokens and documentation in minutes. The constraint is no longer how tedious it would be to build, which makes deciding what not to systematize more important.

Lately I’ve been using a simple filter before adding anything to a system. Does it show up often enough to deserve a shared solution? Does it have behavior or states that need to stay consistent? Is there an actual rule here that we want to encode rather than leave to individual judgment? And, just as importantly, is this something someone is willing to own over time?

The third question is the one I keep coming back to. Repetition alone isn’t enough. Something becomes valuable as part of a system when it captures a decision we don’t want humans or agents to keep making independently.

That decision might concern interaction behavior, accessibility, spacing, content structure, which variants are valid, or which combinations should never exist. Once the rule is encoded, every person and every agent using the system gets to stop thinking about it.

We’re building systems for humans and agents now

This is the part that feels genuinely new to me. Design systems have always encoded shared knowledge: instead of expecting every designer and engineer to remember how something should work, we put that knowledge into components, tokens, documentation and conventions. For most of their history, though, the audience was human.

Agents are starting to consume the same systems. They’re selecting components, writing interfaces, translating designs into code and making decisions based on whatever information we’ve given them. Things that used to feel like good design-system hygiene are starting to look more like infrastructure for two equally important audiences.

Take naming. green-600 tells you what something looks like. text/success tells you what it’s for. A designer with years of context may know which green is appropriate, and an engineer may remember which one the team normally uses, but an agent only has the system in front of it.

The more intent the system contains, the less any of its users have to infer. Semantic naming is not just a preference in that context; it carries the decision across design, code and the agents working between them. That clarity helps people too, but agents expose just how much ambiguity we’ve historically allowed humans to compensate for.

Ambiguity scales very well with AI

This is also where AI can make a bad system worse. If you have four components that perform almost the same job, an experienced designer may have enough context to know which one to use. If token names are inconsistent, someone on the team may simply remember what they mean. If a component has twelve properties but only five combinations are sensible, people gradually learn which seven to ignore.

An agent doesn’t have that institutional memory unless you give it one, and it can reproduce the ambiguity very quickly. A slightly confused designer might make one inconsistent screen; an agent can make twenty before lunch. The speed that makes agents useful also lets unclear decisions spread much further before anyone notices.

So when I’m working on systems now, I’m increasingly interested in making the intended path obvious: fewer overlapping components, fewer properties that exist “just in case,” semantic names instead of visual descriptions, and clear rules about what belongs in the system and what doesn’t. Agents don’t need a special simplified version of the design system. The things that make a system legible to an agent tend to make it better for people too.

The building isn’t where the seniority lives

This has also helped me get over some of the weirdness of having an agent do so much of the execution. Senior engineers use coding agents constantly now, but that doesn’t mean I can do the job of a senior engineer because I can ask the same agent to write code.

I wouldn’t know when the architecture was becoming unnecessarily complicated or which shortcut would become painful six months from now. I wouldn’t necessarily recognise when something technically correct was solving the wrong problem. Most importantly, I wouldn’t know which decisions deserved my attention.

The same is true in design. The valuable part isn’t manually producing 200 variables; it’s deciding which variables should exist. It isn’t drawing every component state yourself; it’s knowing which states represent meaningful product behavior and which ones are just accumulated history.

AI makes execution dramatically cheaper, but it doesn’t remove those decisions. If anything, it makes them more important because whatever you decide can now be implemented much faster.

I wrote about a related idea in How to Stand Out When Anyone Can Build Anything: as the barrier to execution falls, understanding users, business judgment, communication and craft become more important. Working with systems this way has made that idea much more concrete for me.

The interesting question is no longer how much of the system I personally built. It’s how many decisions nobody has to make again because the system already knows the answer. Increasingly, “nobody” includes the agents building from it too.