Vibe Coding: A Fast Path to a First Working Prototype

Why it matters#

Vibe coding means building software mostly by describing what you want in plain language, looking at the result, and asking for changes, often without reading much of the code. It can be a fast way to turn an early product idea into something people can click. Use it to explore an interaction and test assumptions; a working prototype still needs engineering and verification before people depend on it.

Andrej Karpathy coined the term in February 2025. He described accepting every change the AI made, no longer reading the diffs, and pasting error messages back without comment, and he called it “not too bad for throwaway weekend projects” (Karpathy, 2025). This chapter keeps the speed and drops the part where you stop reading.

It is also where habits form. If your first experience is “prompt until it looks right”, you will carry that into bigger projects, where it stops working. Architects use vibe coding deliberately: to explore ideas and test them with people quickly, while keeping checkpoints, boundaries, and a clear record of what the prototype does and doesn't do.

By the end of this chapter you will have the first version of the book's running project, the AI Learning Coach: a clickable prototype that you can show to real users and build on in later chapters.

Learning objectives#

After this chapter you will be able to:

1. Choose an AI coding tool for a task, and set it up with checkpoints and safe handling of secrets.
2. Write prompts that describe users, outcomes, constraints, and acceptance checks, and ask for small, runnable steps.
3. Build an interactive prototype with realistic mock data, form validation, and loading and error states.
4. Manage iterations so you can always get back to a working version.
5. Review a prototype for broken flows, accessibility problems, hidden dependencies, and hard-coded values.

2.1 The AI coding workspace#

An AI coding tool is any program where an AI writes or changes code for you. They fall into four broad families. Product names change quickly; the families are more stable.

Tool landscape reviewed October 2026. Check each tool's current features and pricing before choosing.

Choosing a tool#

Ask three questions:

• What is the task? A first look at an idea suits a browser builder. A project you will keep developing suits a code editor or terminal agent working on files you own.
• What can the tool touch? Some tools only suggest code; others can create files, install software, and run commands. More power is useful, and it raises the cost of a mistake. Start with the least access the task needs.
• Where does the code live? If the code lives only inside a website, you depend on that website. If it lives in a folder on your computer and in a repository you control, you can switch tools at any time.

Checkpoints: your safety net#

A repository is a project folder whose history is tracked by Git, a version-control tool. A commit is a saved snapshot of the whole project with a short note. Think of it as a save point in a game. A branch is a separate line of work, so you can try something without touching the version that works.

You don't need to be a Git expert yet. You need one habit: every time the app works, save a checkpoint. In a code editor, that is a commit. In a browser builder, use its version history or “restore” feature. Chapter 4 explains Git properly. If you want to read ahead, the book Pro Git is free online (Chacon & Straub, 2014).

Secrets and personal data#

A secret is anything that grants access: API keys, passwords, database addresses with passwords in them. Treat them like house keys.

• Never paste a secret into a prompt or directly into code. Put it in an environment file (usually named .env) that is excluded from your repository, and ask the AI to read it from there.
• Assume anything you paste into an AI tool may be stored. Don't paste other people's personal data, and check your tool's privacy settings.
• If a secret leaks, revoke it (cancel it on the provider's website) and create a new one. Deleting it from the code is not enough, because it stays in the history (GitHub Docs; OWASP).

In this chapter the prototype needs no secrets at all: it uses mock data, so there is nothing to leak.

Sidebar: what the AI can and can't see#

An AI coding tool only knows what is in its context: the text it is given for this request. Depending on the tool, that may be your prompt, the conversation so far, the files you opened, or files it chose to read. It does not remember last week's session unless the tool saves notes, and it cannot see what is on your screen unless you show it.

This explains a lot of surprising behavior:

• It “forgets” decisions. In a long conversation, early instructions can drop out of view. Models also use long inputs unevenly: in one study, accuracy dropped when the information needed sat in the middle of a long input rather than near the start or end (Liu et al., 2024). If something matters every time, such as “use TypeScript” or “never change the routes”, repeat it, or put it in a project instructions file that your tool reads automatically.
• It invents things. If the AI hasn't seen a file, it may guess what is in it, and guess wrong with confidence. This includes whole software packages: one study found that code-generating models suggested package names that don't exist at least 5.2% of the time for commercial models and 21.7% for open-source ones (Spracklen et al., 2025). Ask the AI to read the relevant files before changing them, and check that any library it adds is real.
• It can't test what it can't run. A browser builder can usually run your app; a chat assistant usually can't. If the AI hasn't run the code, “this should work” means “this looks plausible”.

Chapter 10 turns this into a skill called context engineering: deciding what the AI needs to know for each task, and keeping it up to date.

2.2 Prompting for software outcomes#

A prompt for software is a small specification. The more clearly it says what “done” looks like, the better the result, and the easier it is for you to check.

A useful prompt answers six questions:

1. Who is it for? (“University students preparing for an exam.”)
2. What job are they trying to get done? (“Turn a goal into a weekly plan they can follow.”)
3. What should they be able to do? Describe the steps a user takes.
4. What are the constraints? Platform, language, framework, style, and anything you don't want.
5. What examples help? A sketch, a screenshot, sample data, or an app you like.
6. How will you know it works? Two or three checks you will try yourself.

Compare two prompts:

Vague: Make a study app with AI.

Specific: Build a single-page web app for university students preparing for an exam. Use React with TypeScript. The home page has a short welcome and a “Create my plan” button. The button opens a form with: goal (text, required), exam date (date, must be in the future), and hours per week (number, 1–40). For now, generate the plan from sample data, with no real AI and no backend. Done means: (1) the form shows clear errors for missing or invalid fields, (2) a valid form shows a loading state and then a six-week plan, (3) everything works with a keyboard alone.

The second prompt is longer, but it gives the AI a target and gives you a test.

Show, don't only tell#

AI tools are good at matching examples. If you can show what you mean, do:

• A sketch. A photo of a hand-drawn screen layout is often clearer than three paragraphs describing it.
• A screenshot of an app you like, with a note on what to borrow: “the card layout, not the colors”.
• Sample data. Two or three realistic example goals and plans tell the AI far more about tone and length than “make realistic tasks”.
• The expected behavior, step by step. “When I press Submit with an empty goal, the message ‘Please enter a goal’ appears under the field and focus moves to it.”

Never use screenshots that contain other people's personal information, and remember that anything you upload may be stored by the tool.

Ask for runnable increments#

Don't ask for an entire platform in one go. Ask for the smallest next step that you can run and check, then build on it. A good rhythm is one prompt, one visible behavior, one check, one checkpoint.

Architect's decision: where should the prototype live?#

2.3 Worked example: the Learning Coach prototype#

The goal of the prototype is to test one question with real people: does a step-by-step study plan from a goal feel useful? It doesn't need accounts, a database, or real AI yet. Those come in later chapters.

Here is the user flow you will build:

flowchart LR
    W[Welcome page] -->|Create my plan| F[Goal form]
    F -->|invalid| F
    F -->|valid| L[Loading]
    L --> P[Study plan]
    L -->|error| E[Error message with Try again]
    E --> F
    P -->|tick a task| P
    P --> R[Progress summary]

Work through the steps in order. After each one, run the app, check it, and save a checkpoint.

Step 1: Set up the project and the welcome page#

Create a new React + TypeScript project using Vite. Make a welcome page for “Learning Coach” with a one-sentence description (“Turn a study goal into a weekly plan you can follow”) and a “Create my plan” button that goes to a page at /plan/new. Use a clean, readable style with good color contrast. Explain how to run the project.

If you want to see what the AI is doing, the official Vite guide shows the same setup (Vite).

Check: the app runs on your computer; the button opens the new page; the address bar shows /plan/new. Save a checkpoint.

Step 2: The goal form, with validation and loading#

On /plan/new, add a form with: goal (text, required, up to 200 characters), exam date (required, must be after today), and hours per week (required, whole number from 1 to 40). Show an error message under each invalid field when the user submits. Each field needs a visible label. When the form is valid, show a loading message for about one second, then go to /plan. Don't change the welcome page.

Check: submit an empty form, a date in the past, and 0 hours. Each should show a clear message. Use only the keyboard (Tab, Enter) to complete the form. Save a checkpoint.

Step 3: A study plan from mock data#

Mock data is realistic sample data that stands in for a real source while you prototype. It lets you test the experience before building the hard parts. The rule is simple: mock data must look realistic, but never pretend to be live.

Ask the AI to keep the mock in one clearly named place, so it is easy to replace later:

Create a file src/mock/planGenerator.ts with a function generateSamplePlan(goal, examDate, hoursPerWeek) that returns a six-week plan after a short fake delay. Each week has a focus and three to five tasks. Base the tasks on a fixed sample list, and include the user's goal text in the plan title. The /plan page shows the plan as a list of weeks with a checkbox per task. Show a small label at the top: “Sample plan (generated from example data)”.

The AI will produce something like this. You don't need to write it yourself, but you should be able to read it:

export type StudyTask = { id: string; title: string; done: boolean };
export type StudyWeek = { week: number; focus: string; tasks: StudyTask[] };
export type StudyPlan = { title: string; examDate: string; weeks: StudyWeek[] };

// Prototype only: stands in for the AI planner added in chapter 9.
export async function generateSamplePlan(goal: string, examDate: string, hoursPerWeek: number): Promise<StudyPlan> {
  await new Promise((resolve) => setTimeout(resolve, 800));
  return {
    title: `Plan: ${goal}`,
    examDate,
    weeks: SAMPLE_WEEKS.map((week, index) => ({
      week: index + 1,
      focus: week.focus,
      tasks: week.tasks.slice(0, hoursPerWeek < 5 ? 3 : 5).map((title, n) => ({ id: `${index}-${n}`, title, done: false })),
    })),
  };
}

Reading it, you can already answer useful questions: the plan's shape is defined by three types (descriptions of what the data looks like); the delay is fake; the number of tasks depends on hours per week; and the comment says when this will be replaced. Those types will matter in chapter 5, when the real backend must return exactly the same shape.

Check: the plan shows six weeks, uses your goal in the title, and carries the “Sample plan” label. Save a checkpoint.

Step 4: Progress you can see#

On the /plan page, add a progress bar above the weeks showing tasks done out of the total, with the number written out (“7 of 24 tasks done”). Ticking a checkbox updates it immediately. Keep the plan and ticks in the browser's local storage, so they are still there after a page refresh. Don't change the form or the welcome page.

State is the information an app remembers while you use it. Here, that is the plan and which tasks are ticked. Local storage keeps that state in your browser, on this one device (MDN). That is fine for a prototype; chapter 6 moves it to a real database so it follows the user.

Check: tick three tasks, refresh the page, and the ticks and the count are still there. Save a checkpoint.

Step 5: Loading, empty, and error states#

Real apps spend a lot of time in states other than “everything worked”. Prototypes that ignore them feel broken the first time something goes wrong.

Handle three extra cases. (1) If someone opens /plan with no saved plan, show a friendly message with a link to create one. (2) If plan generation fails, show “We couldn't create your plan. Try again.” with a button that returns to the form with the fields still filled in. To test it, make generateSamplePlan fail when the goal contains the word “fail”. (3) While the plan is loading, the submit button is disabled so it can't be pressed twice.

Check: open /plan in a private window (no saved plan); type a goal containing “fail”; press Submit twice quickly. Save a checkpoint.

Step 6: Feedback from real people#

Show the prototype to three to five people from your target group. Give them a task, such as “make a plan for an exam you have coming up”, and watch without helping. Write down where they hesitate, what they misread, and what they ask for. You don't need a big group: Jakob Nielsen's research suggests about five testers find most of a design's usability problems, and several small rounds beat one large one (Nielsen, 2000).

Then turn feedback into small prompts, one change at a time:

Testers didn't notice the progress bar. Move it directly under the plan title and make it taller. Don't change anything else.

AI collaboration recipe#

Use this template for each step. Copy it into a notes file and reuse it.

### Change
One visible behavior, in one sentence.

### Where
The page or file this affects. Say what must NOT change.

### Details
Fields, rules, wording, layout, sample data.

### Done means
Two or three checks I will try myself.

### Please also
Explain what you changed and which files you touched.

Boundaries to state every time:

• “Don't change other pages.” This prevents most surprise breakages.
• “Don't add new libraries without asking.”
• “Don't put any keys, passwords, or personal data in the code.”
• “Explain what you changed.” It trains you to read the summary, and gives you something to check.

2.4 Managing iterations#

Change one behavior at a time. If you ask for three changes and something breaks, you won't know which one did it.

Preserve known-good versions. Save a checkpoint every time the app works. Name it after the behavior: “Goal form validates exam date”. If a change goes wrong, go back instead of digging deeper.

Write reproducible bug reports. When something breaks, tell the AI exactly what you did, what you expected, and what happened:

Steps: open /plan/new, fill all fields, press Create my plan.
Expected: loading message, then the plan page.
Actual: the page stays on the form; nothing happens.
Started after: the change that made the Start button bigger.

This works better than “it's broken, fix it”, for an AI and for a person.

Check the AI's summary against reality. Most tools end with a confident summary: “I updated the form and added validation.” Summaries are useful, but they are written by the same system that made the change, and they can leave things out. Compare the summary with the list of files that actually changed. If a file you didn't expect was touched, find out why before you save a checkpoint. In a browser builder, ask directly: “List every file you changed and why.”

Know when to stop prompting. Prompting is the right tool until the problem is no longer about one behavior. Stop and look at the structure (chapters 4 and 5 show you how) when:

• the same bug comes back after being “fixed” more than twice;
• each fix breaks something somewhere else;
• the AI rewrites large files to make small changes;
• you can no longer explain, even roughly, what each file is for.

These are signs of tangled structure, not of a bad prompt.

2.5 Verification: reviewing the prototype#

A prototype that looks right is not necessarily working. Before you show it to anyone or build on it, review it on purpose.

Ten acceptance checks#

An acceptance check is a concrete test of “done” that anyone can perform. Write yours down and run all of them after every significant change.

Smoke test#

A smoke test is a quick run through the main path to see whether anything is obviously on fire: open the app, create a plan, tick a task, refresh. Do it after every change, before saving a checkpoint.

Screen sizes and accessibility#

Accessibility means people can use the app regardless of disability, for example by using a keyboard instead of a mouse, or a screen reader that reads the page aloud.

• Make the browser window narrow, like a phone. Does anything overlap or disappear?
• Use only the keyboard. Can you reach and press everything, and can you see where the focus is?
• Does every form field have a visible label, and are error messages next to the field they describe?
• Is text readable against its background? Many browsers have built-in accessibility checks in their developer tools.

These checks come from the Web Content Accessibility Guidelines (WCAG) 2.2, the W3C standard: content works at narrow widths (1.4.10), everything works from a keyboard (2.1.1), focus is visible (2.4.7), fields have labels (3.3.2), and normal text has a contrast ratio of at least 4.5:1 (1.4.3) (W3C, 2023).

Hidden dependencies and hard-coded values#

Ask the AI, and then check for yourself:

List every external service, library, and hard-coded value in this project, such as addresses, keys, fixed dates, and sample data. Mark which ones must change before real users rely on it.

Look especially for localhost addresses, anything that looks like a key, dates fixed to “today” when the code was written, and sample data that a real feature should replace.

Handoff notes#

Finish with a short README.md in the project, so future you, a teammate, or an AI agent knows what this is:

# Learning Coach prototype

What it does: turns a study goal into a six-week plan you can tick off.
How to run it: npm install, then npm run dev.
What is fake: the plan comes from sample data in src/mock/planGenerator.ts.
What is missing: accounts, a database, real AI, deployment.
Known issues: progress is stored only in this browser.

Sidebar: prototype, MVP, or production?#

People use these words loosely, and the confusion causes real problems, such as letting customers rely on a demo. Be precise about which one you have. The term MVP was popularized by Eric Ries as the smallest version of a product that lets you learn from real customers (Ries, 2011).

At the end of this chapter you have a prototype. That is exactly what you need right now, as long as nobody mistakes it for more.

Failure clinic: the button that broke navigation#

Back to Maya's Wednesday morning. You can reproduce it in your own prototype.

Symptom. After the prompt “make the Start button bigger and more colorful”, the button looks great, but pressing “Create my plan” on the form no longer opens the plan.

Reproduce. Run acceptance checks 1–10. Checks 1–4 pass; check 5 fails. The loading message never appears.

Look at what changed. In a code editor, open the list of changes since your last checkpoint (Git calls this a diff: the lines added and removed). You find the AI didn't only restyle the button. It also “tidied up” the routes and renamed the plan page from /plan to /study-plan. The form still sends users to /plan, which no longer exists.

Fix. Go back to the last checkpoint. Then repeat the change with a boundary:

On the welcome page only, make the “Create my plan” button larger, with the brand color as background. Change only the button's styling. Don't rename routes or change other files.

Run all ten checks again, then save a checkpoint.

Lesson. The AI did what it often does: it made a “helpful” extra change you didn't ask for. You can't stop that entirely, but three habits make it cheap: small requests with boundaries, checkpoints after every working step, and acceptance checks that catch the regression in seconds. A regression is something that used to work and now doesn't.

Architect's checklist#

Before you call the prototype done:

• ☐ The code lives in a repository I control, with a checkpoint for each working step.
• ☐ No keys, passwords, or personal data appear anywhere in the code or prompts.
• ☐ Mock data is in one clearly named place, and the app labels it as sample data.
• ☐ All ten acceptance checks pass, and I ran them after the last change.
• ☐ Loading, empty, and error states all behave sensibly.
• ☐ The app works on a narrow screen and with a keyboard alone.
• ☐ The README says what is real, what is fake, and what is missing.
• ☐ I could explain, roughly, what each main file does.

Exercises#

Beginner. Add a “Reset plan” button that asks for confirmation and then clears the saved plan. Write one new acceptance check for it, and save a checkpoint when it passes.

Intermediate. Let users edit a task's title on the plan page. Write the prompt using the collaboration recipe, including what must not change. Afterwards, compare the AI's summary of changed files with the actual diff. Did it tell you everything?

Advanced. Introduce a deliberate bug (for example, make the progress count ignore the last week), then write a reproducible bug report and give it to a fresh AI session that has never seen the project. How quickly does it find the cause? What did your report need that it didn't have?

Deliverable#

Add these to your portfolio:

• the runnable prototype in your repository, with a clear checkpoint history;
• the README.md handoff notes;
• three screenshots: the form with errors, the plan, and the error state;
• your ten acceptance checks, with results.

Reflection#

• Which decisions did you delegate to the AI, and which did you make yourself?
• What did you verify, and how? What did you only assume worked?
• What in this prototype would be dangerous to show real users as if it were finished?
• When did rapid prototyping start to feel like it was creating a mess, and what would have prevented it?

Next, in chapter 3, you will turn what you learned from testers into a proper specification: users, needs, requirements, and the acceptance criteria that later chapters will test against.

References#

• Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Apress. Free online.
• GitHub. Removing sensitive data from a repository. GitHub Docs.
• Karpathy, A. (2025, February 2). There's a new kind of coding I call “vibe coding”… Post on X.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12.
• MDN Web Docs. Window: localStorage property. Mozilla.
• Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Nielsen Norman Group.
• OWASP. Secrets Management Cheat Sheet. OWASP Cheat Sheet Series.
• Ries, E. (2011). The Lean Startup. Crown Business.
• Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security Symposium.
• Vite. Getting Started. Vite documentation.
• W3C. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, October 5, 2023.

Links checked October 2026.