Vibe coding for designers: the part that decides whether it works

The common experience is that the first two screens are astonishing and the tenth is a mess. That is not the model getting worse. It is that nothing in the project ever pinned down what the thing should look like, so every turn re-decides — a slightly different spacing here, a fresh grey there, a new accent when the last one "looked a bit flat".

Practitioners who ship consistently describe the same habit: sketch the scaffolding first — theme, grid, typography, colour — and only then start asking for features. That ordering is the entire difference, and it is the part that gets skipped because prompting is more fun.

1. 1

   Put a token set in the project

   Named colour roles for light and dark, a type scale, spacing, radii. Not a palette — roles, so the answer to "what colour is a disabled button" exists before anything needs one. One command installs a complete set if you would rather not assemble it: npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Write a rules file that forbids things

   Whatever your tool reads — .cursor/rules/design.mdc, .devin/rules/design.md, a line in CLAUDE.md. Keep it policy, not taste: use only the semantic tokens, never a raw hex, no second accent on a screen, never ship a light change without its dark counterpart, and ask rather than invent when the system is silent.

3. 3

   Get a preview running before you build anything

   You are a designer; you review by looking. If you cannot see the change land, you are reviewing code, which is the one thing you are not set up to do.

4. 4

   Make the first commit

   Before the first feature. This is your baseline, and from here every prompt is undoable. git is the undo button — the chat's is not.

The rules file matters more than it looks, and specifically the prohibitions do. A preference adds one option; a prohibition removes all the others. "Use our green" leaves every generic default still legal. "Never introduce a colour that is not a token" does not. We sampled 299 public design documents written for exactly this purpose and 76% listed only preferences, which is a precise description of why they stop working around screen five.

The single most common self-inflicted problem is asking for too much at once. A prompt that produces a forty-file diff is a diff nobody reads, which means the drift went in unreviewed and you will meet it later as "why does this page look different".

• One screen or one component per turn. Look at it, commit it, move on.
• Commit before every prompt, not after. So the previous good state is always one command away and you never have to decide whether the last change was worth keeping while also fixing it.
• Say what not to touch. "Change only this component" prevents the helpful refactor of three files you had already approved.
• When it goes sideways, revert rather than negotiate. Three rounds of "no, not like that" produce a patched-over result that satisfies the conversation and not the design. Go back to the last good commit and re-ask with a better prompt.

This is the skill worth learning, and it is a design-review skill wearing a git hat. You are not checking whether the code is good. You are checking four things, and all four are visible without understanding a line of logic.

Those four checks take about a minute per diff and catch most of what causes drift. Everything else — whether the state management is sensible, whether the query is efficient — is genuinely not your job at this stage, and pretending otherwise is what makes designers avoid the review entirely.

• Agreeable acceptance. Ask "is this following the design system?" and you will usually be told yes. Ask instead "list every colour value in this file that is not a token" — a question with a checkable answer.
• Hardcoding to make it work. A value pasted in place of a lookup makes the screen correct and the system wrong. It surfaces the first time you change a token and one component does not move.
• Patching output instead of fixing cause. A margin added to compensate for a layout that was wrong two components up. Each patch is small; the tenth one is why nothing can be changed safely.
• Improving the system mid-task. A new colour introduced "for contrast". This is drift with a justification attached, and it is the hardest kind to catch because the reasoning is sound.
• Passing the wrong test. It renders, so it works. Check dark mode, an empty state, and a long string in a narrow column before believing it.

Less than the courses suggest and more than zero. Usefully, the required amount is specific rather than general.

• Reading a diff. Green added, red removed, and the four checks above. An afternoon.
• Basic git. Commit, view a log, revert to a commit. Half an hour, and it is the highest-return half hour available.
• Where things live. Which file is the theme, which is a component, which is a page. Ask the agent to explain the structure once — it is good at this.
• Reading an error. Not fixing it. Being able to paste the relevant part rather than a screenshot of the whole terminal.

What you do not need is to write React, understand build tooling, or manage dependencies. Those are exactly what the agent is for, and time spent learning them is time not spent on the review skill, which nothing else can do for you.

Vibe coding is exceptional for prototypes, internal tools, marketing sites, and proving an interaction is worth building. It is genuinely risky at the boundaries where a mistake is not visual: authentication, payments, anything touching customer data, anything with a migration. Those failures do not show up in the preview, which is the one review channel you have.

A useful line: if the worst outcome of being wrong is that it looks bad, ship it and iterate. If the worst outcome is that someone else's data or money is affected, that is a handoff, not a prompt.