Chase AI argues that the popular framing of "loop engineering" has lost the plot. The claim that prompt engineering is dead and that you should only do loop engineering is, in his view, backwards. A loop is still a prompt. It is just a prompt repeated over and over with some additional scaffolding and a defined success criteria. Loops and prompts are both tools, and the discipline is knowing when each one fits the job.
The video defines loop engineering as giving an agentic coder (Claude Code, Codex, or similar) a task and setting it up to complete that task by iterating repeatedly until it hits a defined success criteria, in a way that is efficient, effective, and sensible. It then breaks down the four phases of any loop and a four-step journey for turning a one-off prompt into a self-improving system.
Instead of saying "here is the prompt, go do it," you set the task up so the agent loops iteratively until it meets a success criteria you define ("here is how you know you've done it right"). At its core it is prompts stacked on top of prompts, run over and over until the task is complete. That is why "prompt engineering is dead" is a misnomer: the loop is built out of prompts. It is also not a one-size-fits-all tool. You do not need a loop for everything, but sometimes you do, so it is worth knowing how to build one.
Every loop has four phases, plus a stop condition.
How the loop gets kicked off and started. Options include scheduled tasks or routines inside Claude Code, a cron job, or a webhook. The mechanism does not matter much; you just need some way to start it, ideally automatically.
Where the AI actually does the work, usually in a coding manner. This should typically be a skill, because skills are perfect for telling Claude Code to do a specific thing in a specific way to get a specific output, which is exactly what a loop is aiming for.
This is all about success criteria: how do you know you actually completed the task? Sometimes this is very clear. For a Python application where the goal is to run faster, the success criteria is obviously runtime, an objective, measurable target. But not everything is like that. A loop that finds AI news and writes LinkedIn articles, aiming to create "better" articles over time, has fuzzy success criteria. Is success engagement? Is engagement even tied to quality? You can run a loop with fuzzy criteria, but understand that it reduces the loop's effectiveness.
Output and memory. The real value of loop engineering is that the system can improve on itself every run. For that, each loop needs a document or database it can read to see the previous result, what was tried, what worked, and what didn't. Without state, every loop runs in isolation and just tries different things blindly. This echoes the Ralph loop concept: record your output, then have the next execution read it to decide what to try next. That is the only way the loop becomes self-improving.
Not strictly a phase, but essential: when do you stop looping? Sometimes you stop when the goal is verified. But you should not run forever, because AI isn't free. Build in a hard stop, such as "we're no longer making progress" (the Python runtime stops dropping) or a fixed cap like eight iterations.
If you take nothing else away, focus on success criteria. It also determines whether a task even belongs in a loop. If the task has very clear, ideally objective success criteria like a number, loops are great. If it is fuzzy (the LinkedIn example), maybe it still makes sense, but you may need a human in the loop or a hybrid approach. Without a strong goal and clear success criteria, the whole thing is pointless; you will just spin your wheels and burn tokens.
If you can define success in some way (even fuzzily) and you have a way to record state, you are in good shape, and you may not even strictly need a separate "step four" beyond these additions.
There are roughly five tiers of verification. The first three are where you want to live: clear success criteria, ideally deterministic (a yes/no), or a rule/constraint to improve upon (like Python runtime). A number like likes lands around tier three. The fuzzier tiers (three through five) force the question: how do I judge success?
There is no perfect answer; this is case by case and requires experimentation. These decisions are what determine whether your loop is engineered correctly.
For the LinkedIn example, settle on "likes" as good enough: trigger at 9am, execution via a skill, goal of maximizing likes, verification via a scraper, and state stored in a database that records each article with its like count. The loop runs daily at 9am.
Reality adds nuance. There is a delay between writing an article and getting likes, so in practice you run a second loop that scrapes likes every 24 hours and keeps the database updated. Once you've accumulated a month of data, each 9am run does more than fetch AI news: the skill also reads the database of past articles and likes, analyzes what's been trending, which hooks and CTAs were used, and feeds that back into execution. That feedback is the self-improvement.
By contrast, the Python "make it faster" loop is simple: trigger every 10 minutes, run the app, check the time, keep a handoff doc of times and code diffs, and keep changing the code to see which diffs lower the runtime. The lesson: clear success criteria make loop engineering much easier; fuzzy criteria add real complexity.