The Taste Tax
AI made execution cheap. Now judgment is the bottleneck.
AI did not remove the need for product judgment.
It removed the excuse for not having any.
When agents can produce five flows, three prototypes, two launch plans, and a passable landing page by Friday, the hard question changes. It is no longer “Can we build it?” It is “Which version is worth shipping?”
That scarce work is taste.
By taste, I do not mean aesthetics. I mean product discrimination: the ability to tell useful from noisy, sharp from generic, finished from merely working, and necessary from extra.
The taste tax is the bill that comes due when execution gets cheap.
When building gets cheap, choosing gets exposed
At Notion, the AI shift did not start with designers making prettier static mocks.
It moved the work into a shared prototype playground.
Brian Lovin, a designer on Notion AI, built an environment where designers could turn ideas into working prototypes with Claude Code. The point was not that every designer should become an engineer. The point was that AI products are hard to judge from static screens.
You have to feel the system behave.
A prototype that answers can still be wrong. It can use the wrong tone. It can hide the moment where trust breaks. It can complete the task and still feel generic in the user’s hands.
That is the right scene for the taste tax.
AI made the first version cheaper. It did not decide whether the interaction was good.
The new bottleneck is not making the artifact.
It is judging it while there is still time to change it.
Taste is not decoration
Taste is often treated as a soft word. That makes it easy to ignore.
Do not ignore it.
Taste is the operating standard underneath product work:
What should we cut?
What should we polish?
What should we call this?
Which version helps the user think less?
Where does the feature cross from useful into trying too hard?
What would make this feel like us if the logo disappeared?
Those are not decoration questions. They are product questions.
Before AI, weak taste was partially hidden by execution cost. Building was expensive, so fewer bad ideas made it all the way to users.
Now the gate is lower.
Bad taste ships faster too.
The failure mode is generic abundance
The first-order effect of AI is more output.
More drafts. More screens. More tests. More strategy docs. More prototypes. More “pretty good” versions of almost everything.
That sounds like leverage. Sometimes it is.
But abundance has a failure mode: teams stop discriminating. The roadmap only adds. The interface gets busier. The product starts to look like every other product built with the same models, the same templates, and the same unwillingness to say no.
This is the taste tax in the wild:
The team can name twenty things to build and nothing to remove.
“The model wrote it” becomes a defense.
Code review catches bugs but not mediocrity.
The definition of done ends at “it works.”
Nobody can name a product they admire and explain the standard behind it.
The product is not broken.
That is the problem. Broken work gets fixed. Generic work gets shipped.
The signal is what the team refuses
The easiest way to see taste is to ask what the team refused.
A team with taste can show you the versions they rejected. They can explain why a feature was removed, why a label changed, why one interaction got another hour and another got killed.
A team without taste can only show you the output.
This is why “move fast” became more dangerous in the agent era. Speed without discrimination converges to the mean. If everyone has access to similar generation tools, the difference is not who can produce more.
The difference is who can choose better.
James Bessen’s work on automation points to the broader pattern: technology often shifts work rather than simply removing it. When the task gets cheap, the judgment around the task becomes more valuable.
The artifact got cheaper.
The standard did not.
Install a quality bar, not a taste lecture
Do not tell teams to “have better taste.” That is not a process.
Make the standard visible at the moment work is about to ship.
Use one review with three questions:
What did we refuse? Tests whether the team can cut. A good answer names a rejected version, feature, message, workflow, or interaction — with a clear reason.
What did we elevate? Tests whether the team improved beyond “it works.” A good answer names one change that made the output clearer, simpler, safer, more useful, or more distinctive.
What standard did we apply? Tests whether taste is shared or personal. A good answer is a reusable principle the next team can apply without the original reviewer in the room.
This keeps the advice industry-agnostic. The artifact might be a product flow, pricing change, policy answer, data workflow, onboarding moment, service script, or internal tool. The standard is the same: the team can explain why this version deserves to exist.
Over time, save the best answers. That becomes the team’s taste library: not a mood board, but a record of good decisions.
What changes Monday
Pick one AI-assisted feature your team is about to ship.
Do one thing before launch: run a refusal review.
The launch decision should not be: “Does it work?”
It should be:
Can the team explain what it refused, what it elevated, and what standard it used?
If the answer is mostly silence, do not call the work finished.
Call it generated.
The market will not punish you because your team is slow.
It will punish you because everyone is fast now, and your product looks like theirs.
Sources
Lenny’s Newsletter — I haven’t written a single line of code in six months: https://www.lennysnewsletter.com/p/i-havent-written-a-single-line-of
Lenny’s Newsletter — Why cultivating agency matters more than cultivating skills: https://www.lennysnewsletter.com/p/why-cultivating-agency-matters-more
James Bessen — Toil and Technology: https://www.imf.org/external/pubs/ft/fandd/2015/03/bessen.htm
Paul Graham — Taste for Makers: https://www.paulgraham.com/taste.html