---
title: 'Vibe Designing'
description: "Claude Design isn't vibe-coding. It's vibe-designing. And treating it like a coding tool might be holding it wrong."
---

Anthropic launched [Claude Design](https://www.anthropic.com/news/claude-design-anthropic-labs) this week. The immediate comparison is with _vibe-coding_ tools like [Lovable](https://lovable.dev/). I think that risks the wrong frame. Claude Design isn't vibe-coding. It's vibe-_designing_[^3] — and treating it like a coding tool might be holding it wrong.

When using Claude Code, it's easy to imagine you are directing a highly-competent Software Engineer. The mode and types of interactions follow from that. Claude Code will prompt you about tests, edge-cases, potential pitfalls and tradeoffs. This is the dialog you would expect with an Engineer.

Claude Design is similarly deliberate. It feels much closer to working with a highly-competent designer. The interface is exploratory, and the conversation uses interviews and feedback to calibrate. For my roguelike, I got questions like "High or Low Fantasy?" through to "Pixel Art or Retro Terminal?". As Claude Design was producing a design system, it prompted for feedback on partial outputs as it went. It was iterative and consultative, not just generative.

Whilst the literal end artifact in my case was a handoff to Claude Code, the real artifact is the _design_. I kept trying to click into the files to see the code — which was also the moment I realized my mental model was off. You’re not really generating UI here; you’re exploring a space of possible designs and converging on one.

You now have the ability to explore problem spaces extremely quickly. For my roguelike I had the same set of principles, but could try a few radically different UI treatments in a short afternoon[^4]. While I love Figma and will miss pixel-pushing, being able to unleash your imagination is intoxicating.

Similar to the Software Engineer's experience with Claude Code, the question becomes "What is the role of the Designer?". Partially I think the answer is in my other short, [We're not Vibe-Engineering](/not-vibe-engineering/). The mechanics of design are changing rapidly, but taste and judgment become more important, not less. If anything, this compresses the gap between a good designer and a great one.

The mental switch I faced as a Software Engineer was from "how do I prevent non-coders from breaking the codebase" to "how do I make it possible?"[^1]. I suspect this will be a similar journey with Claude Design. The challenge will be corralling all of these superpowers, especially when they're disseminated across the team. For me, I can usually tell when a design is good, but not always how to get there — which leads to a kind of search process and the risk of local minima. This is where a partnership with design has always pushed a "logical" product into an excellent one.

This is already apparent in the shape of Claude Design. There's a clear orientation around producing a Design System — a set of primitives that can be assembled to create and iterate on designs. The core benefits of a Design System are consistency and speed[^5]. Those remain true, but the system is going to be stressed in new ways. Many Design Systems are anchored in atomic elements — buttons, typography, core components. Some systems never get beyond this. However, when you can produce these in an afternoon, and when anyone on the team can generate screens in minutes, the atoms start to matter less than the interaction patterns that tie them together.

I haven't used Claude Design enough yet[^4]. One area I'm really curious about is the round-trip between Claude Design and Claude Code as they both iterate. But if my experience with Claude Code over the last year is any guide, this shift is likely to be just as big.

### FOOTNOTES

[^1]: For example, at Pyn we [have Customer Success shipping PRs](/cs-first-prs/).

[^3]: For the record, I'm not entirely a fan of the term "vibe-coding".

[^4]: Constrained only by Claude Design usage limits.

[^5]: There are [numerous more reasons](https://www.nngroup.com/articles/design-systems-101/), but I believe these two to be foundational.