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,
---
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
---
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 promptreview
— 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.