In Part VIII you learned to give an agent a bounded job — a folder to read, tools it may use, and a result it must hand back. A coding agent is that same idea with sharper teeth: its output can change the software itself. Files move. Dependencies appear. The app behaves differently.

This lesson names the working style that power makes possible.

From agents to coding agents

A research agent reads files and reports back. A coding agent reads files and *rewrites* them — then runs commands, starts the project, reads the error, and tries again. You describe the outcome; it handles much of the translation into syntax, framework setup, and boilerplate.

That is why the loop feels magical. The distance between "I have an idea" and "I can click something" collapses from days to minutes.

The style built on top of that capability has a name: vibe coding.

What vibe coding actually is

Strip away the commentary and the definition is simple:

Vibe coding is directing a build mostly through natural language while the AI produces much of the implementation.

You describe what you want. The AI writes much of the code and configuration. You try the result. You react — "closer, but the filter should work like this" — and the conversation continues until the screen resembles the idea in your head.

There is nothing shameful in that loop. It is a real way to explore ideas. The question is never "did you vibe code?" The question is "did you inspect what it built before trusting it?"

Professionals use vibe moves too

Here is the honest distinction the course will keep:

Experienced developers absolutely use vibe-coding moves. They ask for a screen, a feature, a refactor, a test, or a quick prototype in natural language. They let the model write the first draft.

The difference is not whether AI wrote the first draft. The difference is what happens next. A professional:

• reads the important code instead of admiring the screenshot,
• checks which files actually changed,
• runs the project and the tests,
• challenges unsafe assumptions,
• and refuses to treat a good-looking demo as proof the system is safe.

Same fast start. Different finish. Keep that sentence — the whole Part IX hangs on it.

The risky version has a name

Uninspected vibe coding means shipping a site because it appears to work while nobody has examined the repository, permissions, data flows, dependencies, error paths, or security posture.

For a throwaway mockup on your own laptop, that is a tolerable shortcut. The moment the site stores personal, financial, account, health, business, or other sensitive information — or controls money, private documents, or someone else's accounts — it becomes dangerous. A pretty page tells you nothing about who can read the data behind it.

The basic loop

Every vibe-coding session follows the same five steps:

idea → prompt → generated change → run it → react → next prompt

1. Idea: "I want an events page with date filters and saved favorites." 2. Prompt: you describe it in natural language. 3. Generated change: the model creates or edits files. 4. Run it: you launch the project locally and click through it. 5. React: "the layout works, but 'near me' means nothing yet" — and that reaction becomes the next prompt.

The workbench around the loop is the one from Class 6: the editor shows the files, the terminal runs the project, the browser shows the behavior, and the AI explains or changes the system. Notice what is *not* the product: the chat transcript. The product is the files plus the behavior you observed. If you cannot point to both, you have a conversation, not software.

What the model does fast — and what stays yours

Take the neighborhood events finder: "Make a page that shows events near me, lets me filter by date, and saves favorites."

A coding model can produce quickly:

• page layout and styling,
• mock event data so the page is not empty,
• date-filter controls,
• starter files and project structure.

But five decisions remain human, and the model will quietly invent answers if you leave them blank:

A good vibe-coding prompt answers as many of these as possible *before* the model builds. A vague prompt — "build the whole app" — invites the model to answer all of them for you and keep going: login, payments, database schemas, email, dashboards. That is the most common beginner mistake, and the recovery is always the same: shrink the request to one user action and one observable result.

A prototype is for learning, not for launching

A prototype is a deliberately limited version built to learn whether an idea works. It succeeds when it answers a learning question, not when it handles every edge case:

Read that last row twice. A screen is not proof that the data, accounts, billing, privacy, security, or failure paths work. Looking finished and being trustworthy are different properties. Lesson 35.2 teaches the moment the project crosses from one to the other.

A first-pass audit habit, even for small projects

Before you show anyone a prototype that touches anything beyond mock data, build one habit: ask a *second* model to inspect the repository as a reviewer, not a builder. The original coding model is attached to its own choices; a fresh reviewer is less forgiving.

Give the reviewer this job:

You do not need to understand every line it flags. You need to read its map and verify each claim against the actual files: is there really an API key in that file? Does that route really skip a login check? That verification habit — not the AI's report alone — is the skill. Class 36 will make it a full workflow; for now, practice asking for the map.

Practical exercise: write a prototype card

Create a file called PROTOTYPE-CARD.md next to your project. Keep it to one page:

# Prototype card: Neighborhood events finder

- User: a new resident exploring weekend options.
- One job: find Saturday events and save two favorites.
- One screen/workflow: event list → date filter → save button.
- Sample data: 12 hand-written events (fake, no real venues' private data).
- Will NOT do: accounts, real event feeds, payments, email, public launch.
- Question it must answer: can a first-time visitor filter and save without explanation?

Then run the project locally and watch one person — even yourself, thinking aloud — attempt exactly that job.

Finish line: a one-page PROTOTYPE-CARD.md plus a running local preview or rough clickable mockup that completes the single job.

Verify: can you point to the file, the preview, and the one question the prototype answered? If the answer is "it looks nice," you measured the wrong thing.

Common failure mode: the AI adds login, payments, and a database because the request was broad. Recovery: delete the extras from scope, restore the card to one action and one observable result, and re-prompt narrowly.

Check your understanding

1. In one sentence, what is vibe coding — and what makes a coding agent different from a chat-only assistant? 2. A professional and a beginner both let AI write the first draft. What four things does the professional do after that? 3. What is *uninspected* vibe coding, and why is it especially dangerous with sensitive data? 4. For the events finder, name two things the model creates quickly and two decisions only the human can make. 5. Why is a good-looking first screen not proof the system works?