← All projects

Ongoing practice-based research · Mustafa Bagdatli · since October 2024

Story, Gate, Ladder, Ledger

I have been building with AI coding agents almost every day since October 2024, about 21,000 commits across my own projects. They are fast and they sound sure of themselves, but they often hand back work that looks done and isn’t. Every time an agent’s work fooled me, I wrote down what happened and changed my setup so the same thing couldn’t get through again. Four principles came out of that. Each one has a name in my code, and the code enforces it, because telling the agent didn’t work. As I put it in one of these projects: “Verbal warnings, even specific and detailed ones, do not fix structural gaps.”

What does a person need to put in place so that work done by AI agents can be trusted, without reviewing every step?

Approach

I studied my own practice. I started with small apps on my laptop in October 2024. In spring 2026 I started building my own agent tooling, and then two bigger products: Loopstr, a workspace for running creative work through agents, and FieldVision, a camera game for kids that agents built almost entirely. I treated each failure as data. My repositories are the notebook: dated decisions, a ledger of lessons, the checks each lesson turned into, and a small test of builder models.

Mission Control, Agents view: thirteen lanes of work with status, pull request and issues
FieldVision, run by agents. Mission Control, the dashboard I built to run it: each line is a lane of work an agent is doing, with its status, pull request and issues. I decide and reprioritise from here.
Work moves from Story to agents working to Gate to Ladder. The Ledger records each human decision and feeds corrections back into the next story. Storydone is written downbefore the work starts Agents workreversible steps runon their own Gatea person decides atthe point of no return Ladderchecks are testeduntil they can fail Ledgerrecords each human decision;each correction becomes a check
Figure 1. The four principles as one loop. A piece of work starts as a story, runs through agents until it reaches a step that cannot be undone, and is checked by checks that have themselves been tested. The ledger keeps every human decision and turns repeated corrections into new checks.

Finding 1 · Story

Agents say “done” before it is

Observation

When an agent says something is done, I learned not to take it literally. Once, an automated check reported a new part of a screen as tested, 2 out of 2, and that part had never even appeared on the screen. I started calling this “looks done but isn’t”, and it became the first thing I design against.

Principle

No story, no measure; no measure, no merge.

Loopstr, CLAUDE.md §1

Mechanism

So every change in Loopstr starts as a short story with a result you can measure. I commit the story first, on its own, while it still fails. Then the code. If the code comes first, CI rejects the branch. This still works when the branch gets squashed into one commit, because the story leaves a line in the commit message.

Accepted order: story commit, then code commit, then the story passes. Rejected order: code commit first, story after; CI rejects it. Accepted 1 · story, failing 2 · code 3 · story passes, merge Rejected 1 · code 2 · story, after the fact CI rejects the branch
Figure 2. The order is the rule. When I write the story after the code, it describes what got built. When I write it first, it describes what I wanted.

Evidence

1,356stories in Loopstr
~1,352merged pull requests
26 Julythe CI gate began

The week I turned the gate on, 463 stories were written against 270 merged changes. A lot of untested work suddenly had to be measured. Since then the two numbers move together.

Open question

I don’t know yet if writing the story first means fewer bugs reach people, or only that I see them earlier. I need a comparison to answer that.

Finding 2 · Gate

If you approve everything, you stop reading

Observation

In the beginning my agents asked permission for everything, and I started clicking yes without reading. My gate code calls this “approval fatigue / rubber-stamping”. Then I realized most of what agents do for me (research, drafts, designs, builds) only creates files I can throw away. Only a few steps actually leave the system: publishing, deploying, creating a database.

Principle

The gate belongs where an action is hard to undo, not on every step.

Loopstr, GATE-AUTONOMY-LADDER.md

Mechanism

So each kind of step now says whether it can be undone. If it can, the agent moves on by itself when it is confident enough, 0.75 or higher. If there is no confidence signal, it waits. Verify, ship and app always wait for me. An automatic run has to stop before the first step it can’t take back, and a project can make its gates stricter but never looser. In Looper, five kinds of tasks always need a person, no matter how much trust the agent has earned.

Seven steps in a row: intake, research, design, page and build are reversible and advance on their own. Verify and ship are past the point of no return and wait for a person. intakeresearchdesignpagebuild verifyship point of no return advance on their own when confidence ≥ 0.75 a person always decides an automatic run must stop before the first step on the right it could reach
Figure 3. I set autonomy per step, by how easy the step is to undo. One overall “autonomy level” would either slow down the safe steps or let the risky ones through.
Loopstr: Gates by exception, not by step. Six stations; four keep moving, two wait for you
How Loopstr shows it. From the public Loopstr site: six stations, four keep moving on their own and two wait for you.

Evidence

27 of 30kinds of step can advance on their own
3always wait: verify, ship, app
42 of 142stations newly held by the cascade rule

Open question

This rule changes where runs stop. I haven’t shown yet that it prevents real damage. I want to test it by planting risky actions in a sandbox.

Finding 3 · Ladder

A check can pass without checking anything

Observation

A test that can’t fail looks exactly like a test that passes. In Loopstr, one function was supposed to say “unknown” and returned a made-up confidence of 0.5 instead. It stayed there for months and let empty runs pass their own gate. Another time I compared what agents said their tests did with real runs: 2 out of 5 had reported results that never happened, even though the brief told them not to.

Principle

A check that cannot fail is not a check.

Loopstr, docs/LADDER.md; agents-discipline

Mechanism

Every time I closed one way a check could fool me, I found the next one. I wrote them down in order, thirteen so far, each with the tool that catches it. Break the code on purpose and see if the test goes red. Run two cases that have to give different answers. Don’t show a claim as done until it points to a source. If a value is unknown, leave it empty, never fill it with a good-looking guess. Four of the rungs still don’t have a tool, and the ladder says that too.

A ladder of thirteen rungs. Each rung names a check that passes and what can still slip past it. Solid rungs have a tool; dashed rungs are written guidance only.
Figure 4. The ladder, read from the top. Each rung is a check that can pass while something still slips past it, and the next rung closes that gap. Solid rungs are enforced by a tool; dashed rungs are only written guidance so far. Hover a rung to see its tool.
Loopstr: An unknown cost stays blank. Never $0.
One rung as an interface. In Loopstr, a cost the provider didn’t report shows a dash, never $0. “That dash is a law, not a style”: the test suite checks it on every run.

Evidence

13rungs, 9 with a tool
2 of 5agent reports fabricated before the gate
33CI checks that enforce a rung

Open question

I don’t know if thirteen is the full list or if it keeps growing. Trying the rungs on tests that agents wrote for other people’s projects would tell me.

Finding 4 · Ledger

More instructions didn’t help

Observation

My first reaction to an agent’s mistake was to add another rule to its instructions. Loopstr’s rules file went from 392 words to 12,857 in nineteen days, and the same mistakes kept coming back. The lessons ledger started on the day I wrote “i thought we were but we werent.” A study published this year found something similar: these instruction files didn’t make agents more successful and made them about 20% more expensive.

Principle

A lesson gets exactly one home, in this order: CI gate, hook, skill, docs, prose.

Loopstr, CLAUDE.md §12

Mechanism

So now, at the end of each session, a hook saves the corrections I made, and the build won’t pass while any of them is unsorted. Each lesson goes to the strongest place it can live: an automatic check if possible, plain text only if nothing else works. The ledger also records what each of my decisions cost, and whether I gave it, steered it or left it to the agent. And my own words stay the way I wrote them. I didn’t want agents to keep “filtering my thoughts like a phone game.”

Loopstr approval card with Approve, Steer and Defer buttons
A decision as the ledger sees it. Each piece of work comes to me as a card. Approve, Steer or Defer is recorded as my decision, and when a provider reports no cost the card says so instead of guessing.
Figure 5. Left: the 34 recorded lessons by where they now live, strongest home first, with how often each group recurred. Right: Loopstr’s rules file in words. It was cut back once its lessons had moved into checks, and is now capped at 7,000 words, the 99th percentile of 211 public files of this kind.

Evidence

19 of 34lessons now live in CI checks
33×rules growth in 19 days, then cut by 60%

Open question

The cost-per-decision part is built, but it barely has any data yet. Next I want to run it for a few weeks and see how much of the cost comes from my own steering.


Context

The two years behind it

Apps on my laptopOther projectsMy agent toolingLoopstrFieldVision
Figure 6. Commits per month, about 21,000 in all. Laptop repositories are counted in the month each began, so their bars are approximate. At least 4,739 commits on GitHub are signed by an agent; many more under my own name were written by agents I directed.
Figure 7. Seven builder models on four already-merged FieldVision issues, checked against hidden tests and judged by a stronger model. Cost per mergeable result, log scale. The cheapest model scored best and became the default; four issues is a small sample.

Prior work

What is new, and what is not

Most of the ingredients aren’t new. People already write specs first, gate on reversibility, use mutation testing and track cost per run. So I searched published work to see which of my specific versions already exist. For the ones marked below, I couldn’t find a close match.

IdeaClosest published workDifferenceStatus

The short version. Autonomy frameworks give an agent one level; I give each step its own, based on whether it can be undone, and an automatic chain stops before the first step that can’t. Mutation testing proves a test can fail; my ladder lists thirteen ways a check can verify nothing, with a tool for each. Observability tools price a run; my ledger prices a human decision and records who caused it.

Limitations and next studies

What this does not show yet

  1. There is no baseline yet. I need to do matched tasks with and without the method to see if it really means fewer bugs, or just moves the effort somewhere else.
  2. It’s one person’s practice: mine. Two or three other people using it, with interviews or think-aloud sessions, would show what carries over.
  3. Some numbers are small. The model test is four issues, and the fabrication rate comes from about ten agent runs.
  4. The ledger’s cost-per-decision data barely exists yet, and some rules, like keeping my words as written, are stated but not enforced.
  5. My own design critic got taste wrong on 3 of 6 test pairs. I kept that in the record, because the ladder has to apply to my own tools too.

Sources: my repositories Loopstr, Looper, Mission Control, agents-discipline, aic-pipeline-kit and FieldVision, read 13 October 2026, and a summary of my laptop’s git history. Prior work: Anthropic, “Building effective agents” (2024); OpenAI, “A practical guide to building agents” (2025); Feng, McDonald and Zhang, “Levels of Autonomy for AI Agents” (2025); GitHub Spec Kit (2025); Meta, mutation-guided test generation (FSE 2025); Gloaguen et al., “Evaluating AGENTS.md” (ICLR 2026); Langfuse cost tracking; git-ai; METR’s study of developer productivity with AI (2025).