why pipemason
Pipemason builds the software. You review the PR.
Most AI coding tools want a seat at your keyboard. Pipemason wants the keyboard. You give it a ticket; it gives you back a tested branch with atomic commits, a frozen spec, an audit trail, and an open PR. The pipeline runs unsupervised and shows its work.
The problem with chat-in-IDE
Cursor, Copilot, and chat-in-editor tools accelerate individual keystrokes. They're very good at this. But they leave a different problem unsolved:
- The diff is unreviewable. AI-generated PRs touch fifty files because the model can't decide what not to change. The reviewer either rubber-stamps or re-reads the whole codebase.
- The spec is implicit. When the AI made a choice, why? Three months later you need to know, and the prompt is gone.
- You're still the bottleneck. Every cycle still goes through you sitting at the keyboard. You accelerated the typing; you didn't actually delegate.
What pipemason does instead
Pipemason runs a multi-phase pipeline on your behalf: analyze → plan → contracts → test-red → impl → review → verify → ship. Each phase has a frozen input artifact and a gate that decides whether to advance. The output is a reviewable PR plus a directory of frozen artifacts — .pipeline/ — that explains every decision the pipeline made.
.pipeline/ ├── spec.md # frozen interpretation of your ticket ├── test-plan.md # every acceptance criterion → test row ├── contracts/ # cross-domain types the change touches ├── decisions.md # ADRs the agents wrote └── iterations.log # append-only audit trail
Three months from now when someone asks "why did we ship it this way?" the answer is in git.
Pipemason vs other AI coding tools
| What you want | Cursor / Copilot | Devin | Workspace | pipemason |
|---|---|---|---|---|
| Ship without you in the loop | no | yes | one PR | yes — single feature or whole system |
| Frozen, auditable spec | no | no | no | yes — committed to .pipeline/ |
| Multi-PR coordinated programs | no | no | no | yes — programs with story DAG |
| Reviewable atomic commits | depends | no | sometimes | yes — one phase per commit |
| Brownfield migrations with rollback gates | no | no | no | yes — brownfield-upgrade mode |
| Tests written before code (real TDD) | no | no | no | yes — red-test phase is gated |
| Your Anthropic key, never ours | n/a | no | no | yes — BYO Anthropic |
| Cross-domain (API + web + mobile + db) | partial | partial | no | yes — domain-specific agents |
Note
What an actual day looks like
Monday morning, you open a ticket: "ABC-1234 — add SSO via Okta to /sign-in." You type:
pipemason start "ABC-1234 add SSO via Okta to /sign-in"
The runner pairs with your account, freezes a spec, plans the change, writes the failing tests, implements them, self-reviews, and opens a PR. You watch the dashboard. When it finishes you spend ten minutes reviewing a clean diff with a frozen spec the agent wrote on its way through — and you ship.
If something escalated (the spec was ambiguous; a contract mismatch couldn't resolve), the run pauses, the dashboard shows you exactly what went wrong, you edit the upstream artifact, and resume. The pipeline picks up where it stopped.
What pipemason isn't
- Not magic. Garbage spec in, garbage code out. A sharp 4-sentence intent ships dramatically better than a vague paragraph.
- Not free. You pay your Anthropic bill for tokens, plus a per-seat platform fee. Most runs are well under a dollar; complex multi-story programs can reach $20–50. See the pricing page.
- Not for every codebase. Pipemason thrives in repos with tests, types, and clear domain boundaries. Legacy monoliths without test coverage are harder; expect to invest in test scaffolding first.
Get started
14-day free trial. No card needed. Install in 60 seconds:
brew install crashbytes/tap/pipemason pipemason login