Loop Engineering: The 4-Phase Process (and Why Prompt Engineering Isn't Dead)
Loop Engineering: The 4-Phase Process (and Why Prompt Engineering Isn't Dead)
Loop engineering is the practice of setting up an AI agent to attempt a task iteratively — over and over with scaffolding — until it hits a defined success criteria. And here's the part everyone gets wrong: a loop is still just a prompt. It's a prompt repeated with some extra structure around it. So the whole "prompt engineering is dead, only loop engineering matters" take that's flooding YouTube and X right now is not just wrong — it's backwards.
I've watched the conversation around loop engineering completely lose the plot. Every video, every thread, the same recycled hot take. So let me cut through the hype and give you what actually matters: what loop engineering really is, the four phases every loop has, when a task even belongs in a loop, and the one thing that decides whether your loop works or just burns tokens.
What Is Loop Engineering?
Loop engineering is when you go to Claude Code, Codex, or whatever agent coder you're using, and instead of saying "here's the prompt, go do it," you set the task up so the agent completes it by iterating over and over until it hits a success criteria you defined. You're telling the agent: "Here's the task, and here's how you know you've done it right."
That's it. And at its core, what is a loop? It's prompts. It's prompts stacked on top of prompts, run over and over until the task is done.
This is exactly why "prompt engineering is dead" is a misnomer. A loop is a bunch of prompts stacked on one another — kill prompt engineering and you've killed the thing loops are made of. Loops and prompts are both just tools. Discovering a wrench yesterday doesn't mean you throw out the screwdriver. Each has its place, and it's on you to know when it fits the job. You don't need to build a loop for everything. Sometimes you do. Knowing the difference is the skill.
What Are the Four Phases of a Loop?
Every loop has four phases: trigger, execution, verification, and state — and then it loops back and does it again. Get all four right and you have a real loop. Miss one and you have a script that spins its wheels.
Phase 1 — Trigger
The trigger is how the thing gets kicked off. This one's self-explanatory. You've got options: scheduled tasks or routines inside Claude Code, a cron job, a webhook, whatever. It doesn't really matter which. You just need some way to start it, and ideally you want it automatic so you're not the one pressing go every time.
Phase 2 — Execution
The execution phase is where the AI actually does the work, usually in some coding manner. This is almost always best built as a skill. Skills are perfect for telling Claude Code to do a specific thing, in a specific way, to produce a specific output — and the entire point of a loop is a specific output. That's what makes skills and loops fit together so naturally.
Phase 3 — Verification
Verification is really about success criteria: how do you know you actually completed the task? This is the phase everyone talks about and almost nobody handles well.
Sometimes success criteria is dead simple. Take a Python application where the goal is to make it run faster. The success criteria is obvious — it's runtime. You can build a loop that repeatedly tries to reduce that number. Clear goal, objective measure.
But not everything works like that. Say your loop scrapes the web for AI news and turns it into LinkedIn articles, and you want it to write better articles over time. What's success here? Engagement? Is engagement always tied to how good an article actually is? No. That's fuzzy. You can run a loop with fuzzy success criteria, but understand it directly reduces the loop's effectiveness.
Phase 4 — State
State is output plus memory, and it's the real reason loop engineering is worth doing. The whole selling point is that a loop can improve on itself every single run — but only if it can remember what it already tried.
Back to the Python example. If every iteration runs in a silo, blindly trying different things, you've got nothing. The loop needs a document or database it can read: here was the previous runtime, here's what we tried, here's what worked, here's what didn't. Now it knows what to try next. Without a memory of past runs, a loop can't self-improve — it can only guess again.
If this sounds familiar, it should. A lot of loop engineering traces straight back to Ralph loop concepts. The execution phase has to be able to look back and see what it did before, or you'll never get self-improvement in any real sense.
When Should a Loop Stop?
The stop criteria isn't quite a phase, but you can't skip it. When do you stop looping? Sometimes it's clean: you hit the goal, it's verified, you're done. But do you want the loop running forever, chewing tokens until it maybe someday succeeds? Probably not — AI isn't free, and a loop with no stop condition is a bill with no ceiling.
So build in a hard stop. That might be "we're not making progress anymore" — the Python runtime just isn't dropping enough to justify continuing. Or a flat cap: eight iterations, then we call it. Decide this up front.
What's the One Thing That Matters Most in Loop Engineering?
If you get nothing else from this, get this: success criteria. It's the single decision that determines whether a task even belongs in a loop.
If your task has clear success criteria — especially objective, like a number — loops are fantastic. Loop engineering shines. If it's fuzzy, like the LinkedIn article example, maybe it still makes sense, but you probably need a human in the loop or a hybrid approach. Think about this before you start. Because if you don't have a strong goal and clear success criteria, the whole thing is pointless and you're just spinning your wheels burning tokens.
How Do You Actually Build Your First Loop?
There's a hero's journey to loop engineering — four steps, in order. Skipping ahead is how people end up with loops that don't work.
Step 1 — Do it manually. Pull up Claude Code and say "research AI stuff and write me a LinkedIn article." I'm not joking — this literally has to be step one. You need to confirm the task is even possible and the AI can actually do it, hands-on, before you build anything around it.
Step 2 — Codify it into a skill. Once you've confirmed it works and it's something you'll want to repeat and improve, turn it into a skill. Nobody wants to retype the same A-B-C instructions forever. You have a specific outcome and a specific way you want it done — that's exactly what a skill is for. Most people get stuck here, or worse, stall out on step one forever.
Step 3 — Automate it. Now automate the skill. In Claude Code you go into routines, create an automation, and in the instructions just say "run the LinkedIn article skill." Schedule the trigger however you want — daily at 9:00 a.m. Notice what just happened: before you even touched the loop-specific parts, you already solved the trigger phase and part of the execution phase.
Step 4 — Turn it into a true loop. This is where self-improvement, success criteria, and state come in. Your automated skill is probably working, but to make it a real loop-engineered construct you add two things:
- Success definition — how you measure whether a run was good
- State logging — where the results go so the next run can learn from them
For the LinkedIn example, if success is likes, you need a way to scrape the engagement stats, store them somewhere, and then pull out what worked: this hook landed, that one didn't, this CTA converted. That memory is what lets the loop improve. And here's the honest question at step four: if you can define success in some way and record state, you might already have everything you need — some tasks never require the full loop.
What Are the Five Tiers of Verification?
Success criteria isn't binary — there are roughly five tiers, and where you land changes how you build.
- Tiers 1-3 (where you want to live): clear success criteria. Ideally deterministic — a yes/no. Or a rule/constraint you're improving against, like "make the Python app faster." A number like likes or engagement lands around tier three. If you're happy measuring on that number, you can keep the loop fully automatic.
- Tiers 3-5 (fuzzy territory): success requires nuance and judgment. Now you have to decide who judges.
When judgment is required, you've got two options. Option one: LLM-as-judge — but be careful. If Claude Code wrote the articles, do you want Claude Code grading them? Probably not. AI systems tend to love their own work. A better move is bringing in a second model — have something like Codex review Claude's output, so the judge isn't the author. (I've got a whole video on using Codex to judge Claude's work for exactly this reason.)
Option two: put yourself in the loop. This makes it less autonomous and forces the honest question — does this actually need to be a loop? But human judgment can be the most powerful check. With LinkedIn articles: did the engagement reflect the quality, or just good timing and a hot topic? An article can rack up likes for reasons that have nothing to do with how it was written. Do you really want to enshrine that as your gold standard going forward? That's the nuance. There's no perfect answer — it's case by case, and it's going to take experimentation on your part.
How Is This Different From Auto-Research or /goal?
A fair question: why not just use Karpathy-style auto-research, or the /goal command built into Claude Code?
Auto-research is still great — a lot of loop engineering is what auto-research does automatically. But it explicitly requires defined success criteria. It cannot handle fuzzy goals. The Python "make it faster" case is a perfect fit. The fuzzy LinkedIn case is not — auto-research can't deal with it, whereas hand-rolled loop engineering inside Claude Code can tolerate somewhat fuzzy criteria.
/goal is loop engineering in a nutshell — you tell Claude Code to iterate until it hits a condition. The difference is scope. /goal (and Codex's equivalent) lives in a single session: complete this one thing, done. Loop engineering has an infinite horizon — it's almost like running /goal forever, on a schedule, with a self-improvement layer. You can't tell /goal "make me better LinkedIn articles now and forever." It writes one, once, in a silo. If you want it every week, improving each time, that's loop engineering. Bigger picture.
Frequently Asked Questions
Is prompt engineering dead?
No. A loop is literally prompts stacked on top of prompts and repeated with scaffolding. If prompt engineering were dead, loops would have nothing to run on. Loops and prompts are both tools — you pick the one that fits the job.
Does every task need a loop?
No. Loops make sense when you have clear success criteria — ideally an objective number — and something worth improving over time. For fuzzy tasks, or one-off jobs, a single prompt or a /goal run is often the right call. Building a loop for everything is a waste.
What's the difference between /goal and loop engineering?
/goal iterates within a single session to complete one task, then stops. Loop engineering runs on an infinite horizon — triggered on a schedule, logging state across runs, and improving itself each time. Think of loop engineering as running /goal repeatedly with memory.
How do I handle fuzzy success criteria?
Decide who judges. Avoid having the same model grade its own work — bring in a second model like Codex, or put a human in the loop for the judgment call. Just know that fuzzy criteria reduce a loop's effectiveness, so keep the human check where the nuance actually lives.
What's the most important part of a loop?
Success criteria. It determines whether the task belongs in a loop at all and whether the loop can self-improve. No strong goal and no clear way to measure success means you're just burning tokens.
If you want to go deeper into building loops and agentic workflows with Claude Code, join the free Chase AI community for templates, prompts, and live breakdowns. And if you're serious about building with AI, check out the paid community, Chase AI+, for hands-on guidance on how to make money with AI.
