"I don't prompt Claude anymore. I have loops running that prompt Claude."
That's a line from Boris Cherny, creator of Claude Code.
The first time I read it, it completely reframed how I think about coding agents. It's also the reason I built LoopFlow.
https://github.com/faisalishfaq2005/loopflow
For the last couple of years, my workflow with AI coding tools looked the same: write a prompt, read the output, write another prompt, review the result, then repeat. The human stayed in the middle of every step.
A loop changes that dynamic.
Instead of continuously telling an agent what to do next, you define what "done" looks like and let the agent iterate toward that outcome. The workflow becomes: attempt → verify → retry until success or until the loop reaches a limit.
That sounds great in theory. In practice, the moment I started letting agents run unattended, three problems appeared almost immediately.
Problem #1: Agents Grade Their Own Homework
The same model that writes a fix is usually happy to tell you that the fix works.
That's a problem.
In LoopFlow, verification is handled by a separate gate agent with a completely different role and persona. The gate acts like a skeptical reviewer rather than a collaborator. For a loop to succeed, the reviewer must explicitly conclude with:
VERDICT: PASS
Anything else counts as failure.
No verdict means no pass. An unverified success isn't a success.
Problem #2: Unattended Loops Burn Money
A loop that can work autonomously can also make mistakes autonomously.
Without limits, an agent can spend a surprising amount of money repeatedly chasing the wrong solution.
That's why every LoopFlow run has a hard budget. The ceiling is enforced both by the LoopFlow runner itself and by Claude Code's own --max-budget-usd setting on every step.
The loop can keep trying.
It can't keep spending forever.
Problem #3: The Agent Forgets Everything
Agents are stateless.
What they learn in one run disappears in the next.
To solve that, every LoopFlow loop maintains a simple Markdown memory file. After each iteration, observations are appended to memory and injected into future prompts.
The agent forgets.
The repository doesn't.
What Does a Loop Look Like?
A typical loop is surprisingly small:
name: test-and-fix
budget:
max_usd: 2.00
max_iterations: 3
steps:
id: fix
role: You are a careful maintainer who never weakens a test to make it pass.
prompt: Run the test suite. Fix the root cause of any failure. Re-run to confirm.id: review
gate: true
role: You are a skeptical senior engineer reviewing a change you did not write.
prompt: Inspect the diff, re-run the suite yourself, and verify that no test was weakened.
One agent writes.
A different agent reviews.
Memory makes every iteration smarter than the previous one.
Trying It Out
npm install -g @loopflow/cli
cd your-project
loopflow init
See exactly what each agent will be told
loopflow run test-and-fix --dry-run
Execute the loop
loopflow run test-and-fix
LoopFlow doesn't introduce another cloud service, daemon, or API layer.
If Claude works in your terminal, LoopFlow works too.
Staying the Engineer
The biggest lesson I've learned from building loops is that they don't replace engineers.
They change what engineers spend their time doing.
The faster a loop can generate code you didn't write, the more important it becomes to understand what was actually produced. Otherwise, the gap between the software that exists and the software you understand grows very quickly.
That's why LoopFlow keeps memory files, preserves worktrees, and makes verification explicit. The goal isn't to remove humans from the process. The goal is to move humans into higher-leverage positions within it.
Build loops.
But build them like someone who intends to remain the engineer, not just the person who presses "Run."
LoopFlow is open source (MIT), written in typed and tested TypeScript, and already has 35+ GitHub stars from developers experimenting with loop-based workflows.
If you build a useful loop, I'd love to see a contribution to the cookbook:

Top comments (0)