Design, Code or Chat
All three can hand you an HTML page. What separates them is not the output — it is what you can do to it next.
Here is the honest source of the confusion: all three can hand you an HTML page. Ask Chat for a landing page and you will get one. Ask Design and you will get one. Ask Code and you will get one. If the artefact is the same, the usual comparisons — which is more powerful, which is for designers — do not help you choose.
The distinction that does hold is not what comes out. It is what you can do to it next.
You can regenerate it
The page is disposable illustration. Your only lever is to ask again, differently. It has no address, no history and no collaborators, and it dies in the thread it was born in.
You can work on it
The page is the artefact, with a canvas around it. Comment on one element. Edit the headline in place. Move a slider and watch the spacing change. Fix one card and propagate it. Chat cannot do any of that — it can only try again.
You can ship it
The page lives in a repository, with tests, review, version history and a deploy pipeline attached. It is subject to everything an organisation does to software it depends on.
Do not ask what you want to end up with. Ask what you want to do to it once you have it. Read it once and move on — Chat. Push on it, show it to people, change it twenty times — Design. Depend on it — Code.
The matrix, for reference
Once you have the overlap straight, the rest of the differences fall out predictably.
| Claude Chat | Claude Design | Claude Code | |
|---|---|---|---|
| The output is | Words — analysis, drafts, answers | A rendered visual you can work on | Production software in a real codebase |
| You work by | Conversation only | Conversation, comments, direct edits, sliders | Delegating against files, terminals and repos |
| Best first move | Thinking a problem through | Making an idea visible and testable | Implementing, refactoring, shipping |
| The audience is | You, mostly | Other humans — stakeholders, testers, clients | The machine, then your users |
| Fidelity | Descriptive | Looks and behaves real; not wired to production | Is real |
| Cost of being wrong | A wasted read | An afternoon | A sprint, and code someone has to live with |
| Hands off to | Design, or Code | Code, via a one-instruction handoff bundle | Deployment |
The relay, run in order
The three surfaces are not competitors. They are a relay: the idea forms in Chat, becomes visible and testable in Design, and gets built in Code. Skipping the middle leg means engineering the wrong thing beautifully — which is the most expensive way to be wrong that this toolchain makes available.
The relay runs backwards too, and that is the underrated direction. A prototype that fails in front of five users sends you back to Chat with a better question than the one you started with, and you are out an afternoon instead of a sprint. Design is where being wrong is cheap. Use it for exactly that.
When to skip Design
When the design is genuinely settled — a component that already exists in your system, a bug, a refactor, a migration — the canvas is a rehearsal for a performance you have already given. Go straight to Code. The tell that you skipped it too early is arguing about what something should look like once you are already in the editor.