Shipyard

Shipyard is a control plane and CLI for running software development with agents as first-class developers. Humans plan and steer durable work through a web UI or the CLI; API-only runners lease work items, drive coding harnesses, and return verifiable execution evidence. It is the system behind the Building Shipyard series and the planning/build loops that produced projects like PickedPlate.

The shape of it

1
Humans (web/CLI) ──> control-plane server ──> durable state + immutable evidence
2
                           ▲   │
3
                           │   └─> lifecycle workers, live SSE updates,
4
                           │       analytics pipeline
5
                           │
6
Runner daemons ────────────┘
7
  ├─ lease work, own the checkout/branch, capture everything
8
  └─ drive Claude Code, Grok Build, or Codex through harness adapters

• Tasks, agents, and runners are all plural and all configurable. Work is decomposed into work items (WIs). Runners are plain HTTP clients, so adding capacity means starting another daemon on another machine; harness vendors are adapters selected per model alias, not forks of the system.
• The server owns truth. Durable state, authorization, dispatch policy, and read models live in one place. Runs and evidence are immutable: a completed record is never rewritten, and late results create successor work instead of editing history.

The northstar workflow

The loop Shipyard is built around, end to end:

1. Collaborative shaping first. Brainstorming, spec writing, and mocks happen with a human in the loop through the UI, the same way you’d shape work with a colleague.
2. A high-capability model plans the implementation. A frontier-tier model (Fable/Sol class) turns the approved spec into a plan of discrete work items with clear acceptance criteria.
3. Runners execute the WIs. Each work item runs on whatever agent/harness fits it, on whatever machine has capacity, producing branches, builds, tests, and captured transcripts.
4. Humans gate what matters. When confidence is low, or a step is explicitly marked for review, work stops at an approval gate in the web UI. High-confidence mechanical work flows through.

Everything is measured

Every execution captures its full trajectory: tokens, cost, spans, and tool calls are recorded natively and correlated per work item, per session, and per agent. Because time is captured as spans, you can decompose where a feature’s wall-clock actually went (agent thinking time vs. verification vs. builds vs. landing) and optimize the process, not just the prompt. The analytics pipeline settles immutable facts in the background; dashboards and ledgers are bounded reads that never trigger work.

A few design commitments that fell out of running it for real:

• Reads are side-effect free; GET routes never start jobs.
• Model output is visibly distinct from deterministic facts and can never overwrite them.
• Unknown is reported as unknown; metrics never coerce missing data to zero.
• Cancellation is terminal; restoring cancelled work admits a new, bounded successor.

Status

Shipyard runs daily as the development loop for my own projects, with a production pilot completed and the authenticated Run/Record/Ledger UI as the default read surface. It is a working system and a laboratory: the Shipyard blog series covers what running agent-first development actually teaches you. Its device-delivery sibling is Shipyard Deploy.