✅ Good For: GitHub Issues in Batch
The most natural use case for loop engineering is batch processing of well-defined, independent tasks. GitHub issues are the perfect example: each issue is isolated, has its own context, and can be resolved in parallel without stepping on others.
🔧 How Cole Medin Uses It in Practice
Cole demonstrated live the workflow he uses most in his day-to-day work: taking multiple GitHub issues and dispatching workflows in parallel with Archon, each running in its own isolated worktree.
"Most of the input for my day-to-day work is issues in a repo. Either I'll create them or someone else will. And so we can use Archon to send off workflows to run in parallel, handling multiple GitHub issues at the exact same time."
The crucial point: each issue is an atomic unit of work. The orchestrator doesn't need complex reasoning to break down the work because the breakdown is already provided by the issue list. This minimizes the risk of poor orchestrator decisions and maximizes the chance of success.
Why it works well
- ✓Independent tasks - each issue can be resolved independently
- ✓Limited context - the agent only needs to understand one issue, not the entire system
- ✓Clear validation - tests pass or fail, PR is created or not
- ✓Isolation with worktrees - each agent works on a separate branch
🧪 Good For: Exploration and Proofs of Concept
Cole Medin explicitly acknowledges that loops shine when the goal is explore ideas and build proofs of concept quickly. When production quality isn't necessary and iteration speed is what matters, loops are a powerful tool.
"And I think it’s really good for building proofs of concept and exploring ideas. But I don’t want to do all my AI-assisted coding with it."
Ideal Scenarios
- ✓Prototype a feature before investing human time
- ✓Explore N approaches to a problem in parallel
- ✓Generate boilerplate or project scaffolding
- ✓Test the technical feasibility of an integration
The Demo Example
Cole showed the dashboard building a Kanban board as a single-page app. A perfect task for loops: it’s a self-contained application, validation is visual (it works or it doesn’t), and it doesn’t need to be production-ready. "Super easy to get this up and running if you just want to check out the GitHub repo."
⚠️ The Exploration Limit
The risk here is confusing a PoC with production. A loop can generate something that "works" on the surface but has structural problems that only show up at scale. The rule: use loops to explore, but not to deliver.
🚫 Not Suitable for: Critical Production Code
Cole Medin is categorical: loop engineering is not the path to the best possible results with AI. When code needs to be reliable, maintained by a team, and moved to production, the loop's full autonomy is a risk, not an advantage.
"There is no way you're gonna convince me that loop engineering is the way to get the best results possible with AI coding assistance."
⚠️ When Loops Fail
Production code with real users
Bugs introduced by autonomous loops reach end users. Without rigorous human-in-the-loop oversight, the cost of fixing them exceeds the cost of doing the work manually.
Systems with complex dependencies
When a change to one component affects others, the agent needs a system-wide view that exceeds what typical loops offer. Context bloat is the direct symptom.
Architectural decisions
Loops handle well-defined tasks well. Architecture decisions require human judgment, business context, and long-term vision that no loop can provide.
The “Run for a Day” Problem
Cole shares his direct experience: "I've had that myself as I've tested a lot of things within Claude Code, like routines and slash loop. And you have a run for a day, and by the time it comes back, you just have crap." Without human validation checkpoints, long loops gradually degrade.
💸 Not Good For: Limited Budgets and No Observability
Loop engineering assumes two resources that not everyone has: budget for burning tokens e infrastructure to monitor what the loop does. Without both, you're flying blind and paying dearly for it.
💰 The Cost Problem
Cole built the cost-tracking dashboard for exactly this reason. A single run for a relatively simple application consumed more than 1 million tokens. The orchestrator has to reason at every round, and each reasoning round is expensive.
"In a single run, I spent over a million tokens just to build a relatively simple app."
👁 The Blindness Problem
Without a dashboard, structured logs, or cost tracking, you don't know what the loop is doing. Cole emphasizes that he built the Agent Control Plane precisely because without observability, you "run for a day, come back to crap" without understanding what went wrong.
The Contrast with Peter Steinberger
Cole points out that the biggest advocates of loops operate with resources most people don’t have. Peter operates with "pretty much an infinite budget". Boris has Anthropic’s infrastructure. For a solo developer or a startup on a tight budget, every million tokens burned on the orchestrator’s reasoning is a million fewer for useful work.
🧭 Decision Framework: "Does This Actually Need a Loop?"
Before setting up any loop system, the fundamental question is: does this task really need a loop? Often, a well-written direct prompt or a deterministic workflow solves the problem at lower cost and with greater reliability.
🔍 Decision Checklist
Can the task be broken down?
Can it be broken into independent subtasks? If not, a loop won't help. If so, continue.
Is the completion criterion clear?
"All tests pass" is clear. "Clean code" isn't. Without an objective exit condition, the loop runs forever.
Does the cost justify the result?
If the loop will spend 1M tokens on something you can do in 30 minutes, the loop isn't worth it.
Do you have observability?
Can you see what the loop is doing in real time? If not, don’t use it. Running a blind loop burns money.
"I’d include loop engineering under harness engineering. It doesn’t really deserve its own buzzword. But there are some good ideas here."
❓ Questions and the Golden Rule
The golden rule that emerges from Cole Medin’s analysis is straightforward: use loops to distribute work, but keep humans involved for validation. Loops are excellent execution multipliers, but terrible quality decision-makers.
Loops for distribution, humans for validation
The pattern Cole demonstrates with Archon: the orchestrator assigns tasks to workers in parallel (distribution), but a human validates the PRs before merge (validation). "We can always have it pause for us to validate something before it continues." That's the balance that works.
Loop Engineering is an ingredient, not a meal
Cole is emphatic: loop engineering should be folded into "harness engineering", a broader concept. Loops are one tool in the toolkit, not the entire paradigm. "I really do want to incorporate loop engineering. I like the concept of it. But you got to have the right system."
The decision depends on the context
There is no universal answer. A solo developer on a tight budget will use loops differently from Boris managing thousands of agents at Anthropic. The decision framework above helps, but the final judgment is always human and contextual.
🎯 Reflection Point
Cole ends the video with an honest challenge: "I hope I've inspired some ideas for you. Really, I would just fold loop engineering into harness engineering." The message is clear: don’t buy into the buzzword wholesale. Take the good ideas (distribution, incrementality, observability) and integrate them into your own workflow, with the guardrails your context requires.
📋 Module Summary
Next Module:
3.1 - Basic Loop with Claude Code: hands-on with /loop, /goal, and plan.md