VIBE⌇BRATOR
Take the Vibe Check
Learn

The Confidence Circuit

Six short lessons that take you from “it runs” to “I can prove it works.” Each one ends with a check you either pass or do not. No certificates, no login, no streaks — just the habit, installed.

6 lessons3 h 25 min totalno signupevery lesson ends in a check
01of 6

Read the diff before you run it

The one step no model can do for you.

25 min

Goal

Install the habit of reading every generated change before executing it, and learn what to look for when you do.

Why

Vibe coding fails at the moment you accept output you did not read. Not because the model is bad — because you have given up the only check that is entirely yours. Reading is slower than running. That is the point.

Do this

  1. Take the last change an agent made for you. If you do not have one, ask for a small feature in a scratch repo.
  2. Before running anything, read the whole diff top to bottom. Every hunk. Out loud if it helps.
  3. For each hunk write one of three words in the margin: ASKED (I requested this), EXTRA (I did not), or UNSURE (I cannot tell what it 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. Only now run it.

The check

You can name, from memory, one hunk in that diff you would have shipped without noticing if you had not read it. If you cannot, the diff 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 session.

40 min

Goal

Produce an AGENTS.md / CLAUDE.md for a real repo, derived from what is actually in it, and prove a fresh session can work from it alone.

Why

Every session starts with amnesia. Anything you find yourself repeating — the stack, the commands, the things it must never touch — belongs in a file the tool reads automatically. This is the highest-leverage forty minutes in the whole circuit.

Do this

  1. Pick a repo you will work in more than once. Open it with your agent of choice.
  2. Run the Write the Rules File prompt. It should cite a source file for every rule it writes.
  3. Read the result. Delete anything aspirational. Delete anything you cannot verify is true today.
  4. Commit it at the repo root under the name your tool reads (the docs for Claude Code, Codex and Cursor each say which).
  5. Start a brand-new session with no other instructions. Ask it to run the tests.

The check

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

Uses

03of 6

Red before green

A test that never failed never proved anything.

45 min

Goal

Ship one feature where the failing test existed, and was seen to fail, before the implementation did.

Why

“It runs” is the demo cliff: it works on the happy path in front of you and nowhere else. A test written after the code passes by construction. A test written before the code is a specification the model has to meet, and its first red run is the only proof it tests anything at all.

Do this

  1. Choose a feature small enough to describe in one sentence. Smaller than you think.
  2. Run the Red Before Green prompt. Stop at step one: the test, the command, the raw failing output.
  3. Read the failure message. It must 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 implement. The test may not be edited.
  5. Run the test yourself, in your own terminal, not in the agent's transcript.

The check

You have a screenshot or a saved log of the same test red, then green, and you ran the green one yourself. Keep both in the pull request.

Uses

04of 6

Know your building

Every bug lives on a floor. Learn the floors.

30 min

Goal

Map your own app onto the ten layers of the stack, and locate your last three bugs on that map.

Why

Most confusion in vibe coding is not about code. It is about not knowing where you are. A “the button does nothing” bug can live in the frontend, the API route, the auth check, or the database policy, and the fix is different on every floor. Once you can name the floor, you can ask a precise question.

Do this

  1. Walk the whole of The Stack page, top to bottom. Read every panel.
  2. On paper, list your app's ten layers. 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. Put each one on a floor.
  4. For each, write the question you should have asked, naming the floor. “Why does the API route for /orders return rows the user does not own?” beats “why is the orders page wrong?”

The check

All three bugs are on a floor, and at least one of them is on a different floor than you first assumed. If all three landed exactly where you guessed, 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 ship-blockers in the Vibe Check on a real project: no secrets in history, a test proving isolation, and an owner check on every route.

Why

Generated apps almost always build the membership desk (login) and forget the badge (authorization). They also commit keys, because the key was in the prompt. These are not exotic failures; they are the default. The Vibe Check treats them as blockers because a 92% with a leaked key is not a 92%.

Do this

  1. Search the repo and its git history for anything key-shaped. Anything you find has been leaked: rotate it first, then remove it.
  2. List every route or endpoint. Next to each, write the owner check it performs. A blank is an open door.
  3. Run the Security Boundary prompt for the most sensitive table. Get the failing isolation test first, then the policy that makes it pass.
  4. Run Dependency Interrogation on the manifest. Uninstall anything UNVERIFIED before reading further.
  5. Take the Vibe Check. Answer the three blockers honestly.

The check

All three Vibe Check blockers are a yes, and you can point to the artifact behind each one: the scan output, the isolation test, the route table.

Uses

06of 6

Ship with a receipt

Implemented is not evidence.

20 min

Goal

End a session with a Build Receipt and a Cold Handoff, and use them — not your memory — to start the next one.

Why

The last message of a session is the one you will rely on tomorrow and the one you are least likely to read carefully. A receipt separates what was verified from what was merely claimed. A handoff stops the next session from redoing, or undoing, what this one did.

Do this

  1. At the end of a real working session, run Build Receipt. Read the NOT verified section first. If it is empty, push back — nothing is fully verified.
  2. Run Cold Handoff. Read it as if you were the next agent: is the first action unambiguous?
  3. Save both files at the repo root. Commit them with the work.
  4. Tomorrow, open a new session and paste only the handoff. Do not explain anything else.
  5. Compare what it does first with what the handoff said to do first.

The check

The next session's first action matched the handoff, and nothing from the receipt's Changed list was redone. Two sessions, one thread of work, no memory required.

Uses

After the circuit

Go around again on the next project. The lessons do not change; the codebase does, and so does what you notice. When the checks stop teaching you anything, you are not vibe coding any more — you are engineering with a very fast pair.

Keep the Lexicon open for words you meet on the way, the Prompt Deck for the prompts each lesson uses, and run the Vibe Check before anything ships.