⟳
Intent caching
The same intent resolves to the same artifact. bd hashes your source and pins the plan, so builds are reproducible across machines and CI.
intent-first toolchain · now in public beta
Write what you mean.
Compile what you meant.
bd is a compiler for vibe coders. You describe the thing you want in plain
English inside a .bd file, run bd compile, and out comes a real,
working artifact — an HTML page, a Python script, a SQL migration, whatever you asked for.
No boilerplate, no scaffolding, no Stack Overflow tab open at 2am.
- HTML
- Python
- TypeScript
- SQL
- Bash
- Go
- Dockerfile
- React
- YAML
- Rust
The whole language
Three steps. That's the entire manual.
There is no syntax to learn, because the syntax is English. bd handles the rest of the toolchain — parsing intent, planning the build, generating the artifact, and verifying it does what you said.
01
Write a .bd file
Describe the outcome you want, logically, in plain language. One file, one intent.
# health.bd This file should be an HTML page that takes my weight, height and body fat, and tells me my BMR. Use the Mifflin-St Jeor equation. Keep it clean, mobile-friendly, no external dependencies.
02
Run bd compile
The compiler resolves your intent, plans the build, and emits the artifact next to your source.
$ bd compile health.bd resolving intent ......... ok planning build ........... ok generating artifact ...... ok verifying output ......... ok ✓ compiled health.bd → health.html (412ms)
03
Ship the artifact
You get a real file. Open it, deploy it, commit it. bd is a build step, not a runtime.
$ ls health.bd health.html $ open health.html # a working BMR calculator. done.
Playground
Compile something. Right now.
Pick an intent file, hit compile, and watch bd turn it into a working artifact. The HTML examples render live in the preview pane — yes, that calculator actually works.
health.bd
output
idle
Hit bd compile to generate the artifact.
Why it feels like a compiler, not a chatbot
Serious toolchain. Ridiculous ergonomics.
⌖
Target inference
You don't declare a language. The compiler infers the output target from your intent — or you pin it with --target python when you care.
✓
Output verification
Every build runs a verification pass: HTML is validated, scripts are dry-run, SQL is parsed. If the artifact doesn't satisfy the intent, the build fails loud.
◔
Watch mode
bd watch recompiles on save. Edit the sentence, see the artifact change. The fastest feedback loop you've ever had on a feature spec.
⚙
Pins & lockfiles
A bd.lock records the resolved plan and model revision for every artifact, so a green build today is a green build next year.
⌥
Composable intents
Reference one .bd file from another with @import. Build a layout once, reuse it across pages. Intent, but DRY.
Install
One line. Then you're compiling.
The bd toolchain is a single static binary. No runtime, no node_modules, no JVM. It just needs a network connection at compile time.
$ curl -fsSL https://bd.stackramp.io/install.sh | sh
or
brew install bd
winget install bd
cargo install bd-cli
30-second quickstart
$ echo "a CLI that tells me a dad joke" > joke.bd $ bd compile joke.bd --target python ✓ compiled joke.bd → joke.py (388ms) $ python joke.py Why do programmers prefer dark mode? Because light attracts bugs.
The bd thesis
Code is a means. The outcome is the thing.
For seventy years we have written down instructions for the machine and called it programming. But you never wanted the instructions. You wanted the BMR calculator, the scraper, the invoice, the little tool that does the thing.
bd treats your intent as the source of truth and the code as a build artifact — the same way a C compiler treats your .c file as source and the binary as the thing it produces. You don't read the assembly. Soon you won't read the JavaScript either.
It is, genuinely, a compiler. It just happens to accept English.
Docs & FAQ
The questions everyone asks first.
Is the output deterministic?
Within a pinned plan, yes. bd writes the resolved plan and model revision to bd.lock; recompiling against the same lockfile reproduces the same artifact. Change the intent and the plan re-resolves.
What actually happens under the hood?
The compiler parses your intent, builds a plan (target, structure, constraints), generates the artifact with a frontier language model, and runs a verification pass against your stated intent. The model is an implementation detail of the backend — like the optimiser in any other compiler.
Can I pin the output language?
Yes. Target inference covers most cases, but bd compile x.bd --target go forces it. Unset means the compiler decides from your intent.
Does it work offline?
Compilation needs a network connection (that's where the heavy lifting happens). The produced artifact has zero bd runtime dependency — it's just a normal file.
Is this a joke?
It is a very serious joke. Or a very funny compiler. We genuinely haven't decided. Either way, the playground above really does compile that calculator.