Docs
Open Babbit

Get started

How Babbit works

One change, from the sentence you type to the release that ships it. You act twice: you approve the lines, and you confirm the release. Each section links to the page that covers its part in depth.

Who does what

You decide what the product should do and confirm that it shipped. Agents and Babbit do everything in between: the code, the tests, the pull requests, the merges and the deploy.

A bug that reaches your users comes from one of two places, and each has its own fix:

The bugWhere you fix it
The spec was wrong. What you approved isn't what you wanted.Edit the spec, on the Build side.
The code was wrong. The spec is right, but the code doesn't do it.Babbit catches it with tests and blames a box. If the agents keep making the same mistake, tune them on the Manage side.

Build and Manage

Babbit has two sides, and the change bar at the top of the screen works on both.

SideWhat it's forWhat a change edits
BuildWhat your product does.The product spec: features, goals and scenarios.
ManageHow Babbit builds it.Agent rules (agents.md), agent settings and skills.

When you switch to Manage, the change bar and accent turn clay, so you always know which side a sentence will change. A Manage change is reviewed and approved the same way as a product change. See Tune your agents.

The spec is the source of truth

Your product's spec is a tree of features. Each feature has at most three goals, and each goal holds scenarios. A scenario is one line: what someone does, and what they see.

Redeem 500 points → see a $5 credit on the next order.

The spec lives in Git, on the newdev/spec branch of the first repository you connected, and only changes through an approved change. Read more in Features, goals and scenarios.

A change, step by step

The five steps of a change Asked: you type a sentence and the Product agent drafts spec lines. Approved: you approve the lines. Built: the Code Writing agent writes the code and its tests. Verified: Babbit runs the tests and the Verify agent captures the app. Live: Babbit merges and releases. A failing test sends the change back to Code Writing. 1 · Asked2 · Approved3 · Built4 · Verified5 · Live Product agentdrafts spec linesfrom your words Youapprove the lines,not the code Code Writingwrites the codeand its tests Verifyruns the tests,captures the app Babbitmerges, thenreleases A failing test sends the change back to Code Writing, not to you.
The five steps of a change, as the change screen shows them.
  1. Asked. You type a sentence. The Product agent turns it into a brief and proposes exact edits to the spec.
  2. Approved. You approve or reject each proposed line.
  3. Built. The Code Writing agent writes the code and a test per scenario in an isolated workspace. Babbit opens one pull request per repository.
  4. Verified. Babbit runs each scenario's test at its pull request head, and the Verify agent captures the app before and after.
  5. Live. Babbit merges the spec, then the code, and moves one release through preprod to production.

You hear about a change again only when it needs a decision or when it's live. What each step checks, what sends a change back and how it ends are in Changes.

One door for agents

Every agent, Babbit's own or one you bring such as Claude Code or Codex, works through the Babbit MCP. It's the only way an agent can change the spec, run tests, record evidence or use a secret. Each call carries a token bound to one change, one workspace and one tier, and every call, allowed or refused, is logged.

The Babbit MCP is the only door Babbit's agents and outside agents such as Claude Code and Codex call the Babbit MCP. The MCP checks the call and then reads the spec, proposes lines, runs tests, records evidence or hands out a secret handle. Every call, allowed or refused, is logged. No agent writes to the spec, GitHub or production any other way. Agents Product · Code Writing Verify · QA Outside: Claude Code Babbit MCP checks the binding, follows one rule per tool, logs every call What it reaches The spec: read, propose lines Tests and evidence, at a commit Secret handles, never values
Agents never reach the spec, GitHub or production directly.

The other rules Babbit holds everywhere are listed in What Babbit doesn't do, and the mechanism behind each is in Security guarantees.

After the code lands

Babbit runs your product too. A release moves through three tiers, dev, preprod and prod, and reaches prod only after preprod has run it. See Tiers, releases and hosting.

Code can also change outside Babbit: a teammate pushes to main directly. Babbit reads every such push as drift, traces it to the scenarios it touches, re-runs them and brings the spec back in line. See Keeping spec and code in sync.

When something breaks, Babbit blames one box. See What's in the box?.