I researched loop engineering to build a product. I built nothing.

I went into last week intending to ship a loop engineering tool. The term is two months old, the searches are climbing, and I build guardrails for AI coding agents — it looked like my lane. I killed the idea twice.

If you're eyeing the same space — as a builder or just deciding what to adopt — the map that stopped me is more useful than another definition post. Page one of every search is definitions. Here is what actually exists.

The 90-second history

May 2025: Geoffrey Huntley wires a coding agent into a bash while true loop that re-feeds it the same prompt file until the work is done, and names it after Ralph Wiggum — ignorance, persistence, optimism. It works embarrassingly well, and The Register covers it as a genuine technique rather than a joke.

June 2026: Boris Cherny, who created Claude Code, says he doesn't prompt it any more — loops prompt it for him. Addy Osmani wraps a name around the practice, and "loop engineering" joins the lineage: prompt engineering, then context engineering, then harness engineering, now this. Roughly one new layer per year, each wrapping the one before.

So the concept is real. The question for anyone thinking of building here is different: is there room?

The map: what already exists

First stop, the GitHub topic pages. This is one command and it settles most arguments:

$ for t in loop-engineering ralph-wiggum graph-engineering; do
    printf "%-18s %s repos\n" "$t" \
    "$(curl -s "https://api.github.com/search/repositories?q=topic:$t" \
       | grep -m1 total_count | grep -o '[0-9]*')"
  done
loop-engineering   358 repos
ralph-wiggum       130 repos
graph-engineering  36 repos

Nearly five hundred repos across the two loop topics, two months after the term existed. Walking the actual listings, they sort into three shelves:

The runners. Tools that keep an agent looping until done. The topic leader sits near 10k stars, with multiple independent orchestrators around 3k. Every language, every agent CLI, every flavour.

The guardrails. Iteration caps, dollar budgets, no-progress detection, human checkpoints, review gates. At least three projects ship all of these today. The obvious "safe loop" product already exists several times over.

The platform itself. This is the shelf that ends the conversation. Claude Code shipped /goal in May — a native loop that runs until a condition you wrote is true, with a separate model grading each turn — then /loop, /schedule and /batch, then an official guide to all four. When the platform vendor absorbs a pattern into the product, the third-party version of that pattern is on a clock. Codex and Gemini CLI have equivalents.

And the tell that a category has finished consolidating: the curated awesome-lists have real stars now. Nobody curates an empty room.

What the honest practitioners say

The critiques are more interesting than the hype, because they point at what is unsolved.

The Pragmatic Engineer surveyed a couple of hundred developers and found adoption much narrower than the noise suggests — most real usage is ordinary automation wearing a new name, and human-in-the-loop still often beats autonomy.

Black Matter VC, from someone actually running loops in production: genuine leverage, but token burn runs roughly 4× a normal chat session and up to 15× for multi-agent setups. And the failure mode he names is not technical. He calls it comprehension debt — the gap between what's in your repo and what you actually understand, widening every time a loop ships code nobody read.

Notice what's missing from both critiques: neither says "we need another runner."

The gap

Line the tools up against the lifecycle of a loop and the shape jumps out. Before the run: policies, budgets, gates — covered. During the run: progress detection, checkpoints, caps — covered. Then the loop exits, and you are standing in front of two thousand changed lines with a cheerful four-sentence summary, at whatever hour it is.

That moment — the morning after — has no tooling. It is the exact moment comprehension debt gets paid or deferred, and every project in those 488 repos has already clocked off by the time it arrives.

That's the verdict that killed my loop product twice: the crowded part is finished, and the empty part isn't a loop tool at all. It's a reviewing problem. So instead of runner number 359 I built plumb — it holds the agent's summary against the diff and prints only what the summary left out: the files it never mentioned, the assertion that quietly disappeared, the test that got skipped instead of fixed. Zero dependencies, no model calls, and it doesn't care whether the code came from one prompt or a forty-iteration loop.

The method, if you're weighing your own idea

Check the topic page before you write a line. One curl, shown above. The repo count and the star spread tell you which shelves are full.

Check whether the platform vendor already shipped it. A feature in the CLI beats a repo, every time, forever.

An awesome-list with real stars means you're late. Curation is what happens after consolidation.

Then look for the moment in the lifecycle nobody covers. Categories crowd around the exciting phase — the run, the loop, the autonomy. The boring phases either side of it are usually empty, and the boring phase is where the actual pain lives.

A day of research, nothing built, and I'd call it the most productive day of the month. The cheapest product is the one you find out not to make.

The tools: singhlabs.dev. All MIT, all zero-dependency, all built after this same go/no-go research — including the two ideas that died so plumb could exist.

If you're running loops in production: what do you actually do with the output the morning after? Genuinely asking — it shaped one tool already and I suspect there's more there. Tell me.