Taste and discernment

The cost of making a change is dropping. Last year, updating a token meant hand-editing .json files. Now it's a prompt. Every day there's new tooling, better abstractions, faster pipelines, all of it compressing the distance between "we should do this" and "it's done." Agents speed things up even more.

This sounds like pure upside. For production throughput, it is. But it brings a problem most teams aren't talking about yet: when everything is cheap to build, how do you decide what's worth building?

In design systems, that question is existential.

The flood

Design systems have always been a practice of restraint. The whole point is to say: out of the infinite ways you could build this, here are the three we've decided are right.

That restraint is what makes a system useful. It's why a team can move fast: fewer options to weigh, fewer decisions to relitigate.

When the cost of change drops, restraint gets harder. If spinning up a new variant takes 5 minutes instead of 5 hours, the argument against it weakens. "Why not add it?" sounds reasonable when production cost is negligible.

So every edge case gets its own component. Every team's preference gets accommodated. The system grows on cheapness alone.

I've watched this happen. The easier it gets to ship, the more changes get proposed. The volume of possible work drowns out the work that actually matters.

The backlog fills with things that are technically justifiable and strategically meaningless. This is where taste and discernment stop being nice-to-haves and become prerequisites.

Taste is pattern recognition

Taste gets a bad reputation in technical work. It sounds subjective, aesthetic, the thing designers argue about over typefaces. In practice it's pattern recognition built through reps.

It's the ability to look at a component API and know it's going to cause problems before anyone files a bug. It's reading a token scale and sensing that the steps are too close together to be useful at the edges. It's seeing a proposed variant and understanding that it'll create confusion downstream, even though it solves the immediate ask.

Taste is having enough reps to recognize what "right" looks like, and enough conviction to hold that line when the cost of saying yes is almost zero.

The cheaper changes become, the more taste matters. Because the question is no longer "can we build this?" It's "should we?"

Discernment is the edit

If taste is recognizing quality, discernment is prioritization under abundance.

An agent can generate five approaches in the time it used to take to stub out one. It can refactor a component three ways, each technically sound. It can propose token structures, write docs, scaffold variants.

The output is real, and often good enough.

But "good enough" is the trap. Discernment is looking at that output and knowing which version actually fits: the codebase, the system's philosophy, the team's capacity, the consumer's mental model.

It's editing in the deepest sense. Cutting what doesn't belong, however well-made it is.

In design systems this shows up constantly. A well-intentioned contribution that adds complexity without clarity. A refactor that's technically cleaner and harder to learn. A new pattern that solves one team's problem and creates ambiguity for everyone else.

Each one is easy to ship. The hard part is seeing why you shouldn't.

Discernment is sifting through the arbitrary to find the work that actually lands. That skill gets more critical as the volume of potential work climbs.

The bottleneck is judgment

For a long time, the prerequisite for doing this work was production skill. Can you write the code? Can you build the component? Can you set up the token architecture? If yes, you're in. If not, go learn.

That floor is shifting. Production skill still matters; you need to understand what you're evaluating. But it's no longer the bottleneck. The bottleneck is judgment.

The person who can prompt an agent to generate a full component library in an afternoon but can't tell which of those components should exist isn't moving the system forward. They're adding noise.

The person who looks at that same output and says "these 3, not those 7, and here's why" is running the system.

This is about being deliberate. The speed of production has outpaced the speed of evaluation, and that gap is where bad systems get built. Fast, technically correct, and wrong.

The apprenticeship problem

Taste is built by doing the work. You learn what a good API feels like by building bad ones. You develop an eye for token scales by using scales that fail. You understand restraint because you've lived through the consequences of not having it.

If agents handle more of the production work, where does the next generation of practitioners build that instinct? How does a junior designer develop taste for component design if they're evaluating agent output instead of pushing through the hard parts themselves?

The path forward is teaching with more intention. How to evaluate what tools produce. How to judge whether a component should exist at all.

Critique as a core skill, not a soft one.

The mentorship model has to shift from "let me show you how to build this" to "let me show you how to tell if this is good." That's harder to teach. It's also the thing that will matter.

Holding the line

Design systems are, at heart, an exercise in saying no. No, we don't need to change that font weight. No, that component doesn't belong in the shared library. No, that shortcut will cost more than it saves.

When the cost of saying yes drops to nearly zero, the discipline of saying no becomes the most valuable skill on the team. Undisciplined change is how systems rot: slowly, one reasonable-sounding addition at a time, until the system serves nobody well.

Taste is how you see it coming. Discernment is how you stop it. Neither can be automated. They take the kind of accumulated judgment that only comes from caring about the work long enough to develop a point of view.

The agents will keep getting better at building. The question is whether we'll get better at knowing what to build.