I haven't run a loop in any serious way. I want to understand if I'm missing the case, or if we're being sold a more elaborate way to spend money on tokens. The honest position is that I keep trying to find the value and the work I actually do doesn't seem to need it.
If you have a counterexample, I want to see it. The rest of this post is the question, made specific.
What loop content actually shows
The genre has a shape. tmux panels with 10+ Claude Code sessions running in parallel, token counters, screenshots of "I ran 12 agents overnight and blew my Max 20x limit," architecture diagrams of agent topologies.
What I almost never see is the value question answered. Even when the artifact does show up, the framing is "look how much code shipped," not "look how much better the product got." A PR isn't an outcome. A merged PR isn't an outcome either. An outcome is a user doing something they couldn't do before, or a product working measurably better than it did last week.
When the value does appear, it tends to come from a specific context: fully automated agent factories at companies with real backlogs and real headcount to redirect. Agent swarms doing support triage at Stripe-scale, finance ops being automated. Those are legible outcomes. Cost savings, ticket throughput, queue depth. The math works because the company has the workload to justify it.
The translation problem for solo builders and small teams is that we don't have a massive support queue, we don't have a finance ops backlog, we don't have 200 tickets a week of bounded, well-scoped work waiting for someone to clear them. The demos that come with receipts are demos for a workload most of the loop discourse's audience doesn't have.
So the narrowed question is this. What did your loop ship, what did it cost, and is your product better in a way users would notice?
What I actually tried
I've been using Conductor (parallel git worktrees + agents) on Thingly, a small mobile app I'm building. Thingly has no .env, no Supabase instance, no docker-compose. The worktree model fits cleanly because there's nothing to share.
What I expected from "running a loop" was overnight fanout: several agents in parallel, less time in the chat, more merged work by morning. What I got was closer to Cursor with extra ceremony. I spin up a worktree, write a prompt for one task, wait, review the PR, merge. One agent, one ticket, same review burden. The product didn't move faster in a way a user would notice; I just changed where I typed the prompt.
Then I think about Aftermath, a project I worked on earlier this year. It had a local Supabase instance, env files, migrations, the usual production-shaped infra. Two worktrees couldn't share the same Postgres. Schema changes from one agent would collide with the other. Local ports collided. I didn't have a good answer for any of it.
I think this is why most of the public fanout demos I've seen are on a toy app. Anything stateful breaks the worktree assumption. The model the orchestrators are built around, isolated workspaces running in parallel, doesn't survive contact with a real local dev environment. If anyone has solved this cleanly, I'd like to see how.
Even if the infra problem were solved tomorrow, the next question is still product value. Parallel worktrees are a delivery mechanism. They don't answer whether the thing you delivered mattered.
Productivity, or a shift in where the work happens
Granting for a moment that the loops do work. The next question, which I haven't seen anyone in the discourse address head-on, is whether running loops makes me more productive or just shifts what I'm doing.
Writing code is one job. Steering architecture, writing tickets sharp enough for an agent to execute on, reviewing 4 PRs an hour, debugging output that compiled but didn't do the right thing, those are different jobs. Both are work. Trading one for the other isn't automatically a win. It might be. The discourse skips the question and goes straight to "you're behind if you don't."
When someone runs a loop, did they ship more user-facing value, or did they spend the same hours doing different work? I don't know. The posts don't say.
What "designing loops" might actually mean in the small case
Strip the abstraction back and a lot of "loop engineering" in the small case looks like this:
- you write a ticket in Linear
- an agent picks it up on a schedule or a webhook
- it works on the ticket
- it opens a PR
- you review the PR (or another agent does it)
- you merge the PR
- repeat
That's still prompting. The surface is a Linear issue instead of a Cursor chat. The agent runs asynchronously instead of synchronously. The cost difference is real, both in time-to-feedback and in trust required. But calling this a new engineering discipline feels like a stretch. It's a different surface for the same fundamental act: telling an agent what to do and verifying what it did.
I'm not saying loops are nothing. I'm saying the slogan oversells what's underneath, at least at the scale most people reading the slogan are operating at.
The incentive worth naming
Most of the loudest "stop prompting, design loops" voices work at frontier AI labs. That doesn't make them wrong. It does mean the discipline they're advocating burns significantly more tokens than a single Cursor session, and the harnesses being recommended are the same harnesses their employers ship or fund. Claude Code, Codex, the orchestrators built on top. Every one of them has growth metrics tied to how many of us adopt loops as a default workflow.
I'd take the slogan more seriously coming from a builder running their own startup on their own credit card, showing me what they shipped, what it cost, and what their product looks like compared to a month ago. That's the post I'm waiting for.
The bottleneck wasn't shipping speed
For a solo builder, shipping code faster has never been the binding constraint. Finding something worth building is. Finding the audience for it is. Getting a single user to care is.
You can run 100 agents in parallel and ship a polished product in two weeks. If nobody uses it, you've paid 100x more for the same outcome. The loop discourse is solving for output. Most of the loudest consumers (indie devs, solo founders, small teams) have a demand problem, not a supply problem.
For a team with a real backlog, a real test suite acting as the verification gate, and a roadmap of bounded, independent tickets, the calculus is different. Loops are probably worth learning there. That workload exists. It's just not the workload of the audience that's most anxious about being "behind."
Where I am
I'll keep using Cursor for conversation-driven work. I'll keep using Conductor where worktrees are cheap. If someone shows up with a loop that made their product measurably better on a project that looks like mine, with a check users would feel (activation, time-to-first-success, crash rate, retention on one funnel step), plus the artifact, the time spent, and a clear before/after, I'll change my mind on the spot, and I'll update this post.
Show me cost in tokens and hours, what the loop shipped, and whether the product actually got better. Until then, I'm going to keep prompting.
- AI
- Agentic Programming
- Productivity
- Thinking
