Pulley alpha

The discipline that made software reliable, applied to code an AI wrote.

Hand off the ticket.
Get back a verdict.

Merged — or the branch and the reason it couldn't be. A fleet of agents clones your repo, works your ticket, and runs it through your test suite. Whatever the suite says comes back to you, in full.

We're onboarding a few teams at a time. Rails and Node are the stacks the workers run today — we ask because we only let you in when we can actually gate your suite.

146 of the last 152 came back green first time. We tell you which, and why.

Pulley builds for

The hand-off

Pass it to Pulley …

A pass isn't a retreat. It's what you make when someone else is better placed to run with it.

The machine

It isn't a reviewer. It isn't CI. It's a circuit.

A review bot has an opinion about your diff. CI has a verdict on it. Neither of them can do anything about it — they hand the problem back to you. Pulley wires the verdict into the work: the gate decides, the diagnosis reads the failure, the retry runs on the branch that already has the work on it, and green code lands on a trunk the next agent builds from. No human at any junction — right up until it runs out of ideas, and hands you the whole thing back where you started.

green red self-heal escalate your call your Claude Code ticket generate GATE pull request diagnose

Only the dotted path waits for a person.

CI can't diagnose.It tells you it's red and goes home.
A review bot can't fix.It leaves a comment and waits for you.
An agent can't refuse itself.So we gave it something that can.

The verdict

The tests decide. Not the model.

Every coding agent will tell you it's done. Pulley doesn't take its word for it — and it can't be talked around. Three mechanisms make an agent's confidence irrelevant.

Baseline delta

You can't pass by deleting tests

The suite is recorded before the agent touches anything, then compared after. Removing a failing test doesn't read as a fix — and you're never blamed for a test that was already red when the ticket started.

baseline: suite recorded green after: green · delta not negative
Artifact gate

No diff, no delivery

An agent that writes a test and calls it a day gets rejected. The ticket must produce real changed lines in real source files, or it never reaches review — the single most common way autonomous coding quietly fakes success.

changed files: none → rejected: no implementation
Green overrides

A hedging reviewer can't block a green build

When the suite passes and real work exists, Pulley ships it — even if the reviewing model got cold feet. And no amount of eloquence gets a red build through. The suite is the only vote that counts.

review: "I'm not certain…" gate: green → shipped

The trap

You built something incredible. Now you're stuck inside it.

It works. People use it. And you have no idea which parts you can safely touch — so every change is a coin flip, and eventually you stop making them. The thing you built starts closing in around you.

That isn't a skill problem. It's a missing gate. So Pulley builds you one before it touches anything. Card zero writes a characterisation suite that pins what your code does today — bugs and all. That's not a flaw in the method, it's the definition of it: you cannot safely change behaviour you haven't first pinned down.

And we don't trust that suite either. A generated test that can never fail is worse than no test at all — it launders bad work as verified. So card zero has to prove its own tests can fail: we mutate your source code, and if the suite doesn't catch the mutants, it isn't a gate and it doesn't ship.

Coming soon

How it works

One rope, four turns.

Connect the repo

Point Pulley at GitHub and pick a repo. It detects your test command, framework, and timeout — and refuses to run until that gate is confirmed. A project with no working test command can't start, by design.

detected: npm run test:run · vitest · gate confirmed

Write a ticket, not a prompt

Describe the change in plain language on a kanban card. Pulley turns it into a scoped, testable ticket — or takes an epic and decomposes it into an ordered series where each card waits for the last one's PR to merge.

"rate-limit the auth endpoint" → one scoped ticket · Small

The fleet works it

Approve the card and a disposable VM clones your repo, works the ticket through a ten-phase loop, and reports each phase live to the board. Up to twelve tickets run at once. You're not watching any of them.

planning → implementing → review · many workers, isolated per project

A pull request with a green suite

You get a PR on a branch you control, with the diff, the commit, the logs, the test delta, and what it cost — to the cent. If it fails, Pulley diagnoses and retries it on its own, and only escalates to you with a summary of everything it already tried.

PR opened · suite green · cost to the cent · ready for review

Throughput

Serial isn't a model limit. It's an attention limit.

An agent in a terminal isn't slow because the model is slow. It's slow because it needs you — one session, one thread of your attention, one ticket at a time, and you sitting there to say yes. The gate is what takes you out of that loop. And the moment you stop being the bottleneck, the ceiling lifts.

One session

you, watching

Wall clock is the sum of every ticket — plus every minute you spent reading a diff before it could move on.

The fleet

nobody, watching

Wall clock is the slowest single ticket. Twelve run at once, on twelve disposable machines, and none of them need a human to proceed.

Twelve agents hand you twelve conflicting branches.

That's the actual problem, and it's why parallel coding agents usually aren't worth it. So the lanes don't run in isolation. Every card forks from one shared trunk — the line actually under load — and green work comes back over a sheave and joins it, so the next worker builds on what landed instead of guessing. A worker whose branch has gone stale rebases and re-runs the gate before it's allowed anywhere near it.

auth t01 t02 t03 t04 billing wip/t22 conflict tdd/integration — the load line

One lane didn't land. It is still there, still yours, and flagged — never silently resolved. And main is never auto-merged: you promote the trunk, on your cadence.

Scale of work

Hand it the whole epic.

You don't have to slice the work yourself. Describe the outcome and Pulley breaks it into an ordered series of tickets, works out what depends on what, and holds each card until the one before it has a merged pull request — not a hopeful one.

Independent cards run side by side. Dependent ones wait their turn. Green work merges to an integration trunk so the next worker builds on it instead of guessing — and main is never touched until you promote it yourself.

Unattended

It ships while you sleep.

Nothing about Pulley needs you online. Approve the work before bed; the fleet runs the tickets, retries its own failures, and unblocks the dependent cards as each one lands. You review pull requests over coffee.

Where you drive it

Meet it where you already work.

The board is the front door. But if you live in a terminal, you never have to open it.

The board

A kanban card per ticket, with live per-phase progress, the diff, the test delta, the logs, and what it cost. Non-engineers can file work here without ever seeing a prompt. 

implementing ▸ review ▸ delivered

Claude Code

A skill and an MCP server, so your own agent talks to the fleet. Hand it a messy idea; it decomposes the epic, files the tickets in order, and reports back when the PRs land — from the terminal you already have open. 

> break this RFC into tickets and queue it
  → epic created · tickets ordered

The CLI

Coming soon

Scriptable, CI-friendly, and quiet. File a ticket from a git hook, block a release on a delivery, or fan a backlog into the fleet from a shell script. 

$ pulley ticket "rate-limit /api/auth"
$ pulley watch --epic billing

Proof

Pulley leveraged itself.

This isn't a demo repo. The product you're reading about wrote itself, ticket by ticket, through its own gate — and the agent's pull requests are sitting in the git log with everyone else's.

220 tickets in this repo, delivered by Pulley itself
481 test files it has to stay green against
955 delivered across every project it runs
123 came back red at least once, all time — 6 of them in the last 152

Every number on this page is a receipt, not an adjective. The test counts come straight out of this repo — re-run the command yourself. The delivery count comes out of the control plane's own database. None of it is rounded, dressed up, or invented; where a figure couldn't be sourced, the claim came off the page instead. An autonomous system that fakes its numbers isn't succeeding — it's just not checking. Every figure here is recorded, with its source, in marketing/STATS.md.

Turn the handle.

Connect a repo with a test suite and put one real ticket through it. If the gate doesn't go green, you don't get a PR — and you don't pay for it.

We invite in small batches, oldest first. The trial is fourteen days, the whole fleet, no card.