Taste Is All That's Left

Published: August 6, 2026 | Read Time: $\approx 16$ minutes Tags: #thoughts #programming #software

📝 Post Mortem

Wait, before you dive in...

I've been told this piece made it to the front page of Hacker News. Looking at the feedback, it seems some readers feel the prose reads like "AI slop." If that bothers you, please take a moment to read the post-mortem section below to understand the human intent behind these words.

The Collapse of the Wall

For the duration of my career in software—which is modest compared to some of you—I operated under the assumption that the primary challenge was simply making the thing exist.

The journey of building web applications used to be a grueling, often tedious slog. The process looked like this:

Formulate an idea.
Spend hours (or weeks) typing.
Pore over dense manuals.
Misinterpret an API.
~~Fail repeatedly~~ $\rightarrow$ Slowly iterate a "wrong" version into one that was "slightly less wrong."

This friction was the Great Divider. It separated the people who could actually execute from those who merely talked about execution.

The New Distance

Today, you can describe a concept and receive a plausible implementation faster than you could have written a single function() { ... } by hand. We can express the "Idea-to-Artifact Distance" as a mathematical collapse:

$\lim_{\text{AI} \to \infty} (\text{Idea} \rightarrow \text{Artifact}) = 0$

The wall that once defined the craft has vanished. However, there is a hidden truth: the value gained from learning to climb that wall hasn't disappeared; it has just changed form.

Where the Bar Shifted

We often debate whether AI is "reliable." Some call it reliably unreliable. But I believe we are asking the wrong question. The real issue is that the output is "good enough."

Historically, the high cost of production acted as a silent guardian.

Era	Production Cost	The "Filter"	Result
Pre-AI	High (Time/Effort)	Effort filtered out mediocrity.	Only things that survived the cost were shipped.
Post-AI	Low (Near Zero)	No inherent cost filter.	A thousand mediocre variations can be shipped instantly.

When the "floor" of production cost drops, the deciding factor for what is worth keeping is no longer the expense of creation. Instead, it becomes a specific type of judgment.

When you are presented with three plausible versions of a function and you instinctively know that two are wrong—despite them "working"—you are exercising something we rarely discuss in engineering because it sounds too subjective or "aristocratic."

We call it Taste.

Defining "Taste"

I want to be precise here. "Taste" isn't just about aesthetics or decoration.

Robert Pirsig spent an entire book avoiding a formal definition of "Quality" because he believed defining it would destroy it. His core premise was that we recognize Quality before we can explain it. The intuition precedes the justification.

This manifests in various crafts:

The Mechanic: Knows the engine sounds "off" before diagnosing the specific valve.
The Editor: Feels a sentence "sag" before identifying the faulty clause.

In programming, taste is the compressed, wordless verdict. It is the internal voice that says: "No, try again."

It is the only part of the process that was never mechanical. While the syntax, the wiring, and the typing were always automatable, the verdict was not.

Taste Is the Child of Friction

This is the uncomfortable part. You cannot acquire taste through osmosis. You cannot become a master chef simply by eating at Michelin-starred restaurants, nor can you gain judgment by reading a hundred perfect repositories.

Taste is built through the "slow, stupid, and humiliating" process of failure.

Every frustrating wall I hit while learning was secretly teaching me which walls were worth climbing. The cost that limited my output was the same mechanism that educated my judgment.

The Apprenticeship Gap

Now, consider the new developer. They are provided a competent version of a feature for free.

They don't ship the "bad" version.
They aren't forced to live with the failure.
They skip the climb entirely.

They achieve fluency without the apprenticeship. By every measurable metric—tickets closed, lines of code, speed of delivery—they are more productive than I was.

The Tragedy: They can make anything, but they lack the internal compass to know if they should.

The Invisible Cost

If you have paid the "full price" of learning, you can feel the sag in the code. You and the novice now ship at the same speed because the tool is the same. But your internal checklist is different:

Does it run? (Plausible)
Does it pass tests? (Plausible)
Is it right? (Taste)

The person without taste sees the first two checks and closes the ticket. You see the third check is missing and send the work back.

This is a quiet cruelty.

The market uses the same stopwatch for both of you. It does not see the difference because:

The novice has already moved on.
The disasters you prevented leave no trace.

You carry a hidden tax: the extra hours, the rejected drafts, and the insistence on a quality that is unmeasurable on a dashboard.