Should You Even Build a Loop?
Loops cost real money and effort. Before you build one, run a simple test - miss one condition and the loop costs more than it saves
The Most Important Lesson in This Level
Here's a truth most excited tutorials skip: most tasks should NOT be loops.A loop has a setup cost and burns money every time it runs (the AI "thinks" in tokens, and tokens cost money). For a one-time job, a single good prompt is faster and cheaper. Building a loop for the wrong task is the number-one way people waste time and rack up surprise bills.
The 4-Condition Test
A loop only makes sense if it passes all four of these. Miss even one and stay in your chair and prompt by hand.
It happens regularly (say, weekly or more). A loop spreads its setup cost across many runs. If it happens once, you don't have a loop - you have a script you ran once.
There's an objective gate that can reject bad work with no human in the room- a test suite, a type checker, a linter, or a successful build. Without this, you're back to reading every result yourself, which defeats the point.
Loops explore: they re-read big files, retry dead ends, and burn tokens whether or not they succeed. That's fine on a big company plan; it can be reckless on a small personal one.
It can't fix what it can't see. It needs logs, a place to run the code, and the ability to actually execute what it just wrote to see what breaks.
The 30-Second Loop Check
The 4-condition test is your strategy. This checklist is the quick tacticalversion you run on one specific task before handing it to a loop. Can't tick every box? Keep it a manual prompt.
☐ This task happens at least once a week. ☐ A test, type check, build, or linter can instantly reject bad output. ☐ The agent has a live environment to run and test its changes. ☐ The loop has a hard stop (token cap, timeout, or max iterations). ☐ A human approves before anything merges or ships to production.
Good First Loops vs. Bad First Loops
Some tasks are perfect to start with. Others will burn you. Know the difference.
GOOD FIRST LOOPS (repetitive + machine-checkable) ✓ CI failure triage - sort nightly build failures, draft easy fixes ✓ Dependency maintenance - weekly version-bump requests ✓ Lint-and-fix passes - auto-correct style on every change BAD FIRST LOOPS (keep a human in the chair) ✗ Architecture overhauls / refactoring core systems ✗ Authentication, cryptography, or payments code ✗ Production deploys ✗ Vague feature work where "done" is a judgment call
The pattern: good first loops are tasks a careful junior could do with a checklist, where a strong test suite would catch their mistakes. Bad ones need human judgment about what "right" even means, or are too risky to get wrong.
Who Wins and Who Loses
The economics aren't the same for everyone - and that explains why some people call loops "obvious" while others call them "reckless."
Who should skip it (for now): solo builders on small metered plans (the bill arrives before the gains), codebases with no automated tests (no gate = no safety), and teams whose real bottleneck is human review (a loop just piles more into the jam).
If you're on a small plan with no tests, that's not a failure - it just means your first move is to add tests, not a loop. The loop comes later.
Hands-On: Test Your List
Build a loop only if: it repeats, checking is automatic, the budget absorbs waste, and the agent has real tools
An objective checker (test/linter/build) that rejects bad work with no human - the make-or-break condition
Per-task checklist: weekly, auto-rejectable, live environment, hard stop, human approval before merge
CI triage, dependency updates, lint-and-fix - repetitive and machine-checkable
Auth/crypto/payments, architecture, production deploys, vague "done" - keep a human in the chair
Loops favor teams with tests and budget; solo/untested/review-bottlenecked setups should wait