Stop Using Ralph Loops (Use This Instead)

You need to stop using Ralph loops. The Ralph loop hype is everywhere right now, and that's not without good reason. The actual Ralph loop fundamentals are actually really solid.

Things like context window management, atomic tasks, and persistence until completion are all things we should be trying to incorporate into our cloud code workflows. But there are a lot of things people aren't telling you about Ralph loops. >> I'm in danger.

First of all, most people aren't even using the correct type of Ralph loops. That Ralph Wiggum plugin you have in Claude Code, yeah, that's not a real Ralph loop. And I actually did a whole video on that topic.

Secondly, as the creator of the Ralph loop stated himself, Ralph loops are simply a technique. At its most base form, it's just a bash loop and it's one piece of a larger puzzle when you are trying to create projects. And importantly, that piece, the loops, is entirely dependent on everything that comes before it.

How good is your product requirements document? How tight did you define your features? How do you know what done actually looks like?

If the answers to those questions aren't exact and correct, then you're just going to get stuck in a garbage in garbage out scenario, no matter how many times your loop runs. The Ralph Loop is an extremely powerful weapon, but most of us don't need a weapon. We need the entire armory, and that's where GSD comes in.

While Ralph Loops assume you show up to the session with your entire blueprint ready to go, GSD actually helps you build it. GSD takes your half-baked idea, asks you deep questions about it, does research on your behalf, fleshes out a full-blown PRD, turns that PRD into atomic tasks for the AI to execute, and then completes the project from end to end. And while it's executing the code, it's using many of the same fundamentals that makes the Ralph loops as strong as they are.

Namely, context window management using sub aents and the idea of giving AI as small and discreet of tasks as possible. so we always get the best output. So in this video, we're going to dive into GSD.

I'm going to show you how to set it up. I'm going to show you what this framework actually buys you. So hopefully you can give it a test run in your next Cloud Code session.

So here we are inside of the GSD GitHub repo. What we're going to do now is we're going to run through the repo so I can quickly explain big picture how the system works in conjunction with Cloud Code and then we'll actually hop into Cloud Code and play around with it for real. So first of all, how do we install this thing?

Really easy. Just this one line of code in the terminal. MPX get done CC.

Next question should be, well, how do I actually interact with this guy? Well, it uses slash commands. So, for example, if I wanted to start a new project with GSD, I would just do forward slashgsd new project.

Or if I already had code that I wanted it to work on, I could do something like for/gsd map codebase and it would take a look at all the code already in there. So, that's how you interact with it inside of cloud code. Now, you're probably asking, okay, how does it actually execute code?

How does it take my idea and create a working application? Well, Tash, the creative GSD, breaks it down into six steps. Now, the first three steps are initialize project, discuss phase, and then the plan phase.

Think of these first three steps as essentially your standard clawed plan mode on steroids. So, at the beginning, what do you do in the initialized project stage? Well, you just give it your idea.

It's going to ask you questions. It's going to do research on your behalf. And this is where you're getting your like PRD, right?

Your product requirements document. What is it you're actually trying to build big picture. And in this space, it creates four documents that have to do with sort of context.

So Claude always knows what you want to build, what the technical requirements are, and then what has it created and what still needs to be created. And I will show these in action in a little bit. After that, you move into the discuss phase and the plan phase.

And this is where you go from your general PRD and you get really really detailed with like, okay, but what do you actually want? And this is where you have the ability to go from just sort of your random or your average quote unquote AI slop and really, as Tash states it, shape the implementation. And so you continue to have this back and forth with GSD and it continues to do research on your behalf to marry your idea with the technical requirements with what is actually possible.

So as you can see there's really half of the steps here are all about just making sure your idea makes sense because the idea A needs to make sense and B needs to get broken down all the way to a handful of atomic tasks, right? very very small discrete tasks that the AI can execute on your behalf and it also verifies all this. So it's going to check the plan against the requirements in loop until they pass.

Right? Starting to see some Ralph lloop fundamentals at work there. And so once we've planned everything out then we go into the execution phase.

Now this is where again we see a lot of Ralph flu fundamentals because what's going to be happening here? Well, it's going to run plans and waves in parallel when possible. But really what you see is a fresh context per plan.

Now you should probably understand at this point what context rot is. It's the idea that as a context window fills up right the more we interact cloud code the worse the outputs get. And autocompact only solves that so much.

So what this does and what also Ralph loop does is it starts a new session in the form of a sub agent in GSD's case to actually execute the code to create the code. So for atomic task one, it's going to spawn a new sub aent. That sub aent is going to have fresh context to do it so we get the best output possible.

And it does this for every single task. And each task also gets its own commit. From there, it moves on to step five where it's going to test to make sure the code actually works.

And oftent times it's going to bring you in the user to actually go in and say, "Hey, is this working as expected? " And lastly, step six, we just repeat this process over and over until we get what we want. And so the GSD loop essentially becomes discuss, plan, execute, and verify.

And all along the way, we're bringing in the idea of fresh context windows and very small tasks to make sure the best output is brought to us. Now, I suggest hopping in here and taking a look at this GitHub. It talks about a lot of other cool features like quick mode if we're trying to execute something that's small and isn't like a really heavy lift.

And then it also goes into like all the different slash commands at your disposal. So I'll put a link to that down below. So now let's go through a quick demo.

So to install it, you'll spin up a terminal and you'll just do npx get done ccc. Now what you'll want to do almost every time you use this is to update it after you've installed. So, it's the same thing and then it's at latest because uh this guy's kind of a maniac and does like a 100 commits a day.

So, yes to proceed. And then would you like to install this globally or locally? You most likely will want to install it globally.

So, you can use it in any project. And there you go. Uh what is the new one?

Your current. Yep. Let's replace it with the new status line.

So, here we go. Then once you install it, all you're going to do is start up Claude like you normally would. In my case, I'll be doing the skip permissions.

So now we're zoomed in so you can hopefully see this a little bit better. So if I do forward slash, you will notice I then get, you know, a ton of these GSD things pop up. So let's say we're starting a new project.

So it's just going to be GSD colon new project. Hit enter. So it's then going to start asking you some questions.

So what do you want to build? I just told it I want to create a content creation remixer. So I give it some idea or an article and then it turns it into a 30 to 60 second content script.

Simple enough. Now depending on how thorough your first answer was or as vague as it was like our first one, it's going to continue to ask you more questions to get a better idea of what it actually needs to build. Once you get through the initial project scope questions, you'll be hit with a question that says, "How do you want to work?

" Whether it's YOLO or interactive, I suggest YOLO. It's going to make it way quicker. And then it's also going to ask you, hey, how thorough should the planning be?

Standard is just fine. You can always add more plans later if you want to. When it asks you, do you want it to run plans in parallel?

Understand it's only going to run plans in parallel if that makes sense because certain things do have to be sequential. But for the most part, having it execute in parallel is just going to save you time. And then in do you want to commit planning docs to Git?

Again, this just depends on what sort of version control you want. Now, one of the last questions it will ask before it actually starts jetting up some of these documents is which AI models do you want to use for planning agents. So, this kind of depends on your Claude code plan.

I suggest quality if you're on a max plan. That way, you're using Opus for everything. But understand there's a balance and a budget if you're on the pro version or if you're really um conscious about bumping up against your limits.

Next, what you'll see after answering all those questions is the proposed road map. So you can see right here it broke it down into five phases and eight requirements. So in phase one is the foundation and this is where we sort of do the full stack skeleton.

From there is the input pipeline with URL scraping and text inputs etc etc. Then it gets a little more detailed in terms of how it breaks down those phases and you can see here it breaks out the success criteria and the goals. So now I've zoomed out a little bit and over here on the left you can see that it's now created those four documents that were referenced in the GitHub repo.

Project requirements roadmap and state. Now the project document is pretty much a product requirements document, right? A pretty broad overview of what it is we're building.

The requirements gets a little bit more technical in terms of like the actual features. So for example, if we look at the input requirements, what sort of inputs do we need to give this content remixer for it to be able to remix said content? So for there I should be able to paste a URL.

I should be able to enter a raw idea. And I also want to be able to select from template presets. The road map again is a little more detailed because now we're going into the exact phases, right?

We have this into I believe five phases. And it also shows the explicit success criteria. And then we have the state document.

And this is a living document where you can always reference as you're building what has been built so far and what we should expect to be built down the road. Now it transitions into the phasebyphase execution. So it's going to discuss the phase, right?

Really make sure we're on the same page with what is going to be built here in this case in the foundation and then it's actually going to create the code. So it tells you exactly what to do. So it's going to be for/gsd discussphase 1.

But first, right, it's saying, hey, clear it so we can actually run it. So I'm just going to go clear, paste it in, and it's going to start executing. After the discuss phase, you move to the plan phase.

And this is where it's actually going to set the tasks AI is going to complete because everything you've done before this is all about making sure you and the AI are on the same page and that it's going to build what you want. So, it gives you a few options. Either you can do a normal plan phase, in which case, if it makes sense, it will do some additional research, or you can also just skip the research if it's something very basic.

So, after it completes that step, we're then going to finally make it to the execution phase of GSD. So you'll see something that says like next up execute phase one and then it will give you these commands. Now what you will also see over here on the left is we now have phases and in this case you can see phase 01 foundation and over here I have plan 01 01 and 0102.

So it's broken down phase one into two subphases and if I click into each plan I can see what it's actually going to do. For all intents and purposes, these plans are like the prompt that it's going to be giving Claude code. So, it can actually build what we need to build.

So, if we look through this, it's an XML. It's about 200 lines of code. And you can see right here, what is the objective of this particular plan, right?

Well, we want to bootstrap the content remixer project with Nex. js 15 and establish a database, right? We're creating the foundational infrastructure that all subsequent phases will build upon and we have a clear output that we're trying to get to.

It includes the specific context of other files it needs to be looking at as it executes this phase. And then we can see here in the task section the specific atomic tasks that we keep talking about that it's going to go ahead and do, right? We're not just telling it, hey, create this whole app for us.

We're saying, hey, task one, create the next. js project with dependencies and it goes all the way down the list doing it. And I definitely recommend that even if you consider yourself a vote a quote unquote vibe coder that you go through these plans and sort of familiar familiarize yourself with what it's building and ask cla code questions if you are confused at any one point.

But at this point of the video, you should start to see like how methodical this entire GSD process is to get us to this point over and over and over. The next step that we're going to do, it's actually going to create the code based on this. But it's a lot of steps before you get to this point.

And that's what I am sort of referencing when we compare this to Ralph Loop being a weapon and GSD being the whole dang armor and all this scaffolding to handhold you to get you to this place where it's going to execute something well. And so we're going to go to execute phase one. We'll clear this and we'll come back once it's complete so you can see what a finished phase looks like.

Okay, so it executed phase one and here's the sort of messaging we see. It says it did wave 1 and wave two complete. So those were essentially the subfases within phase 1 which was the bootstrap Nex.

js project with the database as well as the OpenAI integration. So it can actually in uh actually remix our content with AI. So now it will verify if the goals were met on its own.

But what it's also going to have you do is actual human verification checklist. So, it's telling me open up new terminal, do npm rundev, make sure it actually works, do the database migration, and then actually check the OpenAI endtoend testing. Now, this part I really like, and this is where it differentiates a little bit with the Ralph loop.

The Ralph loop is very like hands-off a AFK, like it's going to just go forth and conquer versus this. After every single phase, there's pretty much some element of human verification. So, you can actually see it with your own two eyes and then make adjustments accordingly.

And this as I stated before methodical way of implementing tasks is where GSD shines. So in terms of end toend stuff complicated projects I'm starting from you know zero and want to go all the way at the end. I think this is the perfect place for GSD.

I think when you compare that to again Ralph loop which is what we sort of been contrasting with it right loop is a technique. So there are instances especially I think if you're a little more advanced and maybe the scaffolding and structuring of something like this framework is a little too much for you. I think that's where it really really shines where you're already at the place you're like I know exactly what I want and I know exactly what needs to be done.

I think Ralph Lip is great for that. I think for other cases and I think for most people in the space something like GSD just makes a bit more sense. Now there are some cons, right?

And something you probably notice right here, like 22 minutes and 18 seconds. This is, as I keep saying, methodical. It takes a little bit of time.

We are not in the game of just trying to oneshot things as quick as possible. Also, in terms of sub agents, that does use a bit of tokens. The argument for that is is that in the long run, you're actually saving tokens because you're doing, you know, a plan twice, prompt once thing versus just prompting, going, and then having to fix things on the back end.

So, just know that. going in. So, at this point, you would just repeat this process for every single phase until your project was complete.

So, that's where I'm going to leave you today. I hope I was able to introduce you to a pretty cool and upand cominging claude code framework in GSD. I've really enjoyed it.

I think it's perfect for people who don't come from a technical background, but still want to make projects end to end inside of Cloud Code in a way that's sustainable and repeatable and really checks all the boxes.