Bicycle.LLC

← The work

DevPlane

DevPlane is a control panel for solo founders and small teams running AI coding agents.

The conductor cockpit, live — Guide, Vision, capture inbox, agent bench, and the dispatch board, operating on a real repo (August 2026).

I built DevPlane as a control panel for solo founders and small teams running AI coding agents, starting with the agents I use across my own projects. The need was ordinary and persistent: an agent would say it had pushed code, passed a check or changed a page, while the repository or site showed something else. I still had to find the gap, send the work back and keep several projects straight.

I also kept finding that useful work disappeared inside individual repositories. A capability could already exist, but the next project had no reliable way to find it before rebuilding it. I did not want a cheerful paragraph from a tool that could not see the whole trail to become the record. DevPlane separates the report from the evidence and makes declared capabilities searchable across projects.

I am building it so small teams can spend less time policing completion reports and more time deciding what is worth building. I am also developing it as the instrument for a field study of whether human vigilance falls as agent reliability rises. The study is designed to compare agent reports with independent outcomes instead of treating those reports as truth.

Who it is for

DevPlane is a control panel for solo founders and small technical teams using Cursor, Claude Code, Codex, Replit or custom agents on real codebases. It is for people who need to assign work, set limits on each run, follow handoffs across projects and check whether reported work reached the codebase and live site.

The problem

AI coding agents can give a confident close-out while the repository, deployment and page show something else. You then have to open several tools, compare commits, rerun checks, read build logs and work out what really changed. Across several projects, you also have to remember where the same capability was already built. Until that checking is done, unfinished work can sit in the completed column and another agent can spend time rebuilding an answer that already exists.

What I built

DevPlane is the control panel I use to run AI coding agents across my projects, with the aim of letting a small team delegate more work without giving up control of cost or completion. It assigns and tracks work, including handoffs between repositories, and gives each run explicit spend and memory limits. When an agent reports completion, DevPlane checks the claim against the pushed code, the deployment and the live page. Failed evidence leaves the work open. Before new work begins, it searches 856 declared capabilities across 30 repositories so an existing capability can be reused. For a cross-repository handoff, confirmation can run a supplied evidence command, reject a non-zero result, store the result as a receipt and rerun the command later.

What is new in it

  • When DevPlane checks a completion report, it tests the claim against three sources outside the agent's summary: what was pushed, what deployed and what appears on the live page.
  • Each run starts with explicit spend and memory limits, giving a founder or small team a defined boundary before an agent begins work.
  • Meaning-based search covers 856 declared capabilities across 30 repositories, helping teams find reusable work even when project names and filenames do not reveal the match.
  • For cross-repository handoffs, confirmation runs the supplied evidence command, rejects a non-zero result, stores the result as a receipt and can rerun the command later.

Where it stands

DevPlane is being built so a small team can give agents more coding work without losing control of cost, reuse or what actually reached production. Today it is private, in daily use and runs only on my machine. I use its completion checks, capped runs, handoff tracking and cross-repository search across my own projects.

More screens

How it works

Cockpit flow — dp CLI to multi-tool kanban to assignment registry to agent claim to completion block.

Cockpit flow — dp CLI to multi-tool kanban to assignment registry to agent claim to completion block.

The operator points the `dp` CLI at a target project and the kanban surfaces every card in flight across every tool. The assignment registry is the source of truth — SQLite-backed, structured, cross-project visible. Agents claim cards through the registry: Cursor, Claude Code, Replit, custom agents — all coordinated through one board. The cockpit is the first of DevPlane's two bets, and it collects the telemetry the cross-portfolio brain layer (series 04) turns into pattern recommendations.

Two-phase actor handoff and structured completion-block protocol.

Two-phase actor handoff and structured completion-block protocol.

Builder emits the build artifact; the second transition requires a reviewer-only artifact the builder cannot produce; reviewer runs the pass and emits the review artifact; the card closes with a structured machine-readable completion block carrying decision, evidence, references, and follow-ups. Two rules — the reviewer-only artifact gating the handoff, and structured completion replacing free-text close-out — are the difference between a kanban that is a board and a kanban that is a research instrument. Both are contracts, not conventions.

Coordination-event log + C1 risk-compensation field-study apparatus.

Coordination-event log + C1 risk-compensation field-study apparatus.

Every state transition in the cockpit emits an event into a SQLite-backed coordination-event log. That log is not just an audit trail; it is the apparatus for C1 — a pre-registered field study testing Bainbridge 1983's Ironies of Automation against agent-mediated coding work. Hypotheses, analysis plan, and falsification criteria are specified before data accumulates. The bet underneath is that AI coding tools' productivity claims rest on agent-side measurements that systematically miss what an operator running multiple agents has to do; the cockpit collects the operator-side data, and the study tests the claim. Either way, more honest than what the field has today.

Cross-portfolio brain — pattern library, MCP tools, Brief Protocol, coordination-pill extraction.

Cross-portfolio brain — pattern library, MCP tools, Brief Protocol, coordination-pill extraction.

Seven documentation surfaces — pattern library, architecture maps, session handoffs, cross-project assignment registry, API registry, decision log, capabilities catalog — are legible across every repo in the portfolio. Propagation works two ways: operators reach the patterns through the `dp patterns` CLI, agents reach them through `devplane_patterns_search` and `devplane_patterns_get` MCP tools, and MASTER-PATTERNS.md is the actively-reconciled canonical surface. The Portfolio Brief Protocol syncs sister-repo briefs into the hub; the coordination-pill extraction carves a no-outside-imports `src/coordination/` boundary toward `@devplane/coordination-core` v0.1.0, with PA Toolbox planned as the first external consumer. The shared-brain bet pays for itself the first time a new product stands on the last one's shoulders instead of rebuilding from scratch.