I ran 3 months of spec-driven development without ever reading the code

A developer known as a scrum master ran a three-month solo project using spec-driven development without ever reading the code, relying on LLMs to write specs and tests. The system, published as 'backlog-as-data', treats the backlog as YAML frontmatter in spec files, with lifecycle automation and fresh-context reviewers to avoid confirmation bias.

I'm a scrum master. I was a developer ten years ago. I have enough background to discuss design and trade-offs with an LLM — but three months ago I made a deliberate bet on my solo project: I would never read the code. The specs define the tests. The tests control the code. The code is a black box. I'm not claiming this is what everyone should do. But it's my bet, and it forced a system into existence: when nobody reads the code, the process has to carry the trust that a code-reading human normally provides. I've just published that system as a reference implementation: backlog-as-data — the full Here's the short version. Most agent task-management tools store tasks in a dedicated place — a tasks.json , a database, a backlog/ folder. My bet is different: the backlog is the YAML frontmatter of my spec files. One file per ticket, python --- id: PARSE-07 title: Tolerate CRLF in decklist import type: ticket status: todo priority: should exec: model: sonnet effort: think review: light matured: 2026-07-22 --- PARSE-07 — Tolerate CRLF in decklist import The spec body: design, contracts, test cases. The ticket file IS the spec. Everything below the frontmatter is the spec — written by the LLM, after it has challenged the need I expressed in conversation. The frontmatter is data — owned by a small CLI, mutated only through it. Same file, so they can never drift apart. Why it matters: "move it to Done" is not an operation. LLMs and humans mangle documents when a state change means relocating text. Making status a field makes every transition a one-line, idempotent, testable mutation. The board I look at a small web page on my server, with GitHub deep links to each spec and the readable markdown view are generated projections , locked by a do-not-edit sentinel and covered by a coherence test. Committing to a ticket and deciding how hard to think about it are separate acts. Before any agent runs, a ticket gets matured with a triplet: model — which model implements it haiku → fable effort — reasoning depth injected into the prompt review — the review gate dosage: none , light 1 reviewer , deep 3 A trivial rename gets haiku / none / none . An irreversible data migration gets the most capable model, maximum reasoning, three reviewers. The decision is versioned with the ticket and auditable months later matured: <date . And the implementer sub-agent runs exactly the matured model — its report must open with Model used: … so the decision is verifiable after the fact. This is lean thinking applied to agent budget: pay for defect detection in proportion to the cost of a defect slipping through. todo → wip → merged → shipped is set by hooks attached to my workflow commands — launch sets wip , integration sets merged only for tickets whose feat TICKET-ID : commit is actually on the branch , deploy sets shipped . Nobody — human or agent — moves the back half of the lifecycle by hand. The hooks always exit 0 lifecycle automation must never block a delivery and commit surgically a shared main checkout with 10+ parallel worktrees taught me that git add specs/ sweeps up a neighbor session's work — lesson learned the hard way, with a date on it . This is the part I haven't seen elsewhere. When the implementer sub-agent finishes in its own isolated git worktree , the orchestrator spawns fresh-context reviewers : they get the ticket id, the spec path, the worktree, the commit SHA, and four review axes. Nothing else. No summary of what the implementer did, no hints of where to look. Contaminating a reviewer's context is the main vector for confirmation bias. Three details that took incidents to learn: git status is checked before and after the review.Does it work? The day before publishing, I ran the gate on the published repo itself: a fresh reviewer compared my English translations against the French originals and raised 3 findings — including a mistranslated counter that would have silently corrupted the review register of anyone following the English version. The gate paid for itself on its first public outing. My three touchpoints per ticket are all decisions, never mechanics: agreeing on the need in conversation — the LLM challenges me, then writes the spec , saying "mature it and run it" with the review dosage , and deciding to deploy. Everything in between — the CLI calls, the spec writing, the agent orchestration, the integration — is the agent's job. I never type a backlog command. The CLI is agent-facing: determinism comes from the agent having no hand-editing path, not from me doing the bookkeeping. If you're running coding agents daily and your backlog is still a markdown to-do list that gets mangled every time an agent "moves something to Done" — the data model alone might be worth the read: github.com/giboulz/backlog-as-data . Happy to answer anything in the comments — including whether the never-read-the-code bet has burned me yet.