← AI + Design Field Guide  ·  Workflows

Vibe Coding

Direct AI to build interactive experiences from design intent — not code syntax. You describe what something should do and feel. AI writes the implementation. You evaluate, direct, and iterate.

The Approach Tools Workflow Prompt Patterns Pitfalls
The Approach

You are the designer. AI is the implementer.

Stay at the right level of abstraction. Your job is design intent — what it should do and feel. The moment you start thinking in code syntax, you've given up the designer's chair.

01

Stay at the level of experience.

Describe what a person sees, does, and feels — not the code structure you think you need. The syntax is AI's problem. Precision in describing the experience is yours.

"It should feel like a slow inhale, not a click." That's a brief. That's your job.
02

One change at a time.

Pick one design goal. Make it specific. Evaluate the result. Then move to the next. This discipline keeps you in authorial control — and makes it possible to know what worked.

If your revision prompt has more than two requests, split it into two prompts.
03

Understand before you accept.

Every function you accept is code you're responsible for. Ask AI to explain any section you don't understand. You don't need to memorize syntax — but you need to know what each part is responsible for.

"Explain what this function does, as if I'm a designer who needs to understand the behavior — not the syntax."
Tools

Six tools — and when to reach for each.

Different tools have different strengths. Claude is conversational and strong at design intent. Cursor knows your whole codebase. v0 generates visual UI fast. Know which tool fits the moment.

Screenshot
Claude.ai — Design Intent Document + prompt
Claude
Free + Pro
Full-file generation · design-intent prompting · explanation
The strongest tool for generating complete files from a design brief. Understands aesthetic and emotional language well — "the interaction should feel weighted" lands here in a way it won't in code-focused tools.
How to start
  1. Open claude.ai → new conversation
  2. Paste your Design Intent Document first
  3. Describe the experience you want to build
  4. Ask for a single self-contained HTML file
  5. On follow-ups: paste current file + one specific change
claude.ai
Screenshot
Cursor — Cmd+K inline edit on existing code
Cursor
Free trial · $20/mo
Editing existing code · multi-file projects · inline changes
A code editor where AI can see your entire project — not just what you paste. When you have an existing codebase and need targeted changes, that full-project context changes everything.
How to start
  1. Download Cursor at cursor.com → open your project folder
  2. Cmd+K to edit a selected section inline
  3. Cmd+L to chat about your files
  4. Use @filename to bring specific files into context
cursor.com
Screenshot
v0.dev — UI description + generated component
v0 by Vercel
Free tier
UI component generation · visual starting points · React/Tailwind
Generates React/Tailwind UI components from visual descriptions — and the results look designed, not like a default template. Strong for the visual layer. Bring it into Cursor or Claude for behavior and customization.
How to start
  1. Go to v0.dev → no account required to start
  2. Describe your UI with visual specificity
  3. Iterate in the v0 interface
  4. Copy the component code → customize in Cursor
v0.dev
Screenshot
VS Code + Copilot — comment-to-code autocomplete
GitHub Copilot
Free for students
Inline autocomplete · boilerplate · code continuations
AI autocomplete inside VS Code — suggests completions as you type. Best when you understand the pattern you're implementing and need implementation speed. Less useful for generating from a design brief from scratch.
How to start
  1. Install the GitHub Copilot extension in VS Code
  2. Sign in with GitHub (free for verified students)
  3. Write a comment describing the function you want
  4. Tab to accept Copilot's suggestion
github.com/features/copilot
Screenshot
Bolt.new — prompt + live app preview + deploy
Bolt.new
Free
Full-stack generation · live demos · deployed URL in minutes
Generates a complete, deployable web application from a single prompt — front end, back end, and a live URL. The fastest path from idea to something demonstrable. Less controllable than Cursor, but dramatically faster for pitching.
How to start
  1. Go to bolt.new → no signup required
  2. Describe your full application (include DID context)
  3. Iterate by typing follow-up changes in the chat
  4. Click Deploy for a shareable URL
bolt.new
Screenshot
Replit — browser IDE with live preview + AI chat
Replit
Free
No local setup · browser-based · instant sharing
Everything runs in your browser — no installation required. Write, run, and share code from any computer. The most accessible starting point for students who don't have a development environment set up.
How to start
  1. Go to replit.com → create a free account
  2. Click Create Repl → choose HTML/CSS/JS
  3. Use the AI chat to describe what to build
  4. Click Run to see it live → share the URL for demos
replit.com
The Workflow

From design intent to working code.

A repeatable structure. You'll cycle through steps 4–6 many times — the quality of your work lives in that loop.

01
Build your context.
Write your Design Intent Document before you touch a tool. Five to seven sentences: what you're making, who it's for, what you want them to feel, what constraints you're working under. Paste this at the top of every AI conversation. Without it, you're starting from zero every session.
Keep your DID in a text file. Paste it first, every time.
02
Describe the experience — not the code.
Your first prompt should describe what a person experiences: what they see, what they do, what they feel. No HTML elements, no CSS properties, no JavaScript functions. Those are AI's job. Your job is the experience brief.
"Feels like it's deciding whether to respond" is better than "0.3s transition delay."
03
Run it first — then read the code.
When AI generates a file, open it in a browser before you read the code. Interact with it as a user. Your felt reaction is valid design data. What works? What doesn't? What surprised you?
Ask for a single self-contained HTML file whenever possible.
04
Explain it back.
For any section you don't understand, ask AI to explain it in plain language before you move on. You don't need to memorize syntax — but you need to know what each part is responsible for, so you can ask for targeted changes and debug when things break.
"Explain this function as if I'm a designer who needs to understand the behavior, not the syntax."
05
Evaluate against your design intent.
Return to your DID. Does this draft achieve what you said you wanted? Apply Norman's three levels: does it hit visceral (immediate feeling), behavioral (works as expected), reflective (says something after you walk away)? Write your evaluation in a sentence — that sentence becomes your next prompt.
"The transition feels mechanical because it has no variation in speed or weight."
06
Iterate precisely.
One change at a time. Take your evaluation sentence, make it a prompt, paste the current full file, and specify exactly what to change — and what to leave alone. Always paste the full current file. Never ask AI to "remember" the previous version.
"Revise only the animation logic. Everything else should stay the same."
07
Document as you go.
At session end: ask AI to add inline comments explaining each major section (if missing), and log three sentences in your AI use record: what you asked for, what AI gave you, what you decided and why. This is your authorship record — and what lets you continue next session.
Your log doesn't need to be elaborate. Three sentences is enough.
Prompt Patterns

Four prompts you'll use constantly.

These aren't templates to copy verbatim. They're structures. Understand why they work, then adapt them to your project.

01  ·  Opening a new session Every single time
[Paste your Design Intent Document] I'm continuing work on this project. Current code: [Paste full current file] Today I want to work on [specific goal]. Before making changes, confirm you understand the design argument and flag anything in the current code that conflicts with it.
AI has no memory between sessions. This rebuilds full context in one move and asks AI to catch conflicts before generating.
02  ·  First generation from a brief Starting something new
[Design Intent Document] Build a single self-contained HTML file. When a visitor arrives, they should feel [emotional quality]. The visual language is [descriptors]. The primary interaction is [describe] and when it happens it should feel [quality — immediate / weighted / elastic / reluctant]. Do not include: [exclusions]. Add comments in the code explaining what each major section does.
You're writing a director's brief, not a technical spec. "Reluctant" is a useful word here. "50ms delay" is implementation — AI's job, not yours.
03  ·  Iterating on feel The most common prompt type
Current code: [paste full file] The [element or behavior] currently feels [how it feels]. I want it to feel [how it should feel] — specifically, [what's missing or wrong]. Revise only the [relevant section]. Do not change anything else. Explain what you changed and why it produces the feeling I'm describing.
"Revise only X" is critical. Without it, AI will refactor things you weren't asking about. The explanation request connects the technical change to the experiential goal.
04  ·  Requesting explanation After anything you don't understand
Explain this section as if talking to a designer who needs to understand the behavior — not the syntax: [paste section] What is this responsible for? What breaks if I remove it? What would I change to get [alternative behavior]?
"As if talking to a designer" reframes explanations away from jargon. The "what would break" question gives you actionable design handles, not just a description.
Pitfalls

Five ways this goes wrong.

01

Accepting code you can't explain.

If something breaks, you need to locate why. "AI wrote it" is not a debugging strategy. Understanding doesn't mean memorizing syntax — it means knowing what each section is responsible for.

Ask for explanation after every generation. Make it a habit.
02

Describing the code instead of the experience.

"Add a CSS flexbox layout" tells AI to build but gives away the design decision before it's made. The result will be technically correct and design-neutral.

Start every prompt from the human experience. Code structure follows.
03

Too many changes in one prompt.

Asking for five things and getting three addressed makes it impossible to know what worked — or revert anything specifically. This is how projects become impossible to debug.

One design goal per prompt. Evaluate before moving on.
04

Not testing in a real browser.

Generated code may behave differently across browsers, screen sizes, and interaction speeds. The only valid test is interacting with it yourself, in the environment where it will run.

Open it in a browser after every generation. Interact before reading the code.
05

Starting a new session without rebuilding context.

AI has no memory. Paste only code, get code-level help. Paste your DID first, get design-intent-level help. The difference is significant. The fix costs sixty seconds.

Keep your DID in a text file. Paste it first. Every time.
← Back to Field Guide Microcontroller Programming →