Taste Has a Distribution Channel: Emil Kowalski and the Design Engineer
Nov 2026Open-source components, a course, a skill for coding agents, and what I think comes next.
Why this is on my mind
Emil Kowalski is a good case study in how taste spreads. He didn't write a manifesto. He shipped components people loved, explained how they worked, and has now packaged his thinking for machines.
What's true right now
The components made the reputation. Kowalski built two open-source libraries, Sonner (toasts) and Vaul (drawers). He says he came up with the name Sonner by looking up French words for notifications, and that the animations are what made people fall in love with the tiny component. Vaul grew from wanting Apple's sheet experience on the web, built on Radix's Dialog primitive for accessibility and focus management.
The details are explicit. In his writing on transforms he explains that Sonner uses only translateY() with percentages, so a toast moves by its own height regardless of its size. That's a rule you can write down, which matters later in this post.
Sharing created the career. In an essay on animating in public, he describes how sharing a small component in 2021 led to work at Compound, Vercel, and Linear, to creating Sonner and Vaul, and eventually to launching an animation course. His site also links the course, animations.dev, and a newsletter on design engineering.
Now the taste is packaged for agents. He turned his blog articles into one design-engineering skill covering animation, component design, and the principles behind his open-source projects, and invites people to install it for their coding agents in a post called Agents with taste. A skills directory listing for it showed nearly 90,000 installs when I checked; third-party counts are rough, but the demand is clearly real.
What I notice
There's a clear progression in how craft knowledge travels. First, finished components (copy the thing). Then essays and courses (understand the thing). Now skills (let a machine apply the thing). Each step is more portable than the last, and each demands the knowledge be more explicit.
Turning a rule into a check
Illustrative: my own sketch, not a sourced fact.
Start with the rule that can be measured. Take the Sonner rule that a toast moves by its own height using percentages. That is easy to check, because you can read the code and see whether it holds. A rule like "ease-out for responsive feel" is harder, because it needs someone to look at the motion and judge it. The first kind can be automated. The second kind needs graded examples. That split also tells you who does the checking: a script for the first pile, and a person with a good eye for the second. Mixing them up wastes time on both sides.
Sort rules before you write evals. I would split a skill into rules a linter could catch and rules that need human taste. Only the second pile needs the ten pass/fail examples I describe below. That keeps the effort honest: you spend judgment where judgment is actually required, and you do not pretend taste can be reduced to a regex. The goal is not to automate taste, only to be clear about which parts of it can be written down and which parts still need someone who has seen a lot of good work.
What I would not trust a skill to do
My opinion, based on the progression above.
Applying a rule in the wrong place. A skill packages how one craftsperson thinks. An agent that follows it will apply it everywhere, including places where the author would have broken the rule on purpose. The knowledge is explicit now, but the judgment about when not to use it is still mostly tacit. An agent has no way to feel that a rule does not fit this screen. It will follow the text, which is exactly what makes a skill useful and exactly what makes it risky when the context shifts.
Confident sameness. If many teams install the same skill, their interfaces may start to feel alike. I do not know how big that effect would be. It is one more reason I would want published checks that tell you where the output is wrong, not only where it follows the style. That is a guess, not a finding. But it is the kind of risk I would want a team to name early, before every product in a category quietly ends up moving the same way.
My hypothesis
This section is my opinion, not a sourced fact.
The next step is evals: published test cases that let anyone check whether a generated interface actually meets a craftsperson's standard.
A skill tells an agent what good looks like. But it can't tell you whether the agent followed it. The natural complement is a set of graded examples: this transition is right, this one is too slow, this one fights the user's expectations. Whoever publishes a trusted set will let teams measure taste instead of arguing about it.
I'd expect the most respected design engineers of the next few years to be known for the checks they publish, not just the components.
How I'd test it
Take one rule from a published skill, such as "ease-out for responsive feel." Write ten pass/fail examples. Ask three different agents to generate ten transitions each. See whether the examples reliably separate the good from the bad. If they do, the rule is testable, and so is the taste.
What would change my mind
If craft turns out to depend so heavily on context that no fixed examples generalize, evals would be too brittle to be useful, and human review stays the only real check.
How I would explain this to a teammate
My opinion, written as a plain-language pitch.
The short version. Components let you copy someone's taste. Essays let you understand it. Skills let a machine apply it. Evals would let you check that the machine did it right. Each step makes the knowledge more portable, and each one asks the author to be more explicit about what "good" means. It is a short chain, and I find it easier to explain than any single piece of it. Most people already know the first step; it is the last step that is still missing.
The ask. Before a team adopts a skill for its agents, I would ask one question: how will we know when it was followed? If nobody has an answer, the skill is a hope, not a standard. Even three graded examples would be a start, and they would make design reviews about evidence instead of preference. That one question is cheap to ask and hard to dodge. It moves the conversation from whether the skill sounds good to whether we can show it working, which is where design reviews should have been heading anyway.
References
- Emil Kowalski, Agents with taste
- Emil Kowalski, Building a toast component
- Emil Kowalski, Building a drawer component
- Emil Kowalski, CSS transforms
- Emil Kowalski, Animating in public
- Vibe Index, emil-design-eng skill listing