VIBE⌇BRATOR
Take the Vibe Check
Learn · The Confidence Circuit

Learn vibe coding: build, run and check

Six short lessons that take you from “it runs” to “I can show somebody this.” Each one ends with a test you either pass or you do not. No certificate, no login, no streak to keep up — just the habit, stuck in your head.

6 lessons3 h 25 min totalno signupeach one ends in a test you either pass or do not
60minutes

Your first hour: one small task, then proof

Aim for a prototype you can run and explain. Keep real customer data out of it.

  1. 0–10 minutes: name one job. Write who it is for, one input and one result you can watch happen. Open Plan Before It Types before asking for code.
  2. 10–30 minutes: generate and run. Pick a builder or coding agent, give it your small task and run what it creates. A preview is the beginning of checking.
  3. 30–50 minutes: inspect the result. If it breaks, use Hand It An Error. If it appears to work, use Define Done and check its published failure notes. The ten-minute check walks through it.
  4. 50–60 minutes: save the evidence. Use Show Your Work to record what changed, what ran and what remains unchecked. Before sharing a real app, answer the Vibe Check honestly.

At the end, be able to say what works and what you have not verified. The six lessons below go deeper; this first hour does not replace them.

01of 6

Read the changes before you run them

The one step no machine can do for you.

25 min

Goal

Get into the habit of reading every change the AI made before you run it, and know what you are looking for while you read.

Why

Vibe coding goes wrong the moment you accept something you did not read. Not because the AI is bad — because reading it was the only check that was entirely yours, and you skipped it. Reading is slower than running. That is the point.

Do this

  1. Take the last change an AI made for you. If you do not have one, ask it for one small feature in a throwaway project.
  2. Before you run anything, read the whole list of changes, top to bottom. Every block of it. Out loud if that helps.
  3. Beside each block write one of three words: ASKED (I wanted this), EXTRA (I did not), or UNSURE (I cannot tell what this does).
  4. Send the EXTRA list back with the Stop Refactoring prompt. Send the UNSURE list back with Explain It Like I Own It.
  5. Now, and only now, run it.

The check

You can name, from memory, one change in there you would have shipped without noticing if you had not read it. If you cannot, it was too small to learn on. Pick a bigger one.

Uses

02of 6

Write the rules file

Say it once, in a file, instead of every single time.

40 min

Goal

Write a rules file for a real project, built from what is actually in it, and prove a brand-new session can work from that file alone.

Why

Every session starts with the AI remembering nothing. Anything you catch yourself repeating — the tools, the commands, the things it must never touch — belongs in a file the tool reads on its own. This is the best forty minutes you will spend here.

Do this

  1. Pick a project you will come back to more than once. Open it with whichever AI you use.
  2. Run the Write the Rules File prompt. It should point at a real file for every rule it writes down.
  3. Read what it gives you. Delete anything that is a wish. Delete anything you cannot check is true today.
  4. Save it in the top folder of your project, under the name your tool looks for. Claude Code, Codex and Cursor each say which name in their own instructions.
  5. Start a completely new session with no other instructions. Ask it to run the tests.

The check

The new session runs the tests correctly without asking you a single question. If it asks something, the answer goes into the rules file and you try again.

Uses

03of 6

Watch the test fail first

A test that never failed has never proved anything.

45 min

Goal

Ship one feature where the test existed first, and you watched it fail, before a line of the code was written.

Why

“It runs” is the cliff everybody falls off: it works on the one path you walked in front of somebody, and nowhere else. A test written after the code passes automatically — it was written to match. A test written first is a target the AI has to hit, and watching it fail once is the only proof it is testing anything at all.

Do this

  1. Pick something small enough to describe in one sentence. Smaller than that.
  2. Run the Red Before Green prompt. Stop it at step one: the test, the command, and the raw failing output.
  3. Read the failure. It has to be about the missing behaviour, not a typo or a missing import. If it is not, fix the test, not the feature.
  4. Say go. Let it write the code. It is not allowed to touch the test.
  5. Run the test yourself, in your own terminal, not in the AI's window.

The check

You have a screenshot or a saved log of the same test failing, then passing, and you ran the passing one yourself. Keep both.

Uses

04of 6

Know your building

Every bug lives on a floor. Learn the floors.

30 min

Goal

Match your own app to the ten floors of the stack, and find your last three bugs on that map.

Why

Most of the confusion in vibe coding is not about code. It is about not knowing where you are standing. “The button does nothing” can live in the lobby, in a hallway, at the membership desk or down in the stockroom, and the fix is different on every floor. Once you can name the floor, you can ask a question worth answering.

Do this

  1. Read The Stack page all the way down. Every panel.
  2. On paper, list your app's ten floors. Where you do not have one — no background jobs, say — write “none”. That is information too.
  3. Take your last three bugs, or the last three things that confused you, and put each one on a floor.
  4. For each, write the question you should have asked, naming the floor. “Why does the hallway for /orders hand back rows this person does not own?” beats “why is the orders page wrong?”

The check

All three bugs are on a floor, and at least one is on a different floor than you first guessed. If all three landed exactly where you thought, you were already doing this. Move on.

Uses

05of 6

Lock the doors

Who are you, and which floors does your badge open?

45 min

Goal

Close the three blockers in the Vibe Check: watch an important test fail then pass, remove secrets from files and saved history, and check identity plus permission on every way in.

Why

An app can check who you are and forget what you are allowed to touch. A login screen does not prove that one customer cannot reach another customer’s data. The Vibe Check also blocks on missing test evidence or exposed keys, whatever the overall score.

Do this

  1. Search the project, and its saved history, for anything key-shaped. Anything you find is already leaked: replace it first, then take it out.
  2. List every way into your app. Beside each, write how the server checks identity and permission. Test that one customer cannot reach another customer’s records.
  3. Run the Security Boundary prompt on your most sensitive table. Get the failing test first, then the rule that makes it pass.
  4. Run Dependency Interrogation on your list of add-ons. Remove anything marked UNVERIFIED before you read any further.
  5. Take the Vibe Check. Answer the three blockers honestly.

The check

All three blockers are a yes, with evidence for each: an important test that failed then passed, the secrets/history search, and the server-side identity and permission checks. Customer-isolation tests help verify that permission boundary.

Uses

06of 6

Ship with a receipt

“I did it” is not proof that it is done.

20 min

Goal

End a session with a Build Receipt and a Cold Handoff, then start the next session from those instead of from your memory.

Why

The last message of a session is the one you will lean on tomorrow and the one you are least likely to read properly. A receipt separates what was actually checked from what was only claimed. A handoff stops tomorrow's session from redoing, or undoing, what today's one did.

Do this

  1. At the end of a real working session, run Build Receipt. Read the NOT verified part first. If it is empty, push back — nothing is ever fully checked.
  2. Run Cold Handoff. Read it as if you were the next AI: is the first move obvious?
  3. Save both files in the top folder of your project, alongside the work.
  4. Tomorrow, open a new session and paste in the handoff, and nothing else. Explain nothing.
  5. Compare what it does first with what the handoff said to do first.

The check

The new session's first move matched the handoff, and nothing on the receipt's changed list got done twice. Two sessions, one thread of work, no memory needed.

Uses

When you get to the end

Go round again on your next project. The lessons stay the same; your code does not, and neither does what you catch. The day these checks stop teaching you anything is the day you stopped guessing — you are just building now, with a very fast helper.

Keep the Lexicon open for any word you do not know, the Prompt Deck for the exact words each lesson asks you to paste, and run the Vibe Check before you show anything to anybody.