The most advanced coding harness ever made. We're not humble. We tried it once and it failed QA.

Claude says it's done. VBW makes it prove it.

Describe it like you'd explain it to a toddler. VBW will build it like a team of PhDs.

This page comes in two versions. Pick yours:

Tell it what you want in plain words. A team of AI agents plans it, builds it and checks each other's work. Then a strict program with no AI in it tests every piece before anyone is allowed to tell you it's done. You never have to read a line of code. Spec → failing acceptance checks → SHA-256-sealed contract → file-disjoint parallel build → proof on a clean copy of HEAD → goal-backward QA. The model proposes; a bash + jq + git kernel disposes. Done means exit 0.

Watch it build somethingSee a full run Star on GitHub

/plugin marketplace add swt-labs/vibe-better-with-claude-code-vbw

Step 1 of 2. You paste it inside Claude Code, Anthropic's coding app.Step 1 of 2, inside a Claude Code session. · full install · press 0

trusts: nobody 0 opinions

fig. 0 — the boss · 0 glyphs

Abraham Lincoln, VBW's mascot, watching from Mission Control. He trusted people without verification. We all know how that ended.

Who checksKernel

a program, not an AIbash · jq · git

Your sign-offContract

locked with a fingerprintSHA-256 sealed

Tests run onProof

a fresh copy of your projectclean copy of HEAD

Team

7 specialist AI agents7 roles, file-disjoint waves

PriceLicence

free, open sourceMIT

§ 01Stock vs VBWthe whole difference, on one pagethe model proposes, the kernel disposes

Claude Code on its own, or with VBW. The model proposes. The kernel disposes.

Claude Code is excellent. VBW doesn't replace it; it gives it a structure, a rulebook and a referee. Here's every difference that matters. VBW doesn't change the model. It changes who holds state, who runs the process and who decides what counts. Every row below is enforced by code, not by instructions.

Claude Code on its own

Claude Code + VBW

Who decides it's doneDefinition of done

The AI, about its own workModel-asserted

A program that runs your approved testsExit 0 of approved argv on a clean HEAD copy

When tests are writtenTest timing

Usually after the code, if at allPost-hoc, if prompted

Before the code, and proven to fail firstFrom the spec, verified red before implementation

Can tests be changed to pass?Test integrity

Yes. Nothing stops itMutable by the agent under test

No. Locked when you approveSHA-256 contract; hooks deny writes

Who approves the planApproval

There's no formal plan to approveNone

Only you. The AI is blocked from itHash-bound consent in .git; answer-hook only

Where the plan livesState

In the chat, until it's summarised awayContext window, until compaction

In a file in your project.vbw/record.json: one writer, locked, atomic

Who runs the processOrchestration

The AI, making it up as it goesThe model, improvising

A fixed, predictable scriptDeterministic JavaScript workflows

Working in parallelConcurrency

Helpers can trip over each otherAd-hoc; overlapping writes possible

A team, each in its own filesFile-disjoint waves; out-of-plan writes denied

Dangerous commandsDestructive ops

Up to your permission settingsPermission rules only

Also blocked by VBW before they runGuards parse what the shell would run; fail closed

Old features breakingRegression

Can happen silentlyNo standing suite

Every past test re-runs on every changeCumulative suite; read-set reuse

Knowing what's going onObservability

Read the chatTranscript

Mission Control, in plain EnglishStatus line + panel from record and run files

No per-agent worktrees, on purpose.

A worktree has no node_modules or virtualenv, so an agent either reinstalls everything or proves the main checkout's code instead of its own. A false proof is the one failure VBW refuses to have.

Guards read the real command.

git commit -m "never rm -rf /" passes. sh -c 'rm -rf .' doesn't. A guard that crashes during a run blocks the action instead of letting it through.

Fine print

VBW adds safety rails; it isn't a security system. Claude Code's own permission settings stay in charge of what's allowed on your computer.Guards are guard rails, not a sandbox: Claude Code's permissions and sandbox remain the security boundary. --dangerously-skip-permissions is called that for a reason. It isn't called --everything-will-be-fine.

On its own, Claude is a brilliant engineer nobody checks. Senior engineers have run that experiment for twenty years. The results are called “production”. On its own, Claude is a genius with commit access and no supervisor. A vibe coder has two of those three.

§ 02The liestock claude code vs vbwself-reported completion

“All done! ✅”

The most expensive sentence in software.The most expensive token sequence a model emits.

AI is brilliant at writing code. But on its own, the AI that wrote the code is also the one that decides whether it works. It grades its own exam. So it always passes. On stock Claude Code, completion is asserted by the same agent that produced the change, in the same context, against criteria it inferred. Nothing external has to agree.

✗ Stock Claude Code · the AI checks itselfself-assessed

It wasn't lying.Not a lie: an unverified claim. It just never checked, and nothing made it check.No acceptance criteria, no external oracle, no gate.

✓ Claude Code + VBW · something else checkskernel-verified

Same AI. Different supervisor. The mistake was caught, fixed and checked again before anyone said “done”.C5 failed on a clean HEAD, a fix round ran, the reproof passed. Done is an exit code.

Senior engineers have a word for untested code that works by luck: “legacy”. They even have a word for the person who wrote it: “CTO”. Vibe coders have a word for code nobody tested: “shipped”. They don't have a word for the other kind. It hasn't come up.

§ 03The methodsix proven habits, done for youatdd · tdd · executable spec · regression

How VBW works, in plain English. Acceptance-test-driven development, with an executable definition of done.

Professional software teams rely on a few famous habits to make sure code really works. They're proven, they're effective, and they're so tedious that most people skip them. VBW does every one of them, every time, automatically. Here they are, without the jargon. VBW runs ATDD: the TDD cycle, red → green → refactor, one level up, with failing tests derived from the agreed requirements rather than the code. Every passing check is kept as a regression suite. Together: an executable definition of done, checked by a machine. Close relatives: BDD, Specification by Example.

01

You agree what “finished” meansHuman-approved spec

The answer key comes firstATDD · Specification by Example

Before anything is built, you and VBW write down, in plain words, what “done” looks like. Like writing the answer key before anyone sits the exam, so nobody can argue about the marks afterwards.Acceptance criteria are agreed before design. Each requirement is [auto] (machine-checkable) or [human] (judgement). Decisions are recorded with rationale in the record, not the chat.
02

Each test must fail firstLead plans with tests that fail today

Press the smoke-alarm test buttonTDD · red

Every test is run before the work exists, and it has to fail. Like pressing the test button on a smoke alarm: if it doesn't beep now, it won't save you later.Every [auto] requirement gets an acceptance check (argv, expected exit, optional output regex), executed and confirmed failing for the right reason. A check that can't fail proves nothing.
03

The team builds until every test passesDev builds until the checks pass

Finished means the tests say soTDD · green

The AI developers keep working until every test passes. Not until they feel finished. Until the tests say so.Implementation proceeds per plan in file-disjoint waves until the approved checks pass, red verified before the first change, one atomic commit per task with a VBW-Plan: trailer.
04

A machine gives the verdictKernel proves the checks mechanically

The breathalyser ruleExecutable specification

“Done” isn't a feeling. A program with no AI in it runs every test and gives a plain yes or no. Like a breathalyser: it doesn't care how sober you feel.The kernel executes every approved check and project command on a clean copy of HEAD, verifies per-commit scope, and writes evidence atomically. The spec is machine-verified, never model-asserted.
05

Old tests are re-run, foreverChecks protected and re-run on later changes

The building inspector who never leavesRegression suite

Every test you've ever approved runs again whenever anything changes. Like a building inspector who re-checks every floor each time you add a new one.Approved checks are hash-protected during build and re-run in every later proof. A pass is reused only when the check's definition, last result and every file it read are unchanged.
06

You judge the human stuffHuman acceptance where checks can't judge

Taste can't be automatedManual acceptance testing

Some things a machine can't judge: does the page feel calm? Is the wording right? Those come to you, and only you can say yes.[human] requirements are verified by the user through /vbw:verify; a rejection needs a note and becomes a fix item. QA reports, never edits.

Stock Claude CodeSkips most of these habits unless you ask, and nothing checks that it really did them.Practices are prompt-level suggestions; adherence is unverified and decays with context.

Claude Code + VBWDoes all six, every time, and a program makes sure of it.Practices are enforced by the kernel, hooks and deterministic workflows.

Senior engineers invented test-driven development. Then they invented “we'll add tests later”, which is the only thing they've ever maintained. Vibe coders test too. They click the button once. If it works, that's a pass. If it doesn't, that's a feature request.

§ 04The kernelfig. 4 — signal from noise

Probabilistic in.
Deterministic out.

AI is creative, fast and sometimes wrong, like people. VBW doesn't pretend otherwise. Everything the AI team makes goes through the kernel: a small, plain program with no AI in it. It can't be talked round, it doesn't get tired, and it gives the same answer every time. Pass or fail. Nothing in between. Models are stochastic; the verdict shouldn't be. Every requirement reduces to an argv check with an expected exit code, executed by the kernel. No LLM judges a result, no prompt can reinterpret one, and a long session can't drift the record, because the record isn't in the context window.

Stock Claude CodeThe AI decides if its own work passed.Verdicts are LLM output: non-deterministic, context-dependent.

Claude Code + VBWA plain program decides. Same answer, every time.Verdicts are exit codes from approved argv. Reproducible.

in · what the AI madeagent outputkernel · no AI insidebash+jq+gitout · pass / fail

Same verdictSame work, same answer. Every time.Deterministic: exit codes, not opinions.

No interpretationRuns exactly the tests you approved.Argv only. No shell, no eval.

No driftThe plan lives in a file, not in the chat.State in .vbw/record.json; one writer.

The kernel gives the same answer every time. Ask a senior engineer the same question twice and you get two answers, and a reason why it's your fault. The kernel doesn't guess, drift or improvise. It's the first thing in a vibe coder's stack that has read the code. Including the vibe coder.

§ 05Watch it workWalkthroughone project, start to proof [..]

Watch a whole project, idea to proof.One milestone, end to end.

Your vegan girlfriend has a yoga studio. It doesn't exist yet. She's asked you to build its website, with a waitlist for the classes she'll run one day. You've never written code. Scroll down: the window on the left shows exactly what you'd see, step by step, and each step shows what Claude Code does without VBW. The brief: a booking site with a waitlist, for your vegan girlfriend's yoga studio, which currently exists as a feeling. Interview → spec → red checks → sealed contract → parallel build → proof → QA. Scroll: the session follows. Every surface is VBW's real output format, and each step lists the stock-Claude-Code baseline.

step 01 / 06 · Agree

01 · Agree

It asks before it builds.Spec first: requirements, decisions, rationale.

You describe your idea in one sentence. The Architect asks three quick questions about you, so it talks at your level. Then it asks about the decisions that matter, one at a time, each with its recommendation. Everything is written down. Three-question interview (level, depth, involvement), then decisions one at a time via the native question box, each with a recommendation and recorded rationale. Requirements land in .vbw/spec.md tagged [auto] or [human].

StockStarts building straight away, guessing what you meant.Requirements implicit in a chat thread; acceptance criteria rarely written.

VBWAsks first and writes down what “done” means.Explicit spec, typed requirements, decision log.

It asks what you want before it builds. Senior engineers also ask. Then they build what they wanted, and bill you for the question. Vibe coders skip the requirements and call whatever comes out “the MVP”. The M stands for minimum. The other letters are aspirational.

02 · Plan · Red

First, it proves the tests can catch a mistake.Red: every acceptance check fails before implementation.

Before any of the app exists, the Lead writes a test for each thing you asked for, then runs it. It has to fail, because there's nothing built yet. That proves the test is real and not a rubber stamp. The Lead decomposes the phase into file-disjoint plans and writes one acceptance check per [auto] requirement. Each is executed and must fail today, for the right reason, before the contract can be offered.

StockWrites tests after the code, if at all. They tend to agree with the code.Post-hoc tests written against the implementation; can pass vacuously.

VBWWrites tests first and proves they fail.Checks derived from the spec, verified red before any change.

A test that passes before the code exists proves nothing. It's a senior engineer's code review: instant, confident, based on nothing. A test that passes before the code exists proves nothing. Vibe coders call that “green on the first try” and screenshot it.

03 · Approve

You approve it. Then it's locked.Approval binds to a SHA-256 contract.

The plan and every test are locked together with a digital fingerprint. You approve that. If anyone changes a single letter afterwards, your approval is cancelled and VBW asks you again. Only you can approve. The AI is blocked from doing it, however hard it tries. Spec, plans, checks and check-file bytes hash to one contract (SHA-256); the 12-hex prefix is what you approve. Consent lives in the clone's .git, reachable only via your answer hook. Check files are write-denied by hooks during build and fix.

StockCan change a test so it passes. Nothing stops it.The agent under test can edit its own tests; no change control.

VBWTests are locked. Trying to change them is refused.Hash-bound approval; hook-enforced write protection.

Only you can approve, and the approval is bound to the hash. Senior engineers approve with “LGTM”. It stands for “looks good to me”. It means “I didn't look”. A vibe coder's change control used to be typing “please don't touch the tests”. Claude said “Of course!” and touched the tests. Politely.

04 · Build · Green

The team builds, all at once.Green: file-disjoint parallel waves.

Several AI developers work at the same time, each on its own part and only in its own files, so nobody trips over anybody. You watch them in a strip above your typing box: who's working, on what, and for how long. One Dev per plan, waves as wide as file boundaries allow; guards deny writes outside a plan. One commit per task with a VBW-Plan: provenance trailer. The band renders each agent's live intent, elapsed time and context.

StockOne worker, one thing at a time. Long jobs lose the thread.Single agent or ad-hoc subagents with overlapping writes.

VBWA team in parallel, each in its own lane.Scheduled waves, scope-checked commits.

Several engineers working at once, with no meetings. A senior engineer just read that and booked a 45-minute meeting to push back. Recurring. File-disjoint waves mean no merge conflicts. Vibe coders resolve merge conflicts the traditional way: a new repo, a new name, and no mention of the old one.

05 · Prove

A program checks it. Not an AI.Proof: approved argv on a clean HEAD copy.

The kernel copies your project into a fresh, empty folder and runs every test there, so leftovers on your computer can't fake a pass. A test fails? The code gets fixed, never the test. After three failed fixes it stops and comes to you, with the evidence. Proof runs every approved check plus the project test command in a detached clean copy of HEAD, verifies each VBW-Plan commit stayed in its plan's files, and records evidence atomically. Fix rounds can't touch checks; three failed attempts escalate to you.

Stock“All done!” based on its own opinion.Completion is model-asserted, in the working tree it modified.

VBWDone when a program with no AI says every test passed.Completion = exit 0 on a clean HEAD + scope check.

The kernel has no ego, no opinion on tabs versus spaces, and has never said “well, actually”. We'd call it a senior engineer, but it's useful. “Works on my machine” is not a proof. For a vibe coder it's the deployment strategy, the test plan, and the only machine.

06 · Review

A strict reviewer checks it against your plan.Goal-backward QA. Deviations fail.

Passing tests isn't enough. A separate QA agent compares the finished work with the plan you approved. Anything added, missed or changed counts as a failure, even if it “seemed helpful”. Then you judge what only a human can: the look, the feel, the words. Independent QA per phase, reviewing goal-backward against plans and recorded decisions; any undeclared or declared deviation fails. QA changes nothing, never runs on Haiku, and risky phases (auth, payments, deletion) get deep rigor with an adversarial pass.

StockReviews its own work, generously.Self-review in the same context that wrote the code.

VBWA separate reviewer that isn't allowed to touch the code.Independent, read-only, plan-anchored review.

QA rejects anything you didn't ask for. Senior engineers reject anything they didn't write, rewrite it, then reject that too. They call it mentoring. QA fails any feature nobody asked for. In a vibe-coded app, that's called “the architecture”.

§ 06The sealfig. 6 — try it yourselfa real sha-256, computed in your browser

Change one letter. Watch the approval die.One byte in. Avalanche out.

This is the plan from the story, with its fingerprint. Try editing anything below, even a comma. The fingerprint changes completely, and VBW refuses to build until you approve again. Live SHA-256 (pure JS, no library) over the requirements plus the sealed plans, checks and a test-file digest. One flipped byte changes about half the output bits; the approval is bound to the old 12-hex prefix, so it's void.

Requirements

Approved fingerprint

computing…

Contract right now

computing…

Approved. Building is allowed.The contract matches the fingerprint you signed.

Stock Claude CodeThere's nothing to sign, so nothing to break.No contract object; scope and criteria can shift mid-task silently.

Claude Code + VBWYour sign-off covers exactly what you saw. Any change needs you again.Approval is bound to the hash; any drift un-approves.

You just understood cryptographic hashing in ten seconds. Senior engineers needed a four-year degree, and still explain it wrong at dinner. Loudly. Yes, real SHA-256, client-side, zero dependencies. A vibe coder just asked Claude what SHA-256 is, got “a Star Wars droid”, and moved on.

§ 07Mission Controllive replica · click the tabs

Always know what's happening. In plain English.Observability for the whole run. Read-only, zero network.

A panel beside your conversation says where things stand in plain sentences, with the technical word underneath so you learn the language as you go. One line turns yellow, with a short sound, when VBW needs you. A side pane plus a band above the prompt, fed from the record and Claude Code's own run files: Now, Plan, Proof, Timeline, Decisions, Team, Costs. Re-reads only on size/mtime change; under 0.5 ms CPU per refresh; never writes.

It tells you when it needs youOne needs-you signal

Otherwise: “Nothing is needed from you right now.” Go make coffee.Approval, verify, ship, stuck fix, question: one yellow line and a sound, once per request.

Buttons never act for youButtons fill, never send

They type the command in. You press Enter. Always.Every action pre-fills the prompt; nothing is submitted on your behalf.

Every test, one squareProof grid

Green passed, red failing. Click one to see what happened.One square per approved check, with its last output.

Lives in your projectSurvives sessions

Not in a chat window. Come back in a week and type /vbw:vibe.State is the record, not the transcript. Compaction-proof.

Stock Claude CodeScroll back through the chat to work out what's going on.Progress inferred from the transcript; lost on compaction.

Claude Code + VBWOne panel, plain sentences, a yellow line when it needs you.Live, structured state from the record and run files.

It tells you exactly what it needs, in plain English. A senior engineer tells you “it's complicated”, which is Senior for “I don't know either”. Mission Control says what's happening, in plain English, and turns yellow when it needs you. Before this, a vibe coder's monitoring system was their customers. Past tense.

§ 08Shippedfig. 8 — the safety netthe regression suite

Shipped. Checked. Checked again, forever.Shipped checks become your regression suite.

When a milestone ships, Mission Control opens on VBW Wrapped: what was proven, who worked on it, where the time went. Then every test you approved joins a permanent safety net. Build ten more features: if one of them breaks the waitlist, you'll know before your customers do. Shipped checks stay in every later proof. A check re-runs when its definition or any file it read changes and keeps its pass otherwise, so the suite grows with every requirement without growing your wait. vbw prove --full reruns everything.

Stock Claude CodeNew work can quietly break old work.No standing acceptance suite across sessions.

Claude Code + VBWEvery test ever approved runs again on every change.Cumulative regression; read-set reuse keeps it fast.

VBW Wrapped

M1 · Class bookings

✓ shipped

0/3

proven by tests

0/1

accepted by you

0

tests, kept forever

0

agents worked on it

0

fix rounds

0

decision, recorded

Fastest stepApprove · you, 4 s

Slowest stepBuild P1.2 · the page. Still ahead of the studio.

Old features don't break quietly anymore. That used to be a senior engineer's retirement plan. Every requirement re-proven on every change. Vibe coders used to do that by asking Claude “does it still work?” Claude said yes. Claude always says yes. That's why this website exists.

§ 09Built in the opengithub.com/swt-labs

Free. Open. Nothing hidden.MIT. Read the kernel.

VBW is free and open source: anyone can read exactly what it does, suggest an improvement or report a problem. No account, no subscription. It runs on your own Claude plan. The kernel is plain bash, jq and git you can read in a sitting, backed by a bats suite. Agents, workflows, skills and hooks are plain files under plugin/. Issues and PRs welcome.

swt-labs / vibe-better-with-claude-code-vbw Public

Vibe Better With Claude Code. An engineering team for Claude Code, kept honest by a deterministic kernel.

★ — stars⑂ — forksShellMIT

Star the repo ★ Read the kernel bin/vbw Contribute PRs Join the Discord chat

# what VBW adds to your projectper-project state
your-project/.vbw/
  spec.md        what you want, in plain words. yoursrequirements, commands, test files
  record.json    the plan. only the kernel writes itplan of record · single writer
  map.md         a map of code you already hadbrownfield map

# what VBW is made ofthe plugin
plugin/
  bin/vbw        the rule-keeper (the kernel)kernel: next, check, prove, record
  lib/           kernel libraries · bash, jq, git
  workflows/     plan, build, fix, verify, map, research
  agents/        architect lead dev qa scout debugger docs
  skills/        /vbw:vibe and every other command
  hooks/         the safety guardsPreToolUse / PostToolUse guards
  scripts/       the status line

Inspired by Ralph and Get Shit Done. A new architecture.

Every line is public. Senior engineers will find something to complain about in the first ten. That's as far as they read. The kernel is bash. Vibe coders: bash is the black window your AI types into. You've been closing it.

§ 10Installtwo lines · about two minutes

Two lines to install. One command to use: `/vbw:vibe`

Open Claude Code in your project's folderStart a Claude Code session in the repo
Claude Code is Anthropic's coding app. Open it in the folder for your project. A brand-new idea or something you already have: both work.Greenfield or brownfield. Existing code gets mapped first.
Add the VBW marketplace

/plugin marketplace add swt-labs/vibe-better-with-claude-code-vbw
Install VBW

/plugin install vbw@vbw-marketplace

Paste each line on its own and press Enter before the next. Pasted together, they arrive as one command.
Restart Claude Code and describe your ideaRestart, then run the router

/vbw:vibe my vegan girlfriend's nonexistent yoga studio website she asked me to build

That's the only command you ever need to remember. If something's missing on your computer, VBW tells you what and how to fix it.Requires Claude Code 2.1.286+, git, jq; macOS, Linux or WSL. /vbw:doctor verifies the setup.

§ 10.1Questionsplain answersstraight answers

Do I need to know how to code?

No. VBW asks three questions about you and then talks at your level. You describe what you want, approve plans written in plain words, and judge the things only a person can, like how a page feels. A program does the checking, so you never have to read the code.

What is Claude Code?

Claude Code is Anthropic's app for building software by talking to Claude. VBW is a free add-on for it: it turns Claude into a team that plans, builds and proves its work.

Could it break my project?

VBW blocks the dangerous stuff (deleting files, rewriting history, reading your passwords) before it runs, and every change is saved separately so it can be undone. Claude Code's own permission settings stay in charge too.

Can I leave it running on its own?

Yes. The team keeps working, and VBW still stops for the things that are yours: decisions, approval, checking results by eye, and shipping. Mission Control shows a yellow line when it needs you.

What does it cost?

VBW is free. It runs on your own Claude plan. A team that checks its own work does more than a single chat, so it uses more of your plan; the status line shows what your session has cost, live. Small fixes automatically get a lighter process.

What if it gets stuck?

After three failed attempts at the same fix, VBW stops and brings it to you with what it tried and why it failed. It never quietly gives up, and it never quietly changes the test to make the problem disappear.

Will it build a website for a business that doesn't exist yet?

Yes. VBW proves the code works, not the business plan. Your waitlist will function perfectly and hold nobody. If the studio opens, the site is ready. If it doesn't, you've built the most thoroughly tested website in the relationship.

How is this different from a good CLAUDE.md?

CLAUDE.md is advice the model can drift from. VBW moves the rules into code: a kernel that owns state, hooks that deny writes to protected checks and out-of-plan files, a hash-bound approval the model can't forge, and deterministic workflows instead of improvised orchestration.

What exactly is in the contract hash?

Requirements (id, text, proof type, rules), checks (argv, expected exit, output regex, timeout), plans minus status, and the bytes of every check's declared files, rendered canonically and hashed with SHA-256. The approval question carries the first 12 hex chars.

Can the model bypass the guards?

The guards deny vbw approve however it's spelled, writes to the consent and run stores, and destructive shell commands parsed from what the shell would execute. They're guard rails, not a sandbox: a determined program can always write a script. Claude Code's permissions and sandbox remain the boundary.

Why no per-agent worktrees?

Worktrees lack installed dependencies, so an agent either reinstalls everything or proves the main checkout's code instead of its own. VBW gets isolation from file-disjoint waves plus write guards, and proves on a clean copy of HEAD.

Does it work with my stack and test runner?

Checks are argv plus an expected exit code, so any runner works (bats, pytest, npm test, cargo test, …). Declare a project test command and, optionally, a per-file form so proofs run only the affected tests. Brownfield repos get mapped first with /vbw:map.

Does VBW validate the business?

No. Checks prove behaviour, not demand. Every requirement for the waitlist will pass on a clean HEAD, and the waitlist will hold zero people. That's a product problem. QA doesn't do those, and neither, apparently, does she.

What does it cost in tokens?

More than a single agent doing the same task: planning, red checks, proof and QA are real work. Rigor is sized per phase (express for a typo, deep for auth), and per-run cost is recorded. We'll publish the 2.x benchmark when it ships, not before.

Two lines to install. If a senior engineer tells you it's harder than that, check the invoice. It's already on it. Two lines, one at a time. A vibe coder will paste both at once, ask Claude why it broke, and Claude will apologise for their mistake.

Proven, not claimed.

The AI will still tell you it's done. Now something checks.Done is an exit code. Everything else is a claim.

Install VBW free Star on GitHub

Curious what we told the engineers? Curious what we told the vibe coders?