Vibe coding for designers: how to prototype with Claude Code

The term has drifted. Karpathy described something loose: let the AI write it, don’t look closely at the code, and see what happens. In March 2025 the developer Simon Willison drew a useful line. If you review, test and understand the code, that is AI-assisted programming. Vibe coding is when you don’t.

The everyday meaning kept growing anyway. Collins named vibe coding its Word of the Year for 2025 and defined it broadly, as “the use of artificial intelligence prompted by natural language to assist with the writing of computer code”. A year after his first post, Karpathy suggested “agentic engineering” for the careful version, in which you direct AI agents and check their work.

For a prototype, the loose version is fine, because the code is meant to be thrown away. What matters is that you know which parts you haven’t checked, and that nobody mistakes the prototype for the product.

Prototype in code when the thing you need to learn depends on behaviour that a design tool can only fake.

Real data is the first case. A Figma frame shows three plants with short names. A coded prototype can load 40 plants, one called “Variegated string of pearls”, and an empty state for someone who hasn’t added any yet. Layout is the second: one screen that reflows properly from a small phone to a tablet. Interaction is the third: dragging to reorder, the timing of an undo message, typing into a search box and seeing results, a keyboard that covers the button you need.

The biggest gain is testing. You can send a link and watch people use the prototype on their own phones, with their own thumbs, screen sizes and text settings.

Code is the wrong tool for early layout and visual direction, where Figma or paper is faster and cheaper to throw away. Nielsen Norman Group points out that a prototype can be high fidelity in some ways and low in others. A coded prototype is how you get the interaction right, and the look can stay rough while you do.

Claude Code is Anthropic’s agentic coding tool. You describe what you want, and it reads the files in a project folder, edits them and runs commands to build the result. It runs in a terminal, in code editors such as VS Code and JetBrains IDEs, in the Claude desktop app and in a web browser.

For most designers the desktop app is the easiest place to start. In its Code tab you choose a folder and chat with Claude, and a Browser pane shows the app as it runs. Claude can start the app itself after editing it, and check its own work there by taking screenshots and clicking through. On the web, sessions run in the cloud against a GitHub repository.

Claude Code changes quickly, so names and menus may differ from what you see. Anthropic’s documentation, linked at the end, has the current steps. Whichever you use, a few minutes of setup before the first prompt saves an afternoon of repeating yourself.

A good brief fits in one paragraph and answers five questions: who it’s for, the one flow you want to test, which screens that needs, what is out of scope, and how it should be built.

The last two matter more than they seem. Without “out of scope”, the tool fills the gaps with what most apps have: sign-in, settings, a profile page. Without a stack, it may reach for a database and a server you don’t need. For a prototype, “a single-page web app, no backend, made-up data” is nearly always the right answer.

A full brief might read: “Sipling helps people with 5 to 15 houseplants remember to water them. One flow: open the app, see which plants need water today, tap Water and see the plant marked as done. Two screens: Today and Plant details. Out of scope for now: sign-in, reminders and settings. Build a single-page web app with no backend, using made-up data in plants.json.”

Here is the same request twice: once as a single line, once with a brief, your tokens and a screenshot.

Adjectives don’t carry a look from your head to the screen. Values do. “Clean and modern” gets you the same rounded cards as everyone else. A tokens file with your colours, type sizes, corner radius and spacing gets you your product.

Export the tokens from your design tool as CSS variables or JSON, and add two or three screenshots of real screens. Claude can read images, so a screenshot shows things a list of values can’t, such as how dense a list is or how much air sits around a heading. Then say which file is for what: “Take colours and type from tokens.css. Match the card style and spacing in today.jpg.”

Get one flow working from start to finish before you polish anything. For Sipling that means: open Today, tap Water on the Monstera, see it marked as done and see the count drop from three to two. It can look rough. It has to work.

A working flow is what you will test, and polish spent on a flow that later changes is wasted. Start in plan mode. In the terminal you switch to it with Shift+Tab, or use it for one prompt by starting the prompt with /plan. Claude reads the folder and proposes what it will build, and nothing changes until you approve. Anthropic’s own best-practice guide recommends exploring and planning before coding when the approach is uncertain, and skipping the plan for small, clear changes.

Once the flow works, improve it in small steps. Ask for one change, look at it in the preview, then ask for the next.

If you ask for five changes and something breaks, you won’t know which change did it. A small prompt is easy to check and easy to undo. Name the element, the state and what should stay the same: “Make the Water button turn green and show ‘Watered today’ when tapped. Don’t change the other buttons.” Claude can check its own work in the desktop app’s preview, but look yourself as well. Tap it, try it on a phone and check the screen that comes next.

Here is one small change, from prompt to preview.

Make bad changes cheap to undo. The simplest way is Git: after each change that works, ask Claude to commit it with a message that says what changed. Before something big, such as “Redesign the Today screen”, you then have a clean point to come back to.

Claude Code also saves checkpoints as you go. Each prompt creates one. In the terminal, typing /rewind, or pressing Esc twice with the prompt box empty, opens a menu where you can restore the code, the conversation or both to an earlier point. It has limits. Changes made by commands Claude runs, rather than by its own file edits, aren’t tracked, and Anthropic says rewind is not a replacement for version control. Use both.

A prototype needs believable data, not real data. Ask Claude to write a file of made-up plants with the awkward cases built in: a very long name, a plant that has never been watered, a room with nothing in it. You will learn more from those than from three tidy rows.

Never paste real customer data, passwords or API keys into the chat or the project folder. Prototypes get zipped, shared and pushed to places nobody planned. If a flow seems to need a real service, such as sign-in or payments, fake its answers in the prototype and leave the real thing to engineering.

The prototype exists to answer questions. Put it in front of five or six people on their own phones, give them a task, and watch. The guide on running a usability test covers the sessions themselves.

Then hand over what you learned, not just the code: what people did, where they got stuck, what you changed and the questions still open. The prototype link is evidence, and a developer can read its code to see what you meant, but don’t assume the real build will start from it. Code written this way often looks finished long before it is. Before anything like it reaches real people with real data, an engineer needs to review or rebuild it for security, accessibility and performance.