All right, so the worst has happened. I have a bug and now it's time for vibe debugging. If you look on x.com, you can see that this is a constant meme. People make a lot of memes around vibe, debugging. They make little comics, they make stupid little images, uh, looking haggard and old abi before and after vibe. Debugging, vibe debugging is very difficult. Vibe. Building vibe coding is super fun. When you get to the debugging step, it usually means,

Building vibe coding is super fun. When you get to the debugging step, it usually means, the thing that people are referring to here is that you ask the LLM to fix something and it doesn't, and then you ask it again and it doesn't, you ask it again and it doesn't. There's a sort of spiral that happens in debugging that happens to be clear to software engineers when we're writing code by hand and we're trying to find a bug,

to software engineers when we're writing code by hand and we're trying to find a bug, it is very frustrating when we can't and we go through multiple things to try it, but there's more control in that process. You make a list of things that it might be you start to work through them in debugging with vibe coating, it's more just like banging your head against the wall and begging the LLM to fix it and you feel like you have very little control.

and begging the LLM to fix it and you feel like you have very little control. I can give you some of the tips that I use to get over this problem. Five debugging is, it doesn't have to be as bad as everyone says, but it's not going to be fun. I guarantee you that. What you need to do is take on that software engineering role hat again, and think about how you solve problems with code, how you solve problems yourself,

and think about how you solve problems with code, how you solve problems yourself, and then you can sort of guide the LLM again, treat it like a junior engineer and try to coax it back. There are a few things that I, I wanna focus on. So this is the thing that I wanted to, to build. If I go into Winder and I start a new generation, then it's going to make a little website for me. So I asked it to make a coffee shop website, and if you see

to make a little website for me. So I asked it to make a coffee shop website, and if you see after it's done, it's going to resize, which is good. This is the new feature that I built, it resizes so that, uh, I can see all of the content. I had to do that manually before. I like that. Now the problem is when I say make the image at the top, a latte watch, it's going to get short. So I don't know why it's getting short. I don't want it to get short.

So I don't know why it's getting short. I don't want it to get short. So this is the bug that you and I are gonna fix together, or at least I'm gonna show you some tricks that I use and we'll see if we can solve it. Um, first we'll go through the tricks and then I'll see what works and then report back. So jumping over to Cursor, this is where I am in the process. I have run all the prompts to build the feature

this is where I am in the process. I have run all the prompts to build the feature and it had some issues and so I explained it resizes correctly, but if I run another prompt, it goes back to being short. And this is the key, this is the most important thing I want you to understand, is that it went through and it wrote a bunch of code to fix this bug and as we just saw, that code did not work. And so this is the grave mistake

and as we just saw, that code did not work. And so this is the grave mistake that I made when I first started Vibe Coding, and it's the mistake I bet you make too. It's that since it didn't work, I'm going to just go in here and say, Nope, didn't work, try again, or something to that effect. I'm gonna say it still doesn't work. Now, what is the problem with that method? I can tell you the problem is that it already wrote a bunch

Now, what is the problem with that method? I can tell you the problem is that it already wrote a bunch of code to fix that problem and it thinks that it fixed it, but I'm telling you it didn't. Now that begs the question, well, what about all that code that it just did? It changed a bunch of stuff in my application for no purpose whatsoever because it didn't work. I now have a bunch of junk code in there, and this is where vibe coding spirals out of control.

I now have a bunch of junk code in there, and this is where vibe coding spirals out of control. This is the most dangerous part of vibe coding to me. Aside from performance and security concerns, like the most typical part where the whole thing falls apart, people give up is because you start filling your code base with just awful, awful code because every time you tell this thing that didn't work, try again. It gets more and more desperate. Now, that's me projecting.

that didn't work, try again. It gets more and more desperate. Now, that's me projecting. It doesn't get desperate, but it just starts trying a whole bunch of random stuff and it fills your code with just slop. It is awful. It is no good. It will ruin your code base. The most important thing that I can tell you to do is to undo. Cursor has these great things like called checkpoints, and I'm going to roll that back so that all that code that it wrote to fix that bug is now gone.

and I'm going to roll that back so that all that code that it wrote to fix that bug is now gone. That is the most important thing you wanna do because again, it's spiraling out of control and you're just gonna continue in that loop to say, fix the bug, fix the bug, fix the bug. And every single one of those is gonna start to put junk code in there, junk code in there, junk code in there. Pretty soon your code base is just more junk

junk code in there, junk code in there. Pretty soon your code base is just more junk code than good code. All those bug fixes that you tried to do are still hanging out in there even though they didn't work, which is awful. That's something that you wanna do. Another thing you wanna do, we talked about this before, you're gonna know what I'm gonna say, but I have already used 75%

before, you're gonna know what I'm gonna say, but I have already used 75% of my context for this conversation. What does that mean? It means that the performance of the LLM is way down. It is already overwhelmed. It is on a, a human engineer would be frustrated and tired and needs to go to bed and get some sleep. My LLM needs that and to do that, I need to start a new agent.

My LLM needs that and to do that, I need to start a new agent. Now, that's another thing that I can do. Um, in order to kind of refresh the context, make sure that the uh, that sort of context rot that we talked about, that golden rule in the first video is not happening. So from there, after I start a new chat, you know what I'm going to say, use the explain method, have it explain how the functionality currently works. We already know how to do that.

have it explain how the functionality currently works. We already know how to do that. And then if that doesn't work, what do you do? Let's jump into a couple of prompts that I use to see if I can get us out of this. Okay, so we're back with Vibe Coding prompts. Number one, I already have gone in here. I've made a new chat. I've done a branch diff with made branch trick that we learned in a previous video. I asked it to explain the code.

with made branch trick that we learned in a previous video. I asked it to explain the code. So I did the explain method already and now I have explained the bug in here, but this is the, the part that is new. This is the trick. Analyze how the resizing logic works step by step and see if you can spot why it shortens the art board height during the streaming step. That should not happen. Don't fix it.

during the streaming step. That should not happen. Don't fix it. Just try to identify the problem. Now, the reason that I did that is because again, it's all about creating that context where it can spot the problem. So I wanna create the context where it's one, not trying to write new code to solve the problem, but two, that it's just analyzing that it's writing through the logic step by step.

but two, that it's just analyzing that it's writing through the logic step by step. This is what I would tell a junior engineer to do. Think through how the logic works, track it down, try to see if you can find the mistake, and then it's going to come in here and it is at least going to try to see if that works. Now, I don't know if it's going to work. We're gonna skip to the next tip. We're gonna try a couple of these and we'll see,

We're gonna skip to the next tip. We're gonna try a couple of these and we'll see, and I'll report back on which one works. But right now let's just focus on the trick. So this one is to explain the logic step by step. Ask it not to fix it, but just to do the explanation and see if it can spot where the logic problem is or the bug, whatever bug it is you're trying to fix. Just make sure that it explains how everything works and then see if it can spot the problem.

Just make sure that it explains how everything works and then see if it can spot the problem. Okay, prompt number two. Here it is. The resizing works On my first prompt, there's a bug where five prompt, again, yada, yada, yada. Come up with a list of things that might be causing this and rank them by how likely they are to be the cause. Don't change anything yet, just make the list. And I could be doing ask mode. It doesn't matter. Like if you tell 'em to change anything,

And I could be doing ask mode. It doesn't matter. Like if you tell 'em to change anything, it doesn't usually do it in agent. So you can use ask mode or you can do this, it's totally fine. But the key here is that not only have I told it not to fix anything, but I haven't rank the issues. The reason for this is that what I find is that if I run a prompt again and again and again, what it does is it typically

that if I run a prompt again and again and again, what it does is it typically finds the same answer. And so I wanted to go through the exercise of thinking about that answer and not getting stuck. Remember we learned before that l lms, when they make a wrong turn, they don't turn around. That has been shown in research. They never recover from that wrong turn, and they sort of get stuck on this is the problem,

They never recover from that wrong turn, and they sort of get stuck on this is the problem, this is the problem, this problem. Even if you tell 'em that's not the problem, they'll kind of still get stuck on it. But I found that if you allow them to list out the things, sometimes they actually do move past it because it's like, I don't know, it got out of their system. Like the tokens were allowed to, uh, finish that thought and it's out there and sometimes they can find another thing

Like the tokens were allowed to, uh, finish that thought and it's out there and sometimes they can find another thing that's wrong and then you can tell it, okay, pursue this one. I know that one's not the cause so let's pursue some of these others. And so here I've asked it to list out all the things that are likely and then rank them by that, which is most likely. And so I find that this often works.

which is most likely. And so I find that this often works. This is kind of my go-to. I I use this one a lot because, um, I wanted to think about all of the possibilities and then we'll go after them one by one. Another trick that I have isn't a prompt, but it's simply to use a different model. Now, if you go in here under the model switcher, think

but it's simply to use a different model. Now, if you go in here under the model switcher, think of these as your team of software engineers. If you just keep hitting that same engineer with the same problem over and over, they might be at the end of the rope. It is possible that they just don't know the answer, and it's possible that that LLM or that model is not going to get to the answer. And so I often reach for a better model.

or that model is not going to get to the answer. And so I often reach for a better model. The thinking models do give it more time and more tokens to think through the problem. Those are your go-to for cases like this. If you can afford them and you have access and you haven't hit your limits, use the thinking models. Any thinking model that you have in here is probably pretty good. I've been having a lot of luck with GPT five in this course.

here is probably pretty good. I've been having a lot of luck with GPT five in this course. I think Gemini 2.5 Pro is really good at thinking through problems. I just find again and again and it's good. And I will admit that there's a reason that I have Claude 3.5 sauna in here. Sometimes when these models are overthinking, they actually think too much and all the modern models come up with the same problem.

they actually think too much and all the modern models come up with the same problem. And I'm just banging my head against the wall. This sounds crazy, but I promise this is a little bit of a magic model. Sometimes Claude 3.5 sonnet, not four, not 3.7, but good old 3.5 sonnet on an issue where the LMS are actually overthinking and thinking too much. This model doesn't do much thinking.

overthinking and thinking too much. This model doesn't do much thinking. It doesn't, it's not a thinking model, so it doesn't do it at all, but it also just doesn't churn out as much stuff as modern models. And so I find on tasks that are relatively simple that a really complex, super modern model is actually completely falling down on. I promise there's some magic in three point fives on.

super modern model is actually completely falling down on. I promise there's some magic in three point fives on. It's a good model. So try switching to that even in your, in your flow. So basically remember what I said about redoing your checkpoint. So don't just go through this without redoing your checkpoint. Run your prompt, see if it fixed the bug. If not, undo the checkpoint switch models.

Run your prompt, see if it fixed the bug. If not, undo the checkpoint switch models. Maybe tweak your prompt a little bit and then try again. Okay, we're back with one more tip. Uh, this is a very common one. If you're a software engineer, probably don't even need to tell you to do this, but in this one I said add some logs that will help us spot what's growing wrong. And when you know how this works, you're gonna fill up your console with logs.

And when you know how this works, you're gonna fill up your console with logs. You're gonna try to track 'em down. But instead of looking at those logs and trying to track it down yourself, you're going to screenshot those logs or copy and paste them into the LLM and let it know, Hey, this is what's going wrong. Don't discount this. The one, the l LMS love doing this. So they'll probably do it on their own, but if you can help guide them

So they'll probably do it on their own, but if you can help guide them and then try to steer them toward a, a good logging system or exactly what you wanna know, that helps. And usually this helps spot the problem. If, if you can just feed it right back in, then it has more information on what's going wrong and where, and it can usually fix the problem. Now, the thing that it never does, I don't know why, but it never cleans up the logs.

Now, the thing that it never does, I don't know why, but it never cleans up the logs. So you do have to tell it when you do this trick. After it's done, after it's fixed, tell it to clean up the logs because it just leaves it a mess. And you often find with vibe coders, if you look at the console at any given time, it has a hundred logs in there for past debugging sessions that they have. So remember to clean up your logs just

for past debugging sessions that they have. So remember to clean up your logs just to finish out the video properly. I was able to fix the bug. Here's what I did. I explained the bug and then I said, this is a brand new chat. Again, I use the explain method to have it explain the difference. What I did here is I said the analyze method. So I said, analyze what happens

What I did here is I said the analyze method. So I said, analyze what happens during the streaming phase step by step and see if you can spot why it shortens the aboard height during the streaming step. That should never happen during streaming. Don't fix it, just try to explain the problem or identify the problem. And I also reach for a better model. So I'm using G PT five thinking here.

And I also reach for a better model. So I'm using G PT five thinking here. So with thought for a long time, I'll be honest. Honest, like I just sat here for a really long time because it thought for a really long time. But it turns out that now if I say make the top photo a latte, da, da da, it never shortens. So that's really good. So we fixed the bug, it no longer shortens and it does keep the height.

So that's really good. So we fixed the bug, it no longer shortens and it does keep the height. If we start from scratch here, let's try a different one. We'll go for this website just to make sure it still works from scratch. It's going to finish and now it's going to resize the height. It worked. So the bug is fixed. Um, and we used that method that was just do the step by step thinking through method.

Um, and we used that method that was just do the step by step thinking through method. I usually start there. It's a really good way to have it. Just focus on the code that exists. Focus on trying to identify the problem and then have fix it. So those are my vibe, debugging tips. It's still gonna suck. You're still gonna sit there for a long time and try again and try again and try again. But just remember, never, never, never accept a change

and try again and try again. But just remember, never, never, never accept a change that didn't fix the bug because it wrote a bunch of code. That's bad. So redo your checkpoints, start a new conversation, have it focus on finding the problem first before it fixes it. Hopefully this will get you to the solution faster and make vibe coating suck a little bit less.

and make vibe coating suck a little bit less.