The problem nobody talks about: AI-generated UI is technically correct but aesthetically broken
AI coding tools ship working code. They do not ship good design. The gap between those two outcomes is where most AI-assisted products quietly fall apart.
The pattern is consistent enough that developers working at the intersection of AI and design engineering have given it a name: slop. Buttons land in the wrong visual hierarchy. Spacing defaults to whatever the training distribution normalized. Color choices read as placeholder-grade. The interface functions — clicks register, forms submit, data renders — but nothing about it signals that a human with taste made decisions. It looks like output, because it is.
This is not a failure of model intelligence. Large language models understand layout concepts. They can describe good design in prose with accuracy. The problem is that the primitives developers use to prompt and constrain AI output have no mechanism for encoding aesthetic judgment. A prompt can specify a button color. It cannot specify the feeling a button color should produce, or how that color relates to the brand’s broader visual logic, or why a particular shade reads as premium versus generic. That layer of judgment has no syntax.
Leon Lin, an open-source developer focused on AI and design engineering, identifies this directly as a primitives problem. His project taste-skill is built on the premise that developers need better building blocks — not smarter models — to produce interfaces that prioritize quality UX alongside functional output. The default outputs of large language models trend toward low-distinctiveness interfaces because the scaffolding developers hand to those models never asks for distinctiveness in the first place.
The result shows up in products everywhere. AI-generated UI has a recognizable texture: technically complete, aesthetically inert. Fixing it requires more than better prompts. It requires a new layer of tooling that treats aesthetic judgment as a first-class input — something the current generation of AI development tools was never designed to supply.
What taste-skill actually does: encoding aesthetic judgment as a reusable developer primitive
Leon Lin built taste-skill to solve a specific problem: AI models generate interfaces that are technically functional but aesthetically hollow. The open-source project inserts a skill layer on top of model output, intercepting the generation pipeline before generic patterns solidify into shipped UI.
The core mechanism is reusable primitives that carry opinionated design constraints baked in. Instead of writing a new prompt from scratch every time a developer wants the AI to make a better spacing decision or reach for a less obvious component hierarchy, taste-skill packages those judgments into a form that travels with the workflow. The constraints don’t live in a comment or a readme — they act on the output directly, nudging generation toward higher-quality UX decisions without requiring the developer to re-litigate aesthetic choices on every project.
This matters because the alternative is what most AI-generated UI looks like right now: safe, centered, padded, forgettable. Models optimize for plausibility, not quality. They produce interfaces that pass a functional check but fail a design check. taste-skill treats aesthetic judgment as an engineering problem — something that can be encoded, versioned, and reused rather than left to prompt improvisation.
Lin’s broader body of work signals that taste-skill is not an isolated experiment. His active projects include a Gemini UI extension and a Prompt Library, all organized around the same stated goal: giving developers better primitives for building interfaces that prioritize functionality and quality UX simultaneously. The pattern across these tools points to a deliberate framework — a design-aware AI tooling stack being assembled piece by piece.
Keeping these tools open-source is a conscious choice. Lin maintains taste-skill through community contributions, funding ongoing updates, bug fixes, and research into new tools in the AI space. The decision to keep the project free and publicly available means the primitives he’s encoding can propagate across the developer ecosystem rather than staying locked inside a single product or workflow.
Why this matters now: the window between ‘AI can build UI’ and ‘AI can build good UI’ is a real market gap
The bar for shipping software has dropped to near zero. Cursor autocompletes logic. v0 generates full component trees from a sentence. Lovable turns a napkin description into a deployed app. What this acceleration produces, at scale, is a market flooded with interfaces that function correctly and feel identical — same layout patterns, same default Tailwind spacing, same component library defaults with the serial numbers barely filed off.
This is the gap that matters right now. “Does it work” is no longer a differentiator. Every AI-assisted product works. The new competitive question is whether a product feels considered — whether the hierarchy makes sense, the spacing has intention, the interactions respect the user’s attention. That quality is taste, and taste is not something current code-generation tools are built to produce.
The timing creates a real market window. AI-native product studios are proliferating, but most lack senior design engineers who can impose quality constraints at the generative layer — before bad UI decisions get baked into a codebase. The bottleneck is not code output. It is design judgment applied early enough in the build process to matter.
Leon Lin’s open-source project taste-skill targets exactly this layer. The tool works at the prompt and primitive level, giving developers better inputs for generating interfaces that prioritize quality UX alongside functionality. That positioning — infrastructure for design judgment, not just code generation — points toward what foundational tooling for AI-native development actually needs to look like.
Open-source tools that operate at this layer have a compounding advantage. They become defaults. They get forked into internal design systems at startups. They shape what “good output” means when developers reach for AI assistance. If taste-skill or tools like it become the standard primitive layer for AI UI generation, they define the quality floor for an entire generation of products — the same way utility-first CSS frameworks redefined baseline visual consistency a decade ago.
The window between “AI can build UI” and “AI can build good UI” is open now. It will not stay open. Studios and developers who close that gap with the right tooling in the next 12 to 18 months will hold a structural advantage that purely functional AI builders will not be able to close by shipping faster.
The open-source angle: building in public at the AI-design frontier
Leon Lin built taste-skill as an open-source project and keeps it that way deliberately. He funds the work through GitHub Sponsors, framing the tool not as a commercial product but as community infrastructure — free for any developer who needs better primitives for AI-generated interfaces. His current portfolio on GitHub includes taste-skill, a Gemini UI extension, and a Prompt Library, all sitting at the same intersection: AI and design engineering.
That positioning carries real consequences. Open-source maintenance at this layer — prompt engineering, design primitives, model-specific extensions — is some of the least glamorous and least funded work in the AI tooling ecosystem. There are no enterprise licensing deals subsidizing bug fixes at 11pm. Sponsorship models like GitHub Sponsors are one of the few mechanisms that make sustained solo maintenance viable, and even then the economics are precarious. Lin’s GitHub Sponsors page is explicit about where contributions go: maintaining and improving the taste-skill codebase, researching new tools in the AI space, and keeping everything free for developers who would otherwise have no access to this kind of quality layer.
The open development model does something proprietary alternatives cannot. When the “taste” encoded in a tool is visible — the prompt structures, the design heuristics, the judgment calls baked into how the system steers an AI toward better UI — it becomes contestable. Developers can read it, argue with it, and submit changes. A proprietary system that nudges AI output toward particular aesthetic choices offers no such transparency. Users accept or reject the output, but they can’t interrogate the assumptions behind it.
That auditability matters more as these tools move closer to production workflows. Design taste is not neutral. Choices about spacing, hierarchy, color application, and component selection reflect specific visual cultures and accessibility assumptions. Building those choices in public means the community can catch blind spots that a closed team would miss. For taste-skill, being open-source is not just a distribution strategy — it’s the mechanism by which the design intelligence it encodes can actually improve.
What most coverage is missing: ‘taste’ as a technical concept, not just a vibe
Most coverage of AI design tools reduces to two questions: how fast does it generate, and how closely does the output match the prompt? Speed benchmarks and capability comparisons dominate the conversation. What gets left out is the qualitative dimension — whether the output is actually good, and what good even means when a model is making visual decisions.
That gap is what makes the framing behind tools like taste-skill genuinely interesting as a conceptual move. Leon Lin, a developer working at the intersection of AI and design engineering, built taste-skill as an open-source primitive explicitly aimed at encoding quality UX judgment — not just functional correctness. The project’s premise is that taste isn’t a vibe or an aesthetic preference that lives in a human designer’s gut. It’s a skill. That means it can be modeled, packaged, and transferred to the systems generating interfaces.
This reframing has implications well beyond UI. If taste is a skill, then the same logic applies to AI-generated copy, brand voice, content strategy — any domain where “technically correct” and “actually good” diverge. The tooling conversation for all of those domains is still stuck at the capability layer, asking what the model can do rather than building primitives that shape how it does it.
The harder question taste-skill forces into the open is whose taste gets encoded. When you package aesthetic judgment as a reusable primitive, you’re making curatorial decisions that will propagate across every interface built on top of that primitive. The risk isn’t that AI-generated UI stays generic — it’s that it converges on a new, different kind of generic, one that reflects the sensibilities of whoever defined “good taste” in the underlying tooling. That’s a homogenization problem, and it’s more subtle than the bland outputs people already criticize.
The field has the benchmark conversation well covered. The conversation it hasn’t started yet is about the politics and provenance of the quality signals being baked into these tools — and that conversation is now unavoidable.
