giboulz

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.

Enter fullscreen mode Exit fullscreen mode

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.