Listen to this article:
When it comes to design and AI, two questions come up frequently. The first is some version of “what’s up with vibe coding?” The second is “what about Claude Design?” They look like the same question — can we point AI at this and get something usable — but they have different answers, and the reason is more interesting than either answer.
Vibes are made; they don’t make.
Start with the term. Vibe coding undersells both the people doing it and what’s actually possible with it. There is real intent and real integrity in a lot of that work, and the phrase flattens it into something casual and faintly embarrassing. But set the naming aside. The more useful question is why it works as well as it does, because that explains why the same approach applied to design produces something so much shakier.
Code is standardized externally. It arrives in layers, and every one of those layers has a specification that exists outside your company and predates your project. A language has a grammar. A browser implements a rendering standard. A runtime documents its behavior. Those standards were argued over in public by thousands of people and then written down. When a model writes code, it draws on a body of convention that is enormous, public, and largely settled. That is why you can rely on it from the first turn of the first conversation. It isn’t that the model is smart about your project. It’s that your project is mostly built out of things that were standardized before you got there.
Design is standardized in layers too. But its standards are internal. They’re the brand: the type scale, the spacing rhythm, the specific relationship between your logotype and every curve radius in your system, the reason a white arrow can overpower a colored one on the page. None of that was argued over in public. It lives in your documentation, in accumulated decisions, and — most of it — in the judgment of the people who made those decisions. A model shows up knowing the conventions of design in general and nothing whatsoever about yours.
Don’t wait for AI to get better at design.
That asymmetry is structural, not a matter of capability. Generic competence is what a shared standard buys you, and design’s standards aren’t shared. Which is also why waiting for a better model won’t resolve it. There is no public corpus of your brand to get better at.
So the work is clear enough, if not easy. If the standard is internal, the job is to make it external — legible enough for a machine to apply. That’s a different exercise from documenting a design system for people. People fill gaps with judgment; a model fills them with whatever it has. A style guide written as reference assumes a reader who already understands design. A style guide written as training material can’t assume anything.
I keep returning to this because it relocates the craft rather than eliminating it. The tedious part — building and duplicating components, producing the fourteenth variant of an email template — is the part that moves. What stays is the articulation itself: deciding what the standard is, and saying it precisely enough that it survives being applied by something with no taste. That was always the hard part. It has just never been so obvious that it was.
Claude Design vs. Design with Claude
On Claude Design specifically, my read has changed. It launched looking like a tool for people who don’t have designers, and for teams that do, it was hard to justify. That’s less true now. It accepts design system imports, allows direct editing on the canvas, and syncs both ways with a codebase, so a design can be built against your real components instead of approximations of them. That is precisely the seam I’ve been describing. If you formed an opinion in April, form a new one.
The economics are worth knowing and worth dating, because they’ve already changed twice. Design currently draws from the same usage pool as everything else; it launched with its own allowance and lost it at the end of May. So the question isn’t which budget you’re spending, it’s cost per useful output. Design is heavier per turn — it renders to a canvas and then looks at what it rendered. Chat is cheaper per turn but blind: you describe what you want, something gets built that nobody sees, and the correction loop runs entirely on words. If you know what you want and can specify it, chat is more economical. If you’re iterating on layout and spacing against an existing system, the canvas earns its cost, because the alternative is many rounds of guessing at pixels.
None of which is the interesting part. The interesting part is that all of this pressure lands in the same place: how well you have said what you mean. A model applying your standard is only as good as the standard you handed it, and most organizations have never had to write theirs down with that kind of precision. They’ve gotten by on the fact that the people applying it already knew.
That’s the work now. Not prompting. Not tooling. Saying precisely what your standard is — and then reviewing everything that comes back against it, because the machine will apply what you wrote, not what you meant.