Lesson 3.2 — Vibe Coding: Build by Describing

You're the Architect, AI Is the Builder

You've probably heard that to build an app or a website, you need to learn to code. That used to be true. It's not anymore.

Vibe coding is a real approach that real people use right now to build real things — apps, websites, tools, dashboards. Here's how it works: you describe what you want in plain English, and an AI coding tool writes all the code for you. You test it. You tell AI what to change. AI makes the changes. You test again. Repeat until it's exactly what you want.

You don't write code. You don't read code. You direct the process — like an architect who designs a building but doesn't lay the bricks. The AI is your construction crew.

This isn't a shortcut or a cheat. It's how software development is actually changing. Professional developers use this approach. Entrepreneurs use it to build and launch products. And now you're going to use it to build your project.

Why it's called "vibe coding"

The name comes from the idea that you're coding by vibes — describing the feel, the look, the behavior you want, and letting AI translate your vision into working code. You focus on what the app should do and feel like. AI handles the how.

Answer: In traditional coding, you write every line of code yourself. In vibe coding, you describe what you want in plain English and AI writes the code. You focus on the vision and direction; AI handles the technical implementation.

Describe → Build → Test → Refine

Vibe coding follows a simple loop. Once you learn this loop, you can build almost anything:

1. Describe what you want.

Write a clear description of what you're building. Be specific about features, layout, and behavior. This is where your prompting skills from Module 2 come in — the better your description, the better AI's first attempt.

2. AI builds it.

AI generates the code — the complete working files for a webpage, an app, a tool, whatever you described. You don't need to understand the code. You need to understand what it's supposed to do.

3. Test it.

Open it up. Click every button. Try every feature. Does it do what you asked? Does it look right? Does anything feel off? You're testing as a user, not as a coder.

4. Refine with feedback.

Tell AI what to change: "The background should be darker." "Add a button that resets the form." "When I click submit, nothing happens — fix that." AI makes the changes. You test again. Loop until it's right.

That's it. That's the whole process. You'll go through this loop many times on your project — sometimes three rounds, sometimes fifteen. Each round gets you closer to what you envisioned.

This connects to Lesson 3.1

Remember the director's mindset? Vibe coding IS the director's mindset applied to building. You're directing AI through every round of that loop — giving feedback, making decisions, shaping the final product. The AI generates, you direct. Same principle, now applied to building real things.

Answer: Describe what you want → AI builds it → Test it → Refine with feedback. And then the loop repeats — your refinement becomes the next description, AI builds again, you test again.

Your Description Is the Blueprint

The quality of what AI builds depends almost entirely on the quality of your description. A vague prompt gets vague results. A specific, detailed prompt gets something close to what you actually want.

Here's what makes a great build request:

What it is:

"Build me a habit tracker web app."

What it should do:

"Users can add custom habits, check them off each day, and see a streak counter that tracks how many days in a row they've completed all habits."

What it should look like:

"Clean, modern design. Dark background with bright accent colors. Mobile-friendly. The habits should be displayed as a list with checkboxes."

What happens when users interact:

"When a user checks all habits for the day, show a congratulations message. When they add a new habit, it appears at the bottom of the list. Include a reset button that unchecks everything for a new day."

Weak request:

"Make me a habit tracker."

AI will build something, but it'll guess at every detail — and those guesses probably won't match your vision.

Strong request:

"Build a habit tracker web page. Features: users type in a habit name and click 'Add' to create a new habit. Each habit shows as a card with a checkbox. Checking the box turns the card green. A counter at the top shows 'X of Y habits complete today.' There's a 'New Day' button that resets all checkboxes. Design: dark mode, rounded corners, clean font, mobile-responsive. The page title is 'Daily Wins.'"

See the difference? The strong request describes the what, the how it works, and the how it looks. AI has enough to build something very close to your vision on the first try.

You already learned this skill

This is prompting (Module 2) applied to building. The same principles — be specific, give context, describe the output format you want — work whether you're asking AI to write an essay or build an app. Your prompting skills are your building skills.

Answer: B, by a mile. It describes what the user sees, how they interact, what feedback they get, and what it looks like. AI can build something close to the vision on the first attempt. With A, AI has to guess everything.

You're a User, Not a Developer

When you test what AI built, you're testing it the way a user would — not by reading the code, but by using the thing. Click every button. Fill in every form field. Try to break it. Here's your testing checklist:

Does it do what I asked?

Go through your original description feature by feature. Did AI include everything? Does each feature work the way you described?

Does it look right?

Check colors, layout, spacing, and fonts. Does it match the design you described? Is it readable? Does it look good on your phone?

What happens at the edges?

Type nothing and hit submit. Type something weird. Click buttons twice. Resize the window. These "edge cases" are where things often break.

Does anything feel off?

Trust your gut. If something feels clunky, confusing, or wrong — even if you can't explain exactly why — that's valid feedback. Describe the feeling to AI: "The form feels confusing — I'm not sure what order to fill things in. Can you make the layout clearer?"

How to Describe Problems to AI

When something's wrong, describe it the way you'd describe it to a friend — you don't need technical language:

What you expected: "I expected the counter to go up when I check a habit."
What actually happened: "Nothing happens when I click the checkbox. The counter stays at 0."
What you were doing when it broke: "I added three habits, then tried to check the first one."

That's a perfect bug report. AI has everything it needs to find and fix the problem. You don't need to know what a "variable" is or where the bug is in the code. You just describe what went wrong from your perspective as a user.

Pro tip: When AI fixes something, ask it: "What was the problem and what did you change?" Not because you need to understand the code — but because understanding what went wrong helps you write better build requests next time. You start to learn the kinds of things that trip AI up, and you can prevent them upfront.

Key Concepts

Vibe coding is an AI-assisted development approach: you describe what you want in natural language, and AI writes the code.
The workflow is a loop: Describe → AI builds → Test → Refine with feedback → Repeat.
Better descriptions produce better first attempts. Be specific about features, behavior, and design.
Test like a user: click everything, try edge cases, trust your gut when something feels off.
Describe problems using "what I expected vs. what happened" — no technical language needed.
You don't need to read code, but notice three things: file names, error messages, and unexpected changes.

Try It: Vibe Coding Challenge

Put the vibe coding workflow into practice. You'll go through 3 rounds of building: write a description, review what AI "built," find issues by testing as a user, and write feedback to fix the problems. Each round gets more complex — from a simple countdown timer to a full quiz app. No code reading required — everything is tested and communicated in plain English.

Answer: "When I click the 'Next Question' button, nothing happens — the page stays on the same question. It should advance to the next question in the quiz." You don't need to know why it's broken. You just describe what should happen vs. what actually happens.

You Don't Need to Read Code — But Here Are Three Things Worth a Glance

You don't need to understand code to vibe code. But as you work with AI, you'll occasionally see code, file names, or error messages. Here are three things that are worth a quick glance — not to "learn to code," but just to keep your bearings:

1. File names tell you what's what.

If your project has multiple files, the names usually tell you their purpose: index.html is typically the main page, styles.css controls how things look, app.js controls how things work. If AI asks "which file should I edit?" — the names help you point it in the right direction.

2. Error messages tell you something broke (and sometimes what).

Error messages look scary but they usually say something simple: "Cannot find X" means something's missing. "X is not defined" means something wasn't set up. You don't need to fix these — just copy the error message and paste it to AI: "I'm getting this error. What's wrong and how do we fix it?" But noticing that an error happened is useful.

3. AI sometimes changes things you didn't ask it to change.

When you ask AI to fix one thing, it occasionally "helpfully" modifies something else. If the app looks or behaves differently in ways you didn't request, tell AI: "I only asked you to fix the button. It looks like other things changed too — undo everything except the button fix." This is about noticing a change, not understanding the code behind it.

That's it. That's all you need.

Three things: file names, error messages, unexpected changes. Everything else — the actual code, the syntax, the structure — that's AI's job, not yours. Some students will get curious and start reading code on their own. That's great. But it's optional, not required. You can build impressive, functional projects through vibe coding alone.

Reflect & Write

Think about a time you wanted to build something — a website, an app, a tool — but gave up because you thought you needed to learn to code first. Knowing what you know now about vibe coding, would that project have been possible? Write 2–3 sentences about how this changes what you think you can build.

Project Checkpoint

Now it's time to take your first vibe coding step on your actual project:

Write a detailed build request for one piece of your project — a single page, one feature, or a core component. Use the blueprint approach: what it is, what it does, what it looks like, how users interact with it.
Give this description to AI and let it build it.
Test the result as a user. What works? What's off? What's missing?
Write 2–3 rounds of feedback and get improved versions.
Save your final version — this is the start of your real project!

Level Up: Coming Next

Lesson 3.3 — Setting Up Your Workspace. Now that you know how vibe coding works, it's time to set up your workspace and take a test drive. You'll get your AI coding tool ready and build something small to prove the workflow works — so you're fully prepared when the real building starts in Module 5.

Continue to Lesson 3.3 →

Vibe Coding: Build by Describing, Not by Typing