Lesson 3.0 · Software Builder Track
Vibe coding is what happens when you stop trying to learn a programming language and start directing one — you describe what you want in plain words, an AI writes the code, and your job shifts from typing to steering. The term was popularized by AI researcher Andrej Karpathy in early 2025, and it has been misunderstood ever since. This lesson shows what it actually looks like, with receipts from the day this site’s own bot was born — in one chat, by a builder who does not write code.
You’ve entered the Software Builder track, which means one thing changed: from here on, the things you build either run or they don’t. That sounds scarier than the media or business tracks. It’s actually a gift — code is the most honest feedback in the world, and this whole track is built on learning to hear it.
What vibe coding actually is — and isn’t
The misunderstanding: “the AI does everything while you watch.” If that were true, every request would produce working software and the world would be drowning in useful tools. It isn’t, because raw AI output drifts — it overbuilds, it guesses, it forgets who it’s talking to. Vibe coding is a division of labor with a hard line down the middle: you own the what and the why; the AI owns the syntax. You never touch the grammar of the code, but you make every decision that matters — what gets built, what gets cut, who it’s for, and when it’s done.
Three things stay permanently on your side of the line. Scope: AI’s default instinct is to build a cathedral when you asked for a shed — left alone, it adds features nobody requested. Audience: AI writes instructions for the person it imagines, not the person you are; when it assumes knowledge you don’t have, that’s your correction to make, loudly. Judgment on errors: when something breaks, the error message is material you hand back, not a verdict on you. None of these require knowing code. All of them require holding the wheel — the same pushing muscle you trained in Lesson 1.1, with sharper consequences.
The experiment: the Wheel Test
Fifteen minutes, any AI chat, nothing to install — you’re testing steering, not running code yet.
Step 1 — Ask loose, on purpose. “Write me a script that organizes the files in a messy folder.” Nothing more.
Step 2 — Count the cathedral. Read what comes back and count the features you never asked for — config options, logging, edge cases you don’t have. That’s the overbuild instinct, live.
Step 3 — Steer on scope. “Cut everything except one feature: move images into a folder called Photos. Nothing else.”
Step 4 — Steer on audience. “Now explain how to run it to someone who has never opened a terminal in their life. Assume nothing.”
Step 5 — Compare. Put version 1 and version 3 side by side. The difference is not the AI improving — it’s you steering. That gap is the entire skill.
From the build log: one chat, one running script
This site’s Tier 3 companion build is a small SEO morning-report bot: every day it reads this site’s Google Search Console data and sends one summary message to Telegram. In a single chat session, with zero hand-typed code, it went from nothing to alive — Search Console verified, a Google Cloud key created, a Telegram bot registered, the full Python script written by the AI. And the first run went straight through:

From the build log: the first run, exactly as it happened. Every number is zero because the site was still hidden from Google on purpose — and the report says so itself, right down to its last line. The builder is Indonesian; receipts on this site are shown as-is, untranslated. Real is real.
But the receipt that matters more is the one where the wheel is visibly being held. Mid-build, the AI handed over the script with instructions that began, casually, “run pip install” — as if everyone on earth knows what pip is. The builder does not code. Instead of nodding along and getting stuck in private, he hit back, in his own words:

From the build log: roughly translated — “No plans to tell me how to install pip, or how to run this thing? That’s just stupid — as if the reader already understands everything.” The AI had forgotten its audience. The human corrected it, and the instructions were rewritten from zero. That correction — not the code — is vibe coding.
One honest footnote: “the first run went straight through” is not the norm, and it wasn’t even the whole truth of that day. Earlier in the same chat, one mistyped URL produced the build’s first real bug — and fixing it cost a security token its life. That story gets its own lesson later in this track. Builds that look smooth in hindsight never were.
Why the wheel stays in your hands
Everything that went right in that build traces back to a human decision, not an AI one. The bot exists because a sprawling four-agent enterprise blueprint — drafted by an AI, naturally — was cut down by the human to one script with one job. The instructions became usable because the human refused to accept expert-only steps. The secrets stayed secret because the human followed the rule he learned back in Lesson 0.4: keys and tokens never get pasted anywhere, ever. The AI supplied speed and syntax. Every safeguard was human.
The Vibe-Coding Contract — your takeaway, three lines. Keep it where you build:
1. I decide what gets built — and what gets cut.
2. The AI decides how the code is written — I never touch syntax.
3. Every error is material I hand back, never a reason to quit.
Run the Wheel Test — one loose request, two steers, then put version 1 next to version 3 and save the comparison in your build log. That side-by-side is the before-and-after photo of the only skill this entire track is built on: not typing code, steering it.
The wheel is yours. Next: the unglamorous hour that powers every real bot.Next — Lesson 3.1: AI Build Setup →