In our last video, we built out a brand new feature inside of winder using what I call the explain method, where we had the LLM explain how the current functionality works and then build on top of that with a new feature. And so now inside of winter you can drag multiple art boards around at the same time, whereas you could only drag one before. So then the question is, there's all this new code, this is all this new code that has been written by the LLM,

So then the question is, there's all this new code, this is all this new code that has been written by the LLM, how do I know if it's any good? And the answer to that is pretty simple. And that if you're an engineer, you should look at the code. Yes, this is a vibe coding course. I'm still gonna encourage you to look at the code. If you can read code and you can look at it and decide if it's good and decide what needs to be better. Just do that. Look at what it wrote

and decide if it's good and decide what needs to be better. Just do that. Look at what it wrote and tell it how to do better. Uh, in the spirit of vibe coding, I'm going to show you a trick that I do to have the LLM review code that has been written. Now this can be code that I wrote myself. It can be code that a different agent wrote in a previous chat. The trick is here. Always start a new

wrote in a previous chat. The trick is here. Always start a new chat again, I'm all about that. You always wanna make sure that you have a brand new chat, brand new context. 'cause what that is, is I like this button here. It says, new agent. That's what it's, it's a brand new agent. This is a fresh pair of eyes that will come in and no matter who wrote that passcode,

This is a fresh pair of eyes that will come in and no matter who wrote that passcode, it is able to look at it. And what you can do is you can actually, since I have all of these open changes here, I can actually at mention and then go into Git and then say Branch Diff with Main branch. So it's gonna look at the main branch. It's gonna look at what I've been working on and say, what's the difference here?

It's gonna look at what I've been working on and say, what's the difference here? What's all this new code in here? It's really handy. You should use this feature a lot to take a look at the work that you've done so far. And then I'm gonna paste in my prompt here. I'm going to say review these changes like a professional react engineer. This is a front end change. That's why I wrote that. It's a lot of just react state management, which I find

This is a front end change. That's why I wrote that. It's a lot of just react state management, which I find that these bots kind of suck at. And they write a lot of redundant code. They create a lot of race conditions. It's a lot of bad stuff in here if you don't, uh, run this command to, to look at it. So that's why I said professional react engineer, if it's a heavy backend change, you might change what you're sort of guiding it towards and,

if it's a heavy backend change, you might change what you're sort of guiding it towards and, and the lens through which you want it to give feedback, that's what I'm doing here. Told it to use best practices. And this is the key. I tell it to group. Any issues as critical should fix or low priority. That's the key for me is I don't want it to just spit out a bunch of stuff in random mortar. Uh, I've run this prompt a bunch

spit out a bunch of stuff in random mortar. Uh, I've run this prompt a bunch of times without that and that's what I get. I just, I get no sense of, um, what's really important to fix. And so I also said, leave a category blank if there's nothing to put in it, because I don't want it to just try to evenly distribute stuff in the categories, which is kind of what it tends to do.

to evenly distribute stuff in the categories, which is kind of what it tends to do. So this is my process. I've refined this a few times over the, the past few months to try to get it to have good results. Another thing that I do is I will run it with different models in here, run it with G PT five, run it with Gemini 2.5 pro, run it with cloud sonnet or whatever models that you have access to. This is your panel of experts.

or whatever models that you have access to. This is your panel of experts. You can have multiple people look at this code and then you can decide if you know enough, which one of those issues is really critical, which one is important enough to spend time on. So I'm gonna go ahead and run this prompt and then we'll come back and see what it spits out. Alright, so we're back with the results of that prompt. And the good news is, is that according to this, uh,

Alright, so we're back with the results of that prompt. And the good news is, is that according to this, uh, specific run of the prompt, there are no critical issues that would block this change. So what that means is that it looked in there. There's no like major security vulnerabilities. There's no, uh, memory things that are gonna take out my, my site or my application. It, it looks pretty good. Now, there is a bunch of should fix stuff.

It, it looks pretty good. Now, there is a bunch of should fix stuff. Like if you have time, you should address these things. They're not maybe super critical, um, but they are things that you should fix. The things that it found are major code duplication. This doesn't surprise me at all. This is the chief. I think sin of these code writing bots is that they tend to write duplicate code. Uh, they don't tend to find things

to write duplicate code. Uh, they don't tend to find things that they can abstract out into reusable utilities or functions. They just write the same code again and again. And even in the same run they'll do this. So this doesn't surprise me at all. Fortunately, it is a fairly easy fix. Um, and I tend to have a lot of luck with actually taking something like this

Um, and I tend to have a lot of luck with actually taking something like this and asking it to fix it and then having it pull it out into reusable bits of code. Uh, there is a potential bottleneck performance, uh, performance with bottleneck here across the broadcast channels. So the way that my application works, we haven't talked about this yet, but it actually does have multi-user syncing.

we haven't talked about this yet, but it actually does have multi-user syncing. So as you drag an art board on your screen, there's another user on their own computer that would see that drag in real time, a little bit like Figma. And so it sees that there are some potential performance concerns. That doesn't surprise me at all because we didn't really prompt it through that. That was just kind of a, something

because we didn't really prompt it through that. That was just kind of a, something that I left out on my part. I didn't think through how that would need to be done from a performance perspective to, to broadcast those real time changes. So that doesn't surprise me at all. And, uh, there's unclear state contracts and redundant logic. So there's a few things in here that ideally just like

state contracts and redundant logic. So there's a few things in here that ideally just like as if we received a sort of PR feedback from a colleague that we would then go and address. And then there's some low priority stuff in here as well. And so what I would do is either if I have enough context, uh, left and I only have used 10% here, so I'd probably just kind of go at it, um, one at a time and start to fix some of these issues in this chat. Maybe open up a new chat and come back to it.

and start to fix some of these issues in this chat. Maybe open up a new chat and come back to it. Um, alternatively, if it's a lot of feedback and a lot of stuff that I need to do on a big feature, what I'll have it do is create a markdown document that I can then come back to again and again and then fix the issues one at a time. So we're gonna go ahead to just round out this video and start to fix the, the top issue and see how that goes. And as long as everything goes well, we'll call that good.

and start to fix the, the top issue and see how that goes. And as long as everything goes well, we'll call that good. Um, and then you can imagine that we would just keep going through this list to make sure it fixes everything. I have tried a few times in the past few days, honestly, to take feedback like this and tell it to fix it, all of it. You can absolutely try that. I find that in my recent attempts that simply doesn't work. I would love for it to fix all of this stuff in one go. It just hasn't been working for me.

I would love for it to fix all of this stuff in one go. It just hasn't been working for me. Um, I would love to deliver better news. It just hasn't been working for me. So we will try the major code duplication, let's say plan out and fix the major code duplication issue. Nothing else for now. So I'm gonna send that prompt and then we're gonna come back in a second and see what it does to just fix that one issue.

So I'm gonna send that prompt and then we're gonna come back in a second and see what it does to just fix that one issue. All right, so we're back. Let's see how it did. I did run into an error somewhere in there. All I did was paste the error back into cursor and it seemed able to fix it. So in that, let's say two prompts, just the original prompt plus the addition of the error, I was able to get a successful state. The summary of the changes is

I was able to get a successful state. The summary of the changes is that it created a reusable hook. Um, if we go over here, we can see that the functionality is mostly good. So there's a lot of things that I would then go do and make sure that I've, uh, created some unit tests in here to make sure that's all working good. Make sure that I've done a lot of click testing. My, my application is pretty complicated,

Make sure that I've done a lot of click testing. My, my application is pretty complicated, so I wanna make sure that nothing broke here. I would test, uh, adjacent features, a lot of like resizing features to make sure everything like that still works. There's a lot of testing that I would still need to do, but a high level, you can see the flow that I go through. Basically I pass it the code that was recently WR written and the, the features that I've been working on

Basically I pass it the code that was recently WR written and the, the features that I've been working on and all of that code, I ask it to review it, I ask it to prioritize that, and then I address those items in priority order. And once I'm feeling really good that there are no really critical issues that most of the should haves have been fixed, only then will I actually submit that PR and I'll actually, uh, start to push that code.

only then will I actually submit that PR and I'll actually, uh, start to push that code. Alright, that's it for this, uh, video. We'll see you in the next one.