Most people use Claude like a vending machine. Type a prompt, get a thing, complain it's not quite right, type another prompt. That works for one-off scripts. It falls apart the moment you're building a real interface where Chat, Design, and Code all need to agree on what you're making.
I've been shipping UI with Claude for long enough to have a "before" and an "after." Here's both.
How I used to work with Claude
The loop looked like this, and honestly it's already better than 90% of the "vibe-code me a SaaS" prompts floating around:
- Claude Chat — talk through the idea. What is this? Who's it for? Walk the user flow out loud, screen by screen.
- Chat → Design prompt — once the flow felt clear, ask Chat to write a prompt for Claude Design. Chat had the context; it could compress it.
- Claude Design — generate the mockup. Tweak. Iterate on layout, hierarchy, copy.
- Export the pack — download the design output.
- Chat → Code prompt — feed the pack and the intent back to Chat, get a build prompt.
- Claude Code — build it.
The shape is right. It separates thinking from visual from implementation, and it uses Chat as a prompt compiler between stages — because each tool wants a different kind of context.
But after doing this enough times I noticed the same problems kept showing up at the same seams. Seven of them. So I changed the loop.
How I work with Claude now
Same three players — Chat, Design, Code — but with the handoffs nailed down. Here's what changed and why.
1. There's a spec.md that outlives every conversation
Old me re-explained the why at every handoff. The next tool only got the what. By the time Code saw the project, "a focused journaling app for people who hate journaling apps" had been flattened into "build a list view with an editor."
Now every project starts with a short living doc:
# Product
One sentence. Who it's for. What it replaces.
# Core flows
1. ...
2. ...
# Non-goals
What we are explicitly not building.
# Vocabulary
Entry, not Item. Streak, not Counter. Pick names once.
# Stack
Next.js 15, TypeScript, Tailwind, SQLite via Drizzle.
Every stage reads this first. Every stage can propose edits. The chat history is not the source of truth — this file is.
2. Data shapes come before pixels
Old me went straight from flows to Design. Then Design would show "Cards" and Code would end up with entries and I'd lose an afternoon chasing the rename through component names, props, and routes.
Now I spend ten minutes in Chat nailing the nouns and their shapes before Design sees anything:
type Entry = {
id: string
body: string
mood: 1 | 2 | 3 | 4 | 5
createdAt: Date
}
Design uses real words. Code inherits them. No rename pass.
3. Design → Code goes through a component inventory
Old me handed the Design pack straight to Code. The pack contains visuals. It doesn't contain intent. Code looking at a mockup sees boxes and text; it can't tell which box is a reusable primitive and which is a one-off.
Now, between Design and Code, I ask Chat to produce an inventory from the mockup:
- AppShell (sidebar + main)
- EntryRow (used in list, in search results)
- MoodPill (1-5, colored)
- Editor (autosave, markdown)
Code gets three things, not one: the pack, the spec, the inventory. Visuals, intent, structure.
4. Code gets staged tickets, not one giant prompt
The single biggest mistake in my old loop: pasting everything into Code and saying "build it." The result was a sprawling, half-wired project where every file was mid-quality and nothing was easy to fix.
Now Code works in three passes:
- Scaffold. Routes, types, empty components, no logic. Commit.
- One screen at a time. Build the list view. Review. Commit. Build the editor. Review. Commit.
- Wire-up. State, persistence, side effects.
Claude Code is dramatically better on narrow tasks against a clean repo than on "build the whole app from this zip." Treat it like a fast junior with small tickets, not a contractor with a brief.
5. There's a visual eval step
Old me assumed the built screen matched the designed screen. Usually: not quite.
Now, after each screen, I screenshot it, drop it into Chat next to the Design mockup, and ask: "What drifted? Spacing, hierarchy, color, copy." Claude is genuinely good at this — better than I am after staring at it for an hour. Fix the top three issues. Move on.
6. Deviations get reconciled back into the spec
Code will make sensible deviations. It'll rename something, restructure a route, pick a library. In the old loop those changes never made it back into the spec, so the next Chat session was working from a stale map.
Now every Code session ends with: "Summarise any deviations from the spec and propose updates." Two minutes to paste them in. Saves hours later.
7. Context lives in the Project, not in every prompt
Old me re-pasted stack conventions, tone, and design tokens into every new Chat. Now they live in a Claude Project once. House style goes in a Skill. The marginal cost of starting a new conversation should be zero — otherwise you'll avoid starting new ones, and long threads rot.
The new loop, end to end
- Chat — idea, flows, non-goals → write
spec.md. - Chat — define data shapes and vocabulary. Update spec.
- Chat — generate Design prompt from spec.
- Design — mockup. Iterate.
- Chat — generate component inventory from mockup. Update spec.
- Code (scaffold) — routes, types, empty components. Commit.
- Code (screens) — one at a time. Commit between each.
- Chat (eval) — screenshot vs mockup. Fix drift.
- Chat (reconcile) — update spec with deviations.
It looks like more steps. It's less work, because nothing gets redone.
The real principle
Claude is three different collaborators wearing the same name. Chat is the PM. Design is the designer. Code is the engineer. The reason my old output was mushy is the same reason a real team's output gets mushy: sloppy handoffs and no source of truth.
Own the spec. Stage the work. Close the loop. The tools are already good enough — the process is the bottleneck.