Taste and discernment

The cost of making a change is dropping. Last year, I was manually editing .json to update one or two tokens that our design system needed. Today, every day, there's new tooling, better abstractions, faster pipelines — all of it is compressing the distance between "we should do this" and "it's done." Agents accelerate that curve dramatically.

What used to take a sprint takes an afternoon. What used to take an afternoon takes a prompt.

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

In design systems, this 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 that we've decided are right. That restraint is what makes a system useful. It's the reason a team can move fast — not because they have more options, but because they have fewer.

When the cost of change drops, restraint gets harder. If spinning up a new variant takes five minutes instead of five hours, the argument against it weakens. "Why not add it?" becomes a reasonable question when the production cost is negligible. Every edge case gets its own component. Every team's preference gets accommodated. The system grows, not because it should, but because it can.

I've watched this happen. The easier it gets to ship a change, the more changes get proposed. And the volume of possible work starts to drown out the work that would actually move the needle. The backlog fills up with things that are technically justifiable but strategically meaningless.

This is where taste and discernment stop being nice-to-haves and become prerequisites.

Taste isn't preference

Taste gets a bad reputation in technical work. It sounds subjective, aesthetic — something designers argue about over typefaces. But taste, in practice, is pattern recognition built through experience.

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 isn't about liking or disliking something. It's about 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 to a problem in the time it used to take to stub out one. It can refactor a component three different ways, each technically sound. It can propose token structures, write documentation, scaffold variants. The output is real and often good enough.

But "good enough" is the trap. Discernment is the ability to look at that output and know which version actually fits — not just the codebase, but the system's philosophy, the team's capacity, the consumer's mental model. It's editing, in the deepest sense. Not fixing typos, but cutting the things that don't belong, no matter how well-made they are.

In design systems, this shows up constantly. A well-intentioned contribution that adds complexity without adding clarity. A refactor that's technically cleaner but makes the API harder to learn. A new pattern that solves one team's problem while creating ambiguity for everyone else. Each of these is easy to ship. The hard part is seeing why you shouldn't.

Discernment is sifting through the arbitrary to find the work that will actually make an impact. And that skill becomes more critical as the volume of potential work increases.

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 actually exist is not moving the system forward. They're adding noise. The person who can look at that same output and say "these three, not those seven, and here's why" — that person is running the system.

This isn't about being slow or cautious. It's about being deliberate. The speed of production has outpaced the speed of evaluation, and the gap between those two is where bad systems get built. Fast, technically correct, and wrong.

The apprenticeship problem

Taste is developed through 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 don't work. You understand why restraint matters 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 being more intentional about what we're teaching. Not just how to use tools, but how to evaluate what tools produce. Not just how to build a component, but how to know whether it should exist.

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 a harder thing to teach. But it's the thing that will matter.

Holding the line

Design systems are, at their core, 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 us 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. Not because change is bad, but because 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 prevent it. Neither of those can be automated — they require 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.