AI forgets your taste between sessions. Write it down
Ask a model for a card and you get one that looks finished: rounded corners, a soft shadow, 24 pixels of padding, a hardcoded white background. It also looks like every other card on the internet — because the training set is the median of public design, and the model samples what is most probable. Accept the first pass and you ship that median. That is less a failure of the model than a failure of review. Taste is the work after generation. I have written that your eval set is your taste, made measurable; a review rubric is its sibling — written criteria that let you catch the generic pass in ten seconds instead of shipping it.
Why does every AI output look the same?
The reason is mechanical, not mystical. Researchers call it typicality bias: models are rewarded during alignment for familiar outputs, so they drift toward whatever is most typical in their data. For frontends, the most typical modern UI is a Tailwind-plus-shadcn SaaS layout with rounded cards and an indigo accent. There is no counter-signal unless you provide it.
Even the labs building the models admit it. Anthropic's own published frontend-design skill bans Inter, bans purple gradients, and forces an extreme aesthetic posture before a line of code is written — because they know Claude's default is the same safe, predictable layout everyone else gets. If the model maker ships anti-default rules, the default is real.
What is taste, if not the generation?
Taste is not what the model produces. It is the pass after generation — when you read the output, name what is wrong, and change it before anyone else has to live with the draft. That is why vague feedback fails. "Make it nicer" sends the model straight back into the same average, because there is no fix to target. A concrete criterion gives it something to fail against, and "this fails the check" is a much better instruction than "this feels off."
What should a review rubric actually check?
I keep mine to five checks, and each maps to a specific decision instead of a vibe:
- Semantics — is this a native control, or a div pretending to be one?
- Tokens — are the colors, radii, and elevation referenced, or hardcoded hex values?
- Spacing — does the padding sit on the scale you already use?
- Motion — springs and interruptible transforms, not
transition: all 300ms linear. - System fit — would this survive dark mode, reduced motion, and the components it sits next to?
The generated draft can stay as scaffolding. The bar for what leaves your machine is just higher. Five lines of criteria turn taste into an exit condition: you stop asking "is this good?" and start asking "did it pass?"
Where should taste live so AI can read it?
This is the part that compounds. Models forget your taste the moment the session ends; files keep it. Write the rubric into a pull-request checklist, a design-lint rule, or a SKILL.md in your repo, and every future chat starts with the same bar instead of re-discovering it.
The big tool makers already bet on this. Vercel's explainer on AI-native design systems is the same move: map your tokens once, and v0 starts every generation from your brand instead of its own default. Structure comes from the component library; appearance comes from your tokens. Without your tokens, you get their defaults, which are everyone's defaults.
Is a written rubric worth it for a solo builder?
More worth it. You are the only reviewer on the team, so the scarce asset is how fast you can catch the generic pass. One file changes what "most likely" means: the most probable output stops being the corpus mean and starts being your brand. The model is still doing maximum likelihood — you have just changed the distribution. First-pass quality goes up, revision count drops, and the file keeps working on the days your own taste is tired.
Treat the first preview as a hypothesis, not a verdict. Read it, score it against the five checks, fix the failures, and ship only the version that survives your own review. The scarce skill in 2026 is not generation. It is the pass after.
Frequently asked questions
Typicality bias. Models are rewarded during training and alignment for familiar outputs, so without counter-signal they converge on the most probable continuation in their data — and for frontends the most typical modern UI is the rounded-card, Tailwind-SaaS look. Distinctive output only appears when you load explicit constraints into context.
About the author
mosh
mosh is a product designer and design engineer working with design systems, LLM-powered prototypes, agent-safe interfaces, production UI, and automated workflows.
Keep reading
- Google spam policies, fake freshness, and why your dates matter more than you think
We audited our own sites for Google publication-dates compliance and found sitemap lies, back-dated pillars, and silent parseDate fallbacks. What Google actually checks and how we fixed it.
- A demo proves nothing. Ship on an eval gate instead
A weekend AI demo hides its failure rate. An eval gate — a quality bar your changes must clear before shipping — is what turns a prototype into a product you can trust at scale.
- Building got easy. Distribution didn’t — and that’s the real problem now
AI collapsed the cost of building a product, so the scarce thing in 2026 is a first user who comes back. Distribution, not development, is the bottleneck for solo founders and small teams.