🔁Loop engineering · stop hand-flying the AI and let it work toward the goal on its own

1. The moment: when you realize YOU are the engine

Think about how you work with AI today. You write it an instruction. You wait. You read what it did. You tell it "now fix this." You wait again. You review. "Now add that." Over and over. It works — but there's a silent problem: you are the engine of the whole thing. Your attention is the fuel. The second you get up for a coffee, the project freezes.

The loop engineering moment arrives when you think: "what if I didn't have to sit here cranking the handle at every step? What if I gave it a goal and it figured things out on its own until it was done?". That's exactly what it is. A Firecrawl article on the subject put it perfectly: with loop engineering, the AI stops being a collaborator on the other side of the chat; it becomes a function that a program calls in a loop.

2. The pain: manual work doesn't scale (and it burns you out)

The pain of not making this leap is real and honest — it's not an apocalypse, it's wear and tear. These are the symptoms:

3. The heart: the Act → Observe → Reason → Repeat cycle

Every loop, however simple or complex, turns on the same four steps. Memorize them, because they're the essence of everything:

The difference from normal chatting is the fourth step: the AI decides whether to keep going, not you. The loop runs on its own until the goal is met or until it hits a limit you set (we'll look at those limits now — they're sacred).

4. The 3 sacred brakes (without them it's not a loop, it's an open tab)

This is the part NOBODY tells you and the most important one. A loop that runs on its own can spend credits on its own. Most of the art of loop engineering isn't making the AI iterate — it's stopping it from iterating forever and draining your account. There are three brakes that must ALWAYS exist:

5. The habit: thinking in loops, not in loose messages

Loop engineering isn't something you do once. It's a constant shift in mindset. Every time you're about to do a task with AI, before writing the first prompt, ask yourself: "is this a loose message, or is it a loop?". Most big tasks are loops disguised as many messages.

6. How to set up your first loop (with commands that actually exist)

Here's the nice part: you don't have to program anything weird. If you use a modern coding agent like Claude Code, it already ships with the pieces built in. These commands are real and are in its official docs:

And the supporting pieces that make a loop reliable also exist: worktrees (claude --worktree) so several agents can work without stepping on each other, skills (folders with a SKILL.md) so the AI doesn't rediscover your context every time, hooks to attach actions at key moments, and MCP connectors so the loop can reach external tools (Slack, GitHub, your database).

7. How it's actually used: design first, then invoke the command

Here's the detail almost every tutorial skips, and it's KEY: the loop doesn't start on its own just because you describe the task. Pasting a long text saying "set up a loop that fixes my tests" makes the AI design the plan for you — but it does NOT run it. For the AI to actually start iterating, you have to type the command explicitly (in Claude Code, /goal or /loop). It's two steps: first you design, then you invoke.

Step 1 — Design the loop. Paste this to your agent, filling in the [brackets]. It'll hand you back the plan, the brakes and — importantly — the exact command you should type afterward:

I want to set up an autonomous loop (loop engineering) for this task: [DESCRIBE THE TASK, e.g.: "find and fix all the failing tests" or "deeply research my 5 competitors and synthesize a report"].

My tool is: [Claude Code / Cursor / other]. Before designing, look at my project and tell me the exact command or signal that serves as the "source of truth" for this task (e.g. the real test command, or how "done" is measured). If you can't find it, ask me.

Design it with me following the Act → Observe → Reason → Repeat cycle. I need you to propose, in clear language:

1. THE GOAL: the exact and VERIFIABLE "done" condition (how we'll know the loop should stop because it genuinely met the goal).
2. WHETHER an OPEN loop (freedom) or CLOSED loop (laid-out steps) is better for this task, and why.
3. THE CYCLE: what the AI does each round (act), how it checks the result (observe), and how it decides whether to keep going (reason).
4. THE SEPARATION: one agent that DOES and a different one that VERIFIES the result (including the anti-cheat rule below).
5. THE 4 BRAKES, mandatory:
   - Iteration cap (maximum number of rounds).
   - Stall check (stop if it's no longer progressing after N rounds).
   - Spend cap (token or time limit).
   - ANTI-CHEAT RULE: forbidden to delete, skip or weaken what's being verified to fake success. You have to fix the ROOT CAUSE (the real code), not slap on a patch that silences the symptom. If a round leaves MORE broken than it fixes, revert that round.
6. THE EXACT COMMAND I SHOULD TYPE MYSELF to run it (don't run it on your own). In Claude Code: if the task is "iterate until a condition is met" use `/goal <condition>`; if it's "repeat every so often" use `/loop <interval> <prompt>`. Give me the line already written, ready to copy, with the stop condition and the brakes included. Verify that the command actually exists; don't make it up.
7. WHAT I CAN SUPERVISE while it runs, one readable line per round even though I don't program, so I don't fall into understanding debt.

First show me ONLY the complete design, the 4 brakes and the exact command to type. Do NOT run the loop: I'll fire it by typing the command once I approve the design.

Step 2 — Fire the loop with the command. When the design and the brakes convince you, NOW you type the command the AI gave you. For "work until a condition is met" (the most common case), in Claude Code that's /goal. For example, to fix tests it'd be something like:

/goal all tests pass (run the full suite), without deleting or skipping any test, max 15 rounds

From there, the AI runs, observes the result, reasons and tries again on its own after each turn, until a fast model confirms the condition is met (or until it hits a brake). If what you want is to repeat something every so often (watch a deploy, say) instead of iterating toward a goal, then the command is /loop:

/loop 5m check whether the deployment finished and let me know what happened

8. The easiest paths · what the AI does and what you decide

To keep it from getting complicated, here's what your coding agent can do on its own through the chat, and what stays your decision:

Summary · your loop engineering checklist