Many people still use Claude Code as a question-and-answer tool: give one prompt, wait for one change, then let a human decide the next step.
If every round still requires a person to read the result, copy the error, and add another instruction, the work has not been delegated. The person is still acting as the loop.
Loop Engineering moves the goal, execution, validation, repair, and stopping conditions into one runnable workflow.
This is not a stunt, and it does not mean letting a model retry forever. The value is turning repeated judgment into checks while keeping permissions, cost, and human handoff under human control.
This is how your work works now.
-
You input a prompt.
-
Claude edits a file.
-
You run tests.
-
It fails.
-
You paste the errors back.
-
It tries again.
Twenty minutes later, you realize you’ve been taking care of the thing you originally wanted to give to someone else.
You are the loop. You are the one who checks the work and decides the next step, every time. This is the work that the loop takes over.
An example shows all the differences
Please have Claude write a one-page brief on any topic. A simple task. It will produce clean, confident content and include sources at the bottom.
Now read these sources. Some of them are fake(!!!). Claude made them up, but he doesn’t even know it himself. They look very real. The links either go to places that don’t exist or lead to content that isn’t what Claude claims. This is the way Claude quietly "tricks you," and a single prompt can never catch it, because Claude will remain confident that he is correct until someone opens the links.
Now switch to running in a loop. The brief is the same, but you need to add a column that can be measured:
Each statement requires at least three sources, and each link must open a real page that supports the statement.
See what happens. After Claude finishes the summary, it then checks each link one by one. It opens each link. It removes invalid and fake links. It finds real replacement links. It keeps checking until every source on the page can be opened. Then it stops.
It never gets bored. It never skips boring parts.
Here is a minimal loop in Claude Code. The commands are the easy part; the important step is defining what “done” actually looks like.
What is a loop
A loop is a small system that continuously sends prompts to Claude until the work is completed.
Every loop, no matter how complex, follows the same five steps:
1 . Look for work. Open tasks, failed tests, unread emails, files in folders.
1 . Do it. Claude handles one item at a time, just like you would manually.
1 . Self-check. Double-check to confirm that the work is completed and correct, not just that a result was produced.
1 . Remember. It records what has been completed, so work is never repeated or progress lost.
1 . Try again. It will repeat until there is nothing left, then stop or alert you.
One sentence to remember: The prompt is doing the work. The loop engineer is managing the worker.
"Isn’t this just a scheduled task?"
Good question. No.
You can already have your computer run the same program every morning at 8 just this time. This is a cron job. It is older than most of us. It runs a fixed script. Each time it follows the same steps, no thinking required.
The difference with a loop is one thing: there is a decision-maker inside.
A scheduled task runs a script. A loop runs Claude. Claude checks the current situation, chooses the next action, executes it, checks the results, and then decides what to do next. Continue. Try again. Undo. Stop.
The decision in the middle is the key. A script cannot look at a failed test and figure out different ways to fix it. Claude can. This only becomes possible if Claude and ChatGPT are good enough to make real judgments in the middle of work.
The two commands to run the loop
This is where most people make mistakes. You can’t create a loop by typing ‘do this in a loop’ in a regular chat. Claude Code has two built-in commands, and which one you use depends on the type of loop you need.
1 . /goal is the one that keeps running until completed.
But obviously, that’s not the kind of goal. xD
You saw /goal in a brief example. You input it and then describe what “completion” looks like. Claude will continue working round by round on its own. After each round, a second copy of Claude quietly checks: have we achieved the goal? If not, it tells the first Claude the reason, and then the work continues. Once the goal is reached, this loop automatically stops.
Checking itself each time is exactly the difference between a real loop and a prompt that runs once and hopes for the best.
Use /goal when there is an endpoint. Keep working until this condition is true.
2 . /loop is a rhythmically repeated loop.
When work is not about ‘completing a bunch of tasks’ but ‘paying attention to something,’ use this. You tell it the frequency and what to do, and Claude will execute it for you again.
30 m means every 30 minute. You can also directly say ‘Every morning, organize my inbox,’ and Claude will help you schedule it.
When there is no finish line, just a rhythm, use /loop. Check this over and over again.
Most of the strong loops you build start with /goal. These are recent Claude Code features, so if you don’t see these commands, update Claude Code and they will appear.
Your first loop, get ready to paste
For small tasks, one line of goals is enough. For large tasks with many steps, you need to provide Claude with full task instructions: where to find work, how to self-check, how to remember, and when to stop.
Fill in the content in the parentheses and paste it into the Claude code:
You are running as a loop, not answering a single prompt. Here are your task instructions.
The state file is the unsung hero. Without it, every run starts from scratch. With it, the loop can precisely continue from where it left off, even if it runs as planned.
When you should not set up a loop
Loops are not free, nor are they suitable for every situation. Before starting, there are three honest things to keep in mind.
1 . One-off tasks do not require loops. If the work has only one answer, prompting directly is faster. Loops are only worth their setup cost for repetitive tasks or work involving many parts.
1 Loops are more costly. A self-checking and retrying loop runs Claude multiple times for each item. Under Claude’s plan, you will reach usage limits faster.
1 Vague work does not belong in iterative loops. "Coming up with a better product strategy" is not an iterative loop. First, figure out the real goal.
Starting this week
Choose a task that you have always done by hand, one that has many small parts. Paste the procedure. Fill in the brackets. Run through it step by step as you watch.
Schedule low-risk work only after a small trial, evidence capture, and stopping conditions are reliable. Keep a complete log for the first unattended run and review it the next day instead of assuming success.
The useful distinction is simple: a prompt describes one action; a loop manages a job.
Original media attachment
Image alt text, image
Turn the loop into a handoverable local process
A reliable loop must at least answer: what to read in this round, what changes are allowed, what to use for checking, how to fix failures, the maximum number of retries, and when to hand over to a human. Predefined workflow paths are not the same as dynamically choosing processes and tool agents, and not all automation needs to be packaged as an "intelligent agent."
Claude Code’s Stop hook can call checking logic before ending, for example, running tests; the HTTP hook can send event data to a specified endpoint. These mechanisms can support validation and notification, but they cannot define for you what counts as completion. Codex’s harness is also responsible for coordinating the agent loop between the user, model, and tools.
Independent subtasks can run in parallel, but steps with dependencies still need to be ordered and share state.High-risk tasks without reliable automated verification are not suitable for fully unattended operation.
During local test runs, please restrict permissions to a dedicated working directory, fix the budget and maximum number of iterations, and save the input, modifications, command output, and check results for each iteration. As long as the checker cannot give a clear pass, the loop should stop, rather than using the model’s own "completed" as evidence.