Taste is trained judgment

At TENEX, we’re building an AI-native, human-led security platform that triages alerts, investigates threats, and helps security teams respond. Lately, I’ve been using AI to help build the product, and I’ve been surprised by how quickly it can create something that looks finished.

I saw this while working on an investigation workflow. It worked. An analyst could complete the job, and at first glance, the workflow looked done.

Then I looked closer.

There were icons that didn’t explain anything, form fields without labels, and patterns that didn’t match the rest of the product. A major form lived inside a dialog, where pressing Escape or clicking outside could cause someone to lose their work.

None of those problems necessarily stopped the workflow from functioning. Together, they were the difference between something that worked and something I’d consider good.

Our CEO, Eric Foster, says it plainly: AI handles the volume. Humans handle the judgment. I’ve found that the same idea applies when we’re building the product itself.

That gap is probably why we’re talking about taste again. Some people are calling taste a new core skill for the AI era. Designers have been working with the same idea for much longer. Both can be true: AI didn’t create the need for taste. It made the need harder to ignore.

I don’t know that I ever thought taste was innate, but I didn’t understand how much it could be developed. The more product and logo work I’ve done, and the more AI-generated work I’ve reviewed, the clearer that has become.

The mistake is treating taste like a mystical trait—like some people are born with it and everyone else is out of luck.

Taste is not preference

Preference is personal. Taste is judgment.

The distinction matters because preference ends the conversation. “I like it” and “I don’t like it” can both be true, but they don’t give a product team or organization much to work with. Taste has to go further. It has to explain why something works, why something doesn’t, and what would make it better.

Preference says:

I like this card layout.

Taste says:

This card layout works because the hierarchy matches the user’s decision path. The most important information is scannable first, the secondary details are available without competing, and the action is placed where the user naturally expects to act.

Two very different critiques.

PreferenceJudgment

Investigation queue

12 open

Prioritized identity risk signals

Impossible travel

Frank Stallone · 4 minutes ago

Critical

Unfamiliar sign-in

Ada Lovelace · 9 min

Open investigation

I like this card layout.

True, maybe. But there is nowhere for the conversation to go.

Logo design works the same way. “I like this mark” doesn’t tell us whether it identifies the organization without trying to communicate everything the organization does. It doesn’t tell us whether the mark is appropriate, distinctive, or simple enough to work on a sign, an app icon, or a pin. Those are reasons a team can examine and use.

“I like it” doesn’t scale. Teams and organizations can scale reasoning, shared language, and principles. But if taste stays trapped inside personal preference, every design conversation becomes a debate over vibes.

That’s where design conversations get stuck. “Can we make this pop?” “It feels too flat.” “Can we add more color?” None of those reactions are wrong, exactly. They’re just incomplete.

When someone asks to make something pop, I want to know what problem they’re actually seeing. Is the next action too easy to miss? Is the hierarchy causing hesitation? Those are problems we can work on. More color might be the answer, but now we have a reason for using it.

Logo critiques need the same move. Is the mark hard to recognize, or is it trying to communicate too much? “Make it more iconic” isn’t useful direction until we can explain what’s getting in the way.

That’s when taste gets useful. It gives the reaction somewhere to go.

David Hume wrote about taste as something improved through practice and comparison in Of the Standard of Taste. That’s the version I mean here. Not personality or instinct alone. Judgment built through exposure, comparison, critique, and repetition.

Before you can judge, you have to see

Developing taste starts with learning to see. That sounds obvious, but I still catch myself recognizing what’s in front of me without really looking at it. I glance. I categorize. I move on.¹

I see the same thing when I’m reviewing AI-generated product work. A list gets a count it doesn’t need. A quiet action gets an icon. A section gets a new color just so it feels different. A dense settings area gets the same breathing room as a simple empty state. An existing component gets extra class names even though the canonical version already looks good without overrides.

Technically, the screen renders. The component works. The acceptance criteria are met. The ticket moves forward. If I’m only checking for completion, that can feel like enough.

But if I keep looking, I start to see where the eye goes first. The count pulls attention away from the list. The icon doesn’t clarify the action. The spacing works in one section but falls apart when the density changes.

That’s the gap between functional and crafted.

Josef Albers built his color courses around a simple problem: color deceives us. His students worked with pieces of colored paper, changing what surrounded them until one color looked like two different colors—or two different colors looked the same.

The point wasn’t to memorize the right combinations. It was to see how easily context changes perception, and to get better at noticing what the eye misses on its first pass.

Interfaces work the same way. A color, component, or spacing decision can look fine in isolation and feel completely wrong inside the product around it. Learning to see means slowing down long enough to notice what the interface is actually doing to the user. Not what we intended it to do. Not what the ticket says it should do. What it’s doing.

• Where did I hesitate?
• Where did my expectation break?
• Where did the page create confidence?
• Where did it create doubt?
• Where is the hierarchy helping?
• Where is the interface asking color, motion, or decoration to solve a structural problem?

These are taste questions, but they start as observation questions.

The premium bar doesn’t start with your competitors

Users don’t limit their expectations to other products in your category. The premium bar starts with every good piece of software they already use.²

That might feel unfair. It doesn’t matter. 😅

The user doesn’t lower their expectations because your domain is complex. They don’t say, “This is enterprise software, so confusing hierarchy is acceptable.” They simply feel the drag.

They may not know how to name it. They may not tell you the typography feels uncertain, the spacing feels accidental, the interaction feels generic, or the action model feels misaligned. They will just trust the product a little less.

That’s probably not fair to the engineering underneath. I’ve seen fantastically engineered systems hidden behind mediocre interfaces. But users don’t experience your architecture diagram. They experience the surface area you give them.

That surface area has a lot of trust to earn. I try to treat the industry standard as the floor, not the ceiling.

That doesn’t mean every product should look like the same modern SaaS template. That’s part of the AI era problem. The tools are very good at producing generic competence. Rounded cards. Soft shadows. “Pleasant” gradients. Balanced grids. A little badge in the corner that says “New.”

It all looks fine. But fine can hide weak judgment.

I wrote a little about this in AI is very good at adding. Design is required to subtract. The next post in this series is about craft, so I won’t go too far down the subtraction path here. For now, I think of taste as the thing that helps you decide whether the polished output deserves to stay.

I was the dependency

Andrej Karpathy makes a useful distinction between vibe coding and agentic engineering. Vibe coding raises the floor. More people can make working software. Agentic engineering is about preserving the quality bar while moving faster. The agents can produce the code, but the engineer is still responsible for the security, architecture, and whether the thing is any good.

I think design is running into the same problem. LLMs can raise the floor, but the average thing they produce is not the premium bar. Designers and engineers develop tacit knowledge from doing the work repeatedly. That knowledge helps us recognize the little things that make something feel unresolved, even when it technically works.

When I first presented these ideas, I was the only designer working with six-plus agentic engineers at a young startup. They could create functional features faster than I could review them.

I was the dependency.

Honestly, I didn’t scale well enough to serve the team. I could look at a workflow and say it hadn’t cleared the premium bar, or that the design wasn’t resolved yet. I knew what I meant. But too much of the reasoning still lived in my head, so the work had to come through me before that judgment became useful.

I wanted to turn our brand attributes into quality filters so the team had language for what was working, what was missing, and what needed more attention.³

We don’t use that language internally yet. I want to be honest about that. It was the intention, and I still think the idea is right.

I still use “premium bar” and “resolved” when I’m reviewing work. Those words point at something real, but they’re only useful if I can explain what I see and why it matters.

That’s the part I didn’t do well enough. I could see the gap, but I hadn’t given the team enough language to see it with me.

The point isn’t to turn taste into a checklist. It’s to make the judgment useful before everything has to come through one person.

The more clearly we see, the more clearly we can decide.

Footnotes

1. This section was inspired by Josh Puckett’s excellent Noticing lesson from Interface Craft. ↩

2. The framing here was inspired by Josh Puckett’s excellent Industry Standards lesson from Interface Craft. ↩

3. The quality filters were inspired in part by Josh Puckett’s excellent Facets of Quality lesson from Interface Craft. ↩