A One-Person Engineering Platform Run Through Spec-Driven Development

The Problem

A coding agent starts every session from zero. Without structure it re-reads the code, guesses at conventions, and produces work that is plausible but not necessarily correct, while the design decisions live in a chat that no longer exists. Spec-driven development answers the memory problem; running many products through agents as one person raises three more.

An orchestrator that fans out is useless without a backlog of real, independently verifiable work to fan out over. A green status is not evidence, because every stage of a pipeline can succeed while the pipeline as a whole eats itself. And prose lessons do not prevent repeats; only checks do.

The platform also had to be honest about its own output. Its flagship market signal turned out to measure nothing, and an apparent edge vanished net of costs. A platform that cannot say that about itself is not one worth describing.

The Approach

Orchestration shape first: a frontier-tier session supervises (decomposes, writes briefs, reviews diffs, holds merge and deploy), and cheaper executors, including off-quota coding agents on separate subscriptions, implement from those briefs in isolated worktrees. Changes land through pull requests. The brief names the files, the verify commands, what is out of scope, and when to stop and ask.

A real work queue of roughly 1,500 items, each stamped with acceptance criteria and a cost tier; a triage pass keeps enough worker-ready items stamped that an unattended loop can burn through them. Orchestration is only as good as its backlog.

A check the agent cannot talk past: local CI mirrors the hosted pipeline and records a full-tier attestation per commit; the merge gate refuses a commit without one; a guard suite plants deliberate violations every week to prove each check still fires. A check you never see fail is indistinguishable from a check that is dead.

Memory outside the context window: a file-based memory with an index loaded at session start; decision records that amend each other instead of being rewritten; an Implementation Reality section per spec package recording what shipped and every known mismatch in both directions; and an overnight distillation of each session into typed records a later session queries before declaring that something has no precedent.

Postconditions over dashboards: after a scheduler default fed the memory pipeline its own transcripts for nine days while every stage reported success, the durable fix was a postcondition on the seams between stages. As of the summer's close the operational-lessons file held 26 numbered entries, and the rule for each is that prose is advice and only a check is a guarantee.

Close the loop last: a weekly pass harvests corrections and sweeps them back into the instruction files as a reviewed pull request. It works only because every layer above it exists first.

The Impact

• Since June 10 through the end of August: 4,141 commits and 2,244 merged pull requests across 25 repositories, run by one person; merges held at the June baseline through July and eased through August as effort moved into four quiet systems
• The productive shape changed: on August 29 the whole platform produced ten commits and it was one of the most productive days of the year, because the work was a memory system that survived its worst failure, a statistical screen with a pre-registered ledger that refuses to flatter its owner, a point-in-time data floor, and a product designed entirely on paper
• The failures stayed on the record: a flagship signal that measured nothing, an edge that vanished net of costs, and a self-ingesting pipeline that produced 21,264 junk sessions and about 38 GB of exhaust in nine days while every status surface stayed green. Each became a numbered lesson and then a check
• The person holds the gates: reviewing the improver's pull requests, owning anything that touches spend or publishing, and reading a morning briefing a scheduled job assembles from the platform's own health signals