We've all been there. We let the AI run crazy on a problem, only to come back to a complete, sloppy mess. Ralph is especially sensitive to this, because it runs fully head less. There's no human in the loop keeping things on track. If a sub-issue from our PRD isn't implemented the way we envisioned, the model will drift and drift and drift until we are left with unusable AI slope. I hate to break it to you, but more often than not, this is our own fault.

unusable AI slope. I hate to break it to you, but more often than not, this is our own fault. We either didn't describe things thoroughly enough, or we left just enough ambiguity in the implementation details for the model to make the wrong call. At the end of the day, it's not that big of a deal, because we can just discard model output easily and steer or PRD with the learnings from the first loop, but sometimes we know there's ambiguity there. For example , maybe let the model

from the first loop, but sometimes we know there's ambiguity there. For example , maybe let the model define a data structure, a database schema, or an API endpoint. And in these moments, we actually want to step in and confirm or steer the model manually. By reviewing its output, I may be slightly tweaked the direction, so it's back on track. Let me introduce you to human in the loop mode. I slightly tweaked our linear skill. I added the human in the loop tasks,

loop mode. I slightly tweaked our linear skill. I added the human in the loop tasks, and we instruct a model that when a child issue involves an important architectural decision, for example, choosing a data model, we have to prefix a title with human in the loop in brackets. Or Ralph's CLI will detect this human in the loop string, and after completing the task, it will not move the sub-issue to done. Instead, it will move it to in review, and it will do the

it will not move the sub-issue to done. Instead, it will move it to in review, and it will do the same for the parent issue. For this reason, I also introduced a small hook system, and we can configure a human in the loop hook, and we'll just have it play a small sound. I prepared a PRD to add add-ons and modifiers to our menu items, for example, or burger. And let 's quickly glance over the user stories to get a sense of what a PRD is introducing. As a customer, I want

glance over the user stories to get a sense of what a PRD is introducing. As a customer, I want to add topics to my burger so I can get it the way I like. I want to choose a drink size so I can pick the right portion, and I want to see how add-ons affect the price, obviously, before I confirm, and I want to see the customizations list in the cart as well. If you take a look at our child issues, the most important task is going to be the data model definition for our menu,

issues, the most important task is going to be the data model definition for our menu, and that's why the human in the loop label is applied. Let's run Ralph and see what it proposes, but first let's check the version we're running. Ralph's version and the latest version should be 0.12. All right, Ralph is running. Let's make sure our issue is set to to do. We can press S, to do. And now, as you can see, Ralph will pick up the issue. All right, the sound plate,

to do. And now, as you can see, Ralph will pick up the issue. All right, the sound plate, so it's time for me to jump in and review the proposal. As you can see, the issue has been put in review and scrolling down will reveal the proposed customization data scheme. Let's quickly read through this. Each menu item can optionally have customizations. All right, that's fine. I mean, this looks good, but I would like to see an ID being added here. So that's a comment I will make. And other than that, it

would like to see an ID being added here. So that's a comment I will make. And other than that, it looks fine. So I'll just put a comment here. So we can say ID is going to be an unsigned integer. And other than that, it looks fine. And let's reiterate it here, we can say options needs an ID field. It's a number, but unsigned integer, other than that, the proposition is fine. All right, now that we commented this, we can change their issue to do. And before I change the parent, let's also

that we commented this, we can change their issue to do. And before I change the parent, let's also just remove the human in the loop, because I think the model will do fine. We can keep human in the loop there, it will just prompt us again. But I think it'll do fine. So I'll remove that. We can go to the parent, we can put this in to do. And now as we can see, Ralph will continue working on our issue. And as we can see here, it picks up our feedback, the file has already custom

working on our issue. And as we can see here, it picks up our feedback, the file has already custom izations from a previous commit. But per the feedback, each option needs an ID field. I'll add ID to all options, which is exactly what we want. All right, Ralph is done. So it's time to take a look. Let's go into its workspace and run yarn dev. Let's open it up in the browser. And let's take a look at the burger. We can choose our toppings, for example, cheese. And we can choose to make it

look at the burger. We can choose our toppings, for example, cheese. And we can choose to make it veggie. And we see the total update. This is great. Let's add it to the cart. Let's add a soda, open up the cart, and we can see the cheese and the veggie options being selected. The price is looking correct. And so is the total. And this is actually looking great. Let's take a look at the code. And right here, we can see exactly what I was talking about. We kept the model within its

the code. And right here, we can see exactly what I was talking about. We kept the model within its guardrails by putting ourselves in the loop and iterate on the data structure before it went on and built the entire feature. And because we instructed the model to add an ID in the options field, we can now use this ID as a key where we're iterating over the options. Even though our feedback was pretty modest, we only ask it to include an ID. The result here is actually very

feedback was pretty modest, we only ask it to include an ID. The result here is actually very important because otherwise the key would have probably been something like the name, and that would have led to other problems down the road. This way of putting myself back in the loop has proven to be super useful in my day-to-day work with Ralph, and I honestly couldn't live without it anymore. In the next lesson, we'll take a look at how we can run Ralph on a remote machine. Join me

anymore. In the next lesson, we'll take a look at how we can run Ralph on a remote machine. Join me there.