The conversation around loop engineering has completely lost the plot. Every single YouTube video and Xthread has the exact same take. Prompt engineering is dead and you should be doing nothing else but loop engineering.
But the problem is this is not only completely wrong, it's utterly backwards. And that's because a loop at its core is still a prompt. It's just a prompt that we are repeating over and over again with some additional scaffolding.
And loops, just like a prompt, are simply tools. Just because we discovered what a wrench is yesterday doesn't mean we throw out the screwdriver. Each one has their place, and it's on you to understand when they fit the job.
So, in this video, we're going to cut through the hype, and I'm actually going to explain what you need to know about loop engineering, when we should be using them, how to actually build them, and what use cases make sense. So, let's begin by defining loop engineering. Loop engineering is the idea that I'm going to go to cloud code, codeex, whatever agent coder I'm using and I'm going to give it some sort of task.
And instead of just saying here's the prompt, go do it. I'm going to set this up in a way that it is going to complete the task by looping by iteratively over and over again trying to complete this task until it hits some sort of defined success criteria. I'm going to say, "Hey, this is how you know you've done it right.
" And loop engineering is all about setting up this loop in a way that makes it efficient and effective and that it makes sense. That's it. And at its core, what is it?
It's prompts. It's prompts stacked on top of prompts that we do over and over and over again till we complete the task. So the idea that prompt engineering is dead is a total misnomer because at its core, it's just a bunch of prompts stacked on top of one another.
That's it. And the rest of this video is going to be about, hey, how do we actually set up a loop in a way that makes sense to complete these sort of tasks? And furthermore, what tasks actually make sense to be, you know, attacked with loops because they don't always need to be done that way, obviously, which again, it's another hit to this whole like prompt engineering is dead thing.
This isn't a one-sizefitit all tool. We don't need to create a loop for everything, but sometimes we do. So, it's a good thing to know.
Now, every loop has four phases. We have the trigger phase, execution phase, the verification phase, and then state before it loops over and does it again. Now, phase number one is the trigger, and that's pretty self-explanatory.
How are we actually going to get this thing kicked off and started? We have a number of options. We could do things like schedule tasks or routines inside of clawed code.
I can make it a chron job, a web hook, whatever. Doesn't really matter. You just need some way to actually get it started because again, we want this to be automatic ideally.
Phase number two is the execution phase. This is where AI is actually doing stuff for us, usually in some sort of coding manner. But either way, we probably want this to be some sort of skill because skills are perfect for telling Claude code to do a specific thing in a specific way to get a specific output.
And the whole idea of the loop is we're going for a specific output, which leads us into phase number three, which is the goal, the verification. Really this is all about success criteria. Success criteria.
What do I mean by success criteria? How do we know we actually completed this? This is a serious question and one people talk to but then they give you examples where it doesn't make any sense.
Okay. So when we talk about success criteria, sometimes it can be very clear. The success criteria for something like I don't know a Python application and the goal is to make it run faster is very obvious.
Well, it's runtime. Okay, so we could have a loop that over and over again tries to reduce its runtime. That's a clear goal with objective success criteria.
However, not everything is like that. What if we are doing some sort of loop that has to do with like content creation? We or we're trying to create LinkedIn articles.
Okay, part of our loop is we want to consistently go out on the web, find things about AI, turn it into a LinkedIn article, and then over time with this loop, create better LinkedIn articles. Well, how do we create better LinkedIn articles? Do you know what is success here?
Is it engagement? Is engagement always perfectly tied to how quote unquote good an article is? You know, these it's very fuzzy.
So you could have a loop with sort of like fuzzy success criteria, but understand it reduces its effectiveness if that's the case. And we'll talk a little bit more about what we can do if we have sort of again fuzzy goals here that aren't like oh a number that's very clear and obvious that we need to improve upon. And then phase four, what do we got?
We have state. It's the idea of output and memory. Because loop engineering, the real cell for loop engineering is that we can have it improve upon itself every single loop and over time improve upon itself every single run.
You know, think again to the Python idea. Okay, the Python idea where we want to reduce the runtime, right? We we want to make it faster.
Well, what good is the loop if every loop is sort of in a silo and it's just trying different things every time? No, it needs some sort of document or database that it can look at and see, oh, this was the previous runtime. Here's the things we tried to reduce the runtime.
Here's what worked. Here's what didn't. Okay, now I know what I need to try.
Should sound very reminiscent to Ralph loops. You know, a lot of loop engineering kind of goes back on these Ralph loop concepts. So, we need in any proper loop some way to figure out what our output was.
is we need to be able to record it. And for follow-on loops, this execution phase needs to be able to look and see, oh, here's what I did. Here's what worked.
Here's what didn't. Right? That's the only way you're going to make it self-improving in any sense of the word.
And the last portion, which really isn't a phase, but it's part of it, is like what is the stop criteria? When do we stop looping anymore? Now, in some cases, it's like, okay, we hit the goal, it's verified, boom, we're done.
But do you want it to just keep running and running and running and running and running and running and running and running until it happens? Probably not because, you know, AI isn't free. So, do we want to have some sort of like hard stop built in?
Whether that's, hey, we're not getting more progress like maybe the Python runtime just isn't going down enough or maybe we have a hard stop like, hey, we're going to do eight iterations, you know, and then we'll kind of call it. These are the kind of things you need to think about, right? And so while loop engineering, like I said at the beginning, is relatively simple from a theoretical point of view, when we do get into the nitty-gritty of like how we define the phases and engineer these loops themselves, there is some nuance and there is some questions you need to be able to answer.
And that can be a lot to take on all at once and can be kind of confusing. So if you get nothing else from this video, what I want you to think about really is the success criteria. And this will also play into the idea of does this task actually make sense to be part of a loop format.
If the task you have is something that has very clear success criteria, especially if it's objective like a number, then loops are great. Loop engineering is awesome. If that is not the case, if it's fuzzy, again, think of our LinkedIn article thing.
Maybe maybe it still makes sense. Maybe we need to have you more human in the loop at this part. Maybe there needs to be some sort of like hybrid approach.
But that's just something you need to think of it going in because if you don't have a strong goal and you don't have clear success criteria, this is all pointless and you're just going to be spinning your wheels and burning tokens. So just know that going in. If you get nothing else, success criteria.
Think about it. Now before we dive into how you should go about setting up your own loops and your own personal loop engineering, a quick word from today's sponsor, me. So, I just released my Claude code masterass and it is the perfect place to go from zero to AI dev, especially if you don't come from a technical background.
I update this every single week and it also includes a codeex masterass and in a Gentic OS master class. You can find it inside of Chase AI Plus. There is a link to that in the pin comment.
Now, real quickly before we go into your own personal loop engineering sort of workflow, want to talk really quick about things like auto research and also forward/goals because you might have watched everything up until now. I've been like, well, why don't we just use something like Karpathy's auto research? Why don't we just use forward/goals, which is a part of cloud code?
Well, first of all, auto research is still great. A lot of what we talk about loop engineering is pretty much what something like auto research does automatically. The thing is though when it comes to something like auto research it explicitly needs that defined success criteria like we talked about.
It cannot do fuzzy things. We can do loop engineering inside of cloud code with somewhat fuzzy success criteria. Not in the case with auto research.
So auto research with that Python example. We're trying to make it faster. Perfect perfect use case.
But if that's not it, we're not talking about an objective like to the number thing that we're trying to improve. You can't really deal with that with auto research. And when it comes to something like forward slashgoal, forward/goal is sort of loop engineering in a nutshell.
It's you telling cloud code, I want to do this certain thing and I want you to just iterate over and over until you reach a certain condition. The difference between forward/goal and loop engineering at large is that forward/goal, and this also applies to codeex is something in a single session, right? We're going to just complete this one thing and that's going to be it.
Loop engineering is meant to have like an infinite horizon. It's almost like we're doing forward/goal all the time. We're looping forward/goal, right?
There's a self-improvement aspect to it. Again, think of something like this LinkedIn article example. I cannot do a forward/goal that says make me better LinkedIn articles for now and forever, right?
It could try to make me one right now again in a silo a single time. But if this is something that I want to do every single week over and over, that's not what ford/goal is for. Loop engineering is bigger picture if that makes sense and we'll talk about it a little bit more here.
So let's now talk about what your journey should look like when it comes to loop engineering. How should you approach this? You have some sort of task in mind and you want to know, hey, how do I how do I loop engineer this?
Well, there's sort of like a hero's journey here you need to follow. And the first step in our journey is a purely manual process. So example again this LinkedIn article thing.
I want to create LinkedIn articles. Well, what would you do? You would pull up Cloud Code and you would say research AI stuff and make a LinkedIn article for me.
I'm not saying this as a joke. This literally has to be the first step. Why?
Because we need to verify that what we're trying to do is even possible and the AI can do it. Okay, so that's step one. We're actually making sure we can do this manually and we're being very, very hands-on.
Once we've confirmed that we can actually do this and it's something we're going to want to improve upon in the future, well, we're going to codify it. So step two becomes turning it into a skill because nobody wants to sit there and say, "Hey, do all A, B, and C over and over again. I have a specific outcome I now have and I want to do it in a specific way.
" So we would turn this into a skill. That's step two. And again, this is where kind of a lot of people sit.
Unfortunately, a lot of people really just sit on step one forever, which is manual. So we validated the process. We've codified it into a skill.
The next step is actually just to automate it, right? We just want to automate the skill because I'm so lazy. I don't even want to write for/in article.
I want it just to do it on its own. Now, this is pretty easy to do in something like Claude Code. We can go into routines.
We can set up an automation called LinkedIn article. And in the instructions, we can just say run the LinkedIn article skill, right? Uh description, run the skill.
And hey, we're already going to figure out the trigger. We just schedule it however we want. We're going to do it daily at 9:00 a.
m. And so before we even really got into the loop engineering part, we've sort of already figured out the trigger and kind of done part of the execution. So if we then want to go from this automated skill into a true, you know, loop engineered construct.
Well, what are we going to need to do now? Well, now we need to think about self-improvement. We need to think about success criteria.
And we need to think about state, right? What is the definition of success? How are we going to record and therefore improve upon it?
So when we're at step three, we're now thinking about this entire second half. And so moving up here, this skill is probably working, but we need to add some things to this skill before we move on to step four. And so what are we going to add?
Well, we need to add the success stuff we talked about, right? And we also need to add some sort of like state logging. Again, state logging.
What am I saying? Where is this information going? Sure, you posted to LinkedIn, but are you able to scrape the engagement statistics?
Because let's say we say success is defined by engagement statistics. We'll just say likes. Well, we need some way to harvest those likes, see what the metrics are, and then we need to put them somewhere.
And it is by that that we can then further improve upon the stuff and pull out hey here's what worked with this article here's what didn't this hook was good this hook wasn't bad this CTA worked etc etc so while before the original step 1 2 and three we didn't have that if we want to move on to step four which is loop engineering what do we need we need these two things and this applies to anything you do right and now comes the question at this point well do we even need step four if you can define success in some way. Even if it's sort of fuzzy like this and you have a way to record state, then you're going to be okay. Now, let's talk about the success criteria a little bit more because I think there's sort of like five tiers of verification here.
First three are kind of where we want to live and this is like, hey, you have success criteria that's very clear, right? Ideally, it's deterministic. It's like a yes or no.
Like, that's perfect. Or there's some sort of like rule or constraint, right? When we talked about the Python application running fast, well, that's sort of like a rule or constraint.
we're trying to improve upon. But if we don't have those and we're kind of in like tier three through five where again it's fuzzy, this is where you need to start thinking, how do I judge the success? Now, if we have something like likes or engagement, that is a number and that kind of puts us in number three, right?
And if you're happy with that, you can continue to make this completely automatic. But if there's something that does require some nuance and judgment in terms of what is good, you need to have like kind of a discussion between you and yourself and probably Claude code of like, okay, are we going to have the large language model as the judge, right? If Claude code is the one who is writing the articles, do we want Claude code to judge the articles?
The answer is probably not. You may want to create something in your loop where something like codeex comes in and takes a look at it. Like I have a whole video on things like this where we use codecs to sort of judge cla's outputs cuz remember one of the issues with cloud code and really all AI systems is they tend to really like their own work.
So anytime you're like, "Oh, I'm going to have the AI judge something in my loop. " Be careful, especially if it's subjective. The other option you have is you bring in you into the loop.
Now, this makes it less autonomous, and this is where you begin to question, does this actually need to be a loop? But it might make sense. There are scenarios where we need some sort of human intervention and this can be the most powerful, right?
Especially in our example of like LinkedIn articles like was it good? Did the engagement make sense for the topic I spoke on? You know, you can have an article with tons of engagement and it can have nothing to do with the quality of the article.
It was just the timing and the subject that worked well for you. And it's like, do we want to necessarily pull, you know, the information about how we wrote said article as like this gold standard for things going forward? Again, a lot of nuance.
There's a lot of nuance. You know, these are the decisions you need to make. And this is what is going to define if your loop is engineered correctly or not.
And there's no perfect answer here as well. This is all case by case and it's something that's going to require experimentation on your part to figure out. But for our example for now, we're going to say, okay, we're going with likes.
That's good enough for us. If it has a lot of likes, we're saying that's a good article. And that's what we're going to base this all on.
So, when we look at our loop now, we have a trigger at 9:00 a. m. We have an execution via a skill.
We've defined our goal as getting the most likes as possible. We're able to verify this with some sort of scraper, and we're able to put all this into some sort of database that records the article with the amount of likes. Now, this will then loop essentially every day at 9:00 a.
m. Now, you might notice some issues here right away because with this thing, this isn't going to just be one loop, is it? because there's going to be a delay between hey when I write the article to where I get likes.
So there's also going to be a delay for how well this actually works in reality. We're going to have to wait some time and build a database of actual data showing our articles and likes. For this video, let's pretend we've sort of been running this for like a month and we already have a treasure trove of like here's articles I've written with the likes.
So the idea would be at this point every morning at 9:00 a. m. we get the trigger the skill executes.
It looks up things for AI and it begins to write the article. Now what it's also going to bring in isn't just AI news, right? It's now going to look at that database of previous articles and previous likes and sort of do some analysis like what's been trending lately, what did we try in terms of hooks, what was our CTI, CTA, etc.
, etc. It will then bring in that information into its execution and that would be all baked into the skill. That's sort of the self-improvement part.
From there, a it sees what it did. It records the likes. Boom, boom, boom, boom, boom.
In reality, you would also have a second loop running outside that just like scrapes the likes every, you know, 24 hours and make sure it's updated. And you can see right away this sort of fuzzy thing with the likes does increase the complexity of how we engineer our loops versus something as simple as like, hey, I want my Python app to be faster. Okay, well this triggers, you know, every 10 minutes it runs the app.
We want the we want it to be faster, so it checks the time. It has a some sort of handoff doc that has the times with the code changes, right? Right?
We could just have the diff there and then it just keeps running over and over and over and over again. Right? And it changes the code each time to see if it lowers the time and sees what diffs work.
So all that to say, if you have clear success criteria, loop engineering becomes much much easier. And hopefully this thoroughly confused you at this point. Um, but I thought it was good to kind of go through this sort of like LinkedIn chaos fuzzy thing because truth be told for a lot of people who use cloud code and want to do these loops, they actually tend to be in this place more often than not.
Um, and sort of this fuzzy area. Not everything is clearly defined as, you know, something you can throw into auto research. So that is loop engineering in a nutshell.
We have a trigger. We're going to execute via skills. It's all about our goals and can we verify our success?
And then we're logging everything all the time so that this becomes a self-improving loop. And ideally at the execution phase with that skill, it needs to be looking at its previous state and figuring out, okay, what have we tried? What do we still need to try?
What's worked? What hasn't? So, that's where I'm going to leave you.
As always, let me know what you thought of this video. I think it's a super interesting topic, but don't get lost and confused by everyone saying prompt engineering is dead. That is not the case.
And make sure to check out Chase Plus if you want to get your hands on my Claude code masterass.
