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

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

writeup, the Claude Code skills translated to English, and the CLI source,

verbatim from my daily setup.

Here's the short version.

The backlog is git data, not a document

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,

and the ticket's status is a field — never a location in a document.

---

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.

Maturation: decide model, effort and review depth per ticket — as data

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.

The lifecycle is applied by hooks, not by anyone's memory

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).

The review gate: reviewers who know nothing

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:

• 
  The evidence of review is produced by the orchestrator, never by the
  entity it audits. The implementer doesn't know the dosage, never sees the
  reviewer prompt, and cannot attest to anything about the review. The SHA is
  read from git programmatically (a hand-transcribed SHA once arrived with 39
  characters), and git status is checked before and after the review.


• 
  Findings have exactly two exits: fixed, or escalated with justification
  (spec is wrong / pre-existing debt / fix breaks a green test). "Not a big
  deal" is not a disposition.


• 
  Reviewers report findings only — no praise. A report that says
  "everything else conforms" manufactures false confidence. It once
  accompanied a report that declared conformant the very decisions it was
  missing a defect in.

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.

What the human actually does

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.

What I'm not claiming

• That you should stop reading code. This is my bet, on my solo project, with
  my risk profile.


• That this is a product. It's a reference implementation extracted from a
  working setup — read it, steal the ideas, adapt the pieces. The
  README has a section on
  exactly which pieces transplant well.


• That the system is finished. Its biggest open problem is honest in the
  README: every rule in it came from an incident retro that I ran by habit —
  the skill doesn't yet trigger its own improvement loop.

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.