All right folks, here we are at the end. Hopefully I provided enough tips and techniques that you can go forward and do really cool, fun stuff with coding agents. They can be frustrating, uh, they can destroy stuff, they could be dangerous, but ultimately it's an impressive technology that is allowing me to build stuff that I could have never built without them. They're really propelling my own knowledge

that I could have never built without them. They're really propelling my own knowledge and skills into a place where I am just having so much fun coding day in and day out, even on weekends. Like I love working with these things. I know I've been a little bit, uh, skeptical and pessimistic at times throughout this course, but ultimately I really love working with these things because they add so much to my own ability and it's important to be able to keep them in line.

because they add so much to my own ability and it's important to be able to keep them in line. But I really hope that you come away from this course with the excitement to try it out and see what limitations you run into and learn how to get around those limitations with the tips and techniques that I've given you. So I'm gonna give you one last parting note on the annoying things that coding agents do. So at this point, you know how to prompt them, you know how

things that coding agents do. So at this point, you know how to prompt them, you know how to troubleshoot, you know how to debug, you know how to design, you know how to do all that stuff, but there's just some high level stuff that I want you to watch out for as you go out and you code with coding agents. So let's get started. Alright, so annoying thing number one that coding agents do is they add tons of functionality and lines of code to a single component.

that coding agents do is they add tons of functionality and lines of code to a single component. They do this all the time, every single time I have it. Create a new component, it, it'll do 1200 lines of code before I know it. Just massive components. And so, uh, one way to help prevent this is to use cursor rules. We haven't talked about this much. I don't tend to over rely on cursor rules

We haven't talked about this much. I don't tend to over rely on cursor rules because I don't want to fill up that context too much, but in many cases they are helpful for setting some system level instructions here to, to guide it towards the kinds of things that you like to do in your own coding. If you want the agent to match that, to match your preferences and you're frustrated because it doesn't code the way you

to match your preferences and you're frustrated because it doesn't code the way you do, try out cursor rules. They're very simple to write. It's just like prompting like we have done in the rest of the course. Um, and here you want to create a cursor rule to keep components small and focused. However you have learned to create components. If you're creating react components

However you have learned to create components. If you're creating react components or any file really, uh, the bigger a single file gets not only the harder it is for you to read, but it is harder for the AI to ingest and understand and work with. I have definitely had points where files have just gotten too big and agents stop working on that file. They just break down and they fail every single time. So it's not just a human thing, uh,

They just break down and they fail every single time. So it's not just a human thing, uh, because of the golden rule, because of context rot. We know we wanna keep those things small. So watch out for this and don't let it create massive components because it's a mess. Alright, annoying things coding agents do. We've talked about this one a little bit already, but they change way too much for a simple request.

We've talked about this one a little bit already, but they change way too much for a simple request. Just keep an eye on this. It happens all the time and every session that I'm doing the solution here, you know what the solution is. Pass the right context in, tell it to keep the solution simple. We've talked about this before. I thought it was worth reiterating.

We've talked about this before. I thought it was worth reiterating. I often, often, often tell it keep it simple because I just find that it's like refactoring half my files for absolutely no reason. These thinking agents especially, they really love to refactor stuff. They really love to just absolutely change everything. Uh, and it's super annoying. Alright, next step is a really dangerous one.

Uh, and it's super annoying. Alright, next step is a really dangerous one. This is what I find is that the heart of some of the most dangerous, terrible, awful things that these coding agents do is I've noticed that they assume your app is pre-launched. You can see this in the comments, you can see this in thinking, uh, you can see this in the output that they give you. They always say stuff like, well,

you can see this in the output that they give you. They always say stuff like, well, you can fix this once you go live because the app isn't launched yet. We can do this. We can make this security mess, we can make this performance mess. We can just leave out entire bits of functionality that we requested. Uh, this is really bad. And so make it clear to the agent, uh, whether

Uh, this is really bad. And so make it clear to the agent, uh, whether through a cursor rule or just when you're prompting something that's super important like security or anything that's to do with like performance. You, you frequently need to make it clear to the bot that what you are working on is real code for a real app with real users, this is going to production and that does change its mindset.

with real users, this is going to production and that does change its mindset. For better or worse, I don't know what sort of uh, reinforcement learning they did on these things, but they are always fully convinced that your app is pre-launch and that's why they'll do things like drop your database table. It's just absolutely just completely drop 'em. I see this in the vibe code and community all the time.

It's just absolutely just completely drop 'em. I see this in the vibe code and community all the time. They just lost their database because the, the, the bot needed to make a change. And it just assumes that your app is pre-launched and that there's no good data in there. So you need to make it explicit. One, you need to make sure that they can't do too much damage, they can't do anything, they can't be undone. So we talked about that before,

damage, they can't do anything, they can't be undone. So we talked about that before, but in general, you want them to write good code. And to do that you need to make it clear that this is production code and that gets them kind of down a different path than like, oh, this is messy prototyping code that we're making here today. Alright, so this one's the big one. This is the one that gives vibe coding a bad

Alright, so this one's the big one. This is the one that gives vibe coding a bad name and for good reason. This is to the detriment of everyone who attempts vibe coding if they don't know how to get around it. If you don't know anything about performance and security, proceed with caution. If you are holding people's data, other users' data and you don't understand basic security, get outta here.

If you are holding people's data, other users' data and you don't understand basic security, get outta here. It's, it's not for you. You need to learn about basic security. But if you do, then how do you use these agents to make sure that you are doing a good job? They can, they can back you up, they can back up your own knowledge. And so what I do is I often run security audits or performance audits with the agents themselves.

And so what I do is I often run security audits or performance audits with the agents themselves. They do a pretty decent job of helping me spot things that I know I should look for. And so I'll just write a prompt that's basically along the lines of do a thorough audit on this part of the code. Look for things like this and make me a markdown document. You know, I wanna make sure that my end points are, are not doing anything sketchy

You know, I wanna make sure that my end points are, are not doing anything sketchy and that everything's locked down and that I have good security policies in place and performance audits. You know, look for code loops that are getting out of control. Look for memory leaks, those types of things. Uh, they do a pretty decent job at making documents of things that you can go through and then fix.

Uh, they do a pretty decent job at making documents of things that you can go through and then fix. And so it's the process that we saw in this, in this course already is basically you make a markdown doc and then you go through either one at a time or in bulk and just say, okay, let's work on these issues together. So you need to make a plan, go watch our planning video. And the plan in this case is geared towards either performance or security for a specific part of your code for a specific flow

performance or security for a specific part of your code for a specific flow and then ask it to make a list of all the issues and then go through and list the issues together again, especially for security that is not sufficient. It is mandatory, but it is not sufficient. So keep that in mind. You obviously need to keep in mind the best security practices for running any application. Oh, and also don't put your API keys in the code.

for running any application. Oh, and also don't put your API keys in the code. I'm sick of seeing vibe coders. I put the API keys in the code that gives everyone a bad night. Just don't do that. Come on, come on. Next up tests. They write bad tests. They delete tests, they skip tests and they work around them. This happens all the time. I suppose it's because they're trained on human code

This happens all the time. I suppose it's because they're trained on human code and we probably do this too much. Um, but you see often if you just like looking through your code, you'll see comments and it says like, test removed, problematic tests removed is what it always says. Or I'll tell it, Hey, go fix this 'cause the test is failing. And then it just comes back with,

go fix this 'cause the test is failing. And then it just comes back with, well I've removed the problematic test. That's no good. Obviously you want it to uh, uh, honor good tests. If they are good, you want it to write good tests. You don't want it to skip them, you don't want it to work around them. They, they do just like humans do and they get a little bit lazy here.

They, they do just like humans do and they get a little bit lazy here. So have a cursor rule that outlines your preferred testing strategy, how you like to write tests. Make sure that the uh, agent has that information. Otherwise it's just gonna be really lazy about it. Alright, here it is. Here's my last piece of advice for vibe coders is that coding agents take shortcuts, repeat code and generally make a mess.

for vibe coders is that coding agents take shortcuts, repeat code and generally make a mess. All of the bad things that people say about coding agents maybe aren't true to the extent that people say, but let's be honest, they are true coding agents often write really bad code. Um, for some of us, if you're not super, super experienced, in some cases, if you're a backend engineer, maybe it writes better front end than you. If you're a front end, maybe it writes

maybe it writes better front end than you. If you're a front end, maybe it writes better backend than you. But in general, they have not yet reached a point where all the code that they write is great. And that's because they take shortcuts, they repeat code. And so you get a lot of code bloat. Uh, they don't often uh, understand, you know, the don't repeat yourself dry principles unless you explicitly prompt for that

the don't repeat yourself dry principles unless you explicitly prompt for that and they just generally make a mess. Like if you have a pure vibe coded code base, no one, no one will expect that code base to be beautiful. Even the people putting out these agents, even the people making them, they use them every day. They know that if you have a pure 100% five coded code base, it's probably going to be a mess. So let's just accept that.

it's probably going to be a mess. So let's just accept that. Let's know that it's going to be true. Let's not pretend that it's not going to be true and let's figure out how to still use coding agents and move forward in a world where that happens. Create cursor rules. Tell it how you like to organize code, tell it the best practices that you like to follow. How would you make this, uh, create an agent

tell it the best practices that you like to follow. How would you make this, uh, create an agent for code review we talked about on that in this course. So that's super important. All the big chunks of code that you write, create an agent, have it, review that code with the expectations that you have. It can fix these things really fast. That's the thing that I think people underestimate. It's not that these things can't write good code, it's just

That's the thing that I think people underestimate. It's not that these things can't write good code, it's just that they don't tend to out of the box and you can get them to write really good code and you can get them to do it so dang fast. That's the thing about coding agents. That's the reason why we're all using them is 'cause it can write hundreds and thousands of lines of code and like lty split no time at all. You just have to get it to a place

and like lty split no time at all. You just have to get it to a place where it's writing the kind of code that you want. And so for all these issues, I say create an agent that's a new chat. Create a new chat, make some cursor rules or something. But in general, you make a new chat, you tell it what you want to do, and then it does a pretty good job if you're guiding it towards the best practices that you want to have and the the messes that it needs

you're guiding it towards the best practices that you want to have and the the messes that it needs to clean up even it does a pretty decent job. So you as a vibe coder just need to put in the time to do that. If you prompt it to write some code and then it writes some bad code and then you give up and you say you're done, look it wrote bad code that was also you, you are a part of that. Like there's a, there's a relationship there between you

that was also you, you are a part of that. Like there's a, there's a relationship there between you and the coding agent and you are 50% of that responsibility to make that code good. And if you're just giving up and saying, well, it didn't make good code, that's not my fault. It is your fault because you had an opportunity to go in and prompt it to write better code, better code, better code.

and prompt it to write better code, better code, better code. Now you might hit a point where you just decide that you're such a good engineer, that you can actually write good code faster than the buck. That's totally fine. If that's where you are, then maybe these things aren't useful for you. Maybe they aren't for you. But if you are someone who says, Hey, wow, they, they can write a lot better and faster than me under certain circumstances,

Hey, wow, they, they can write a lot better and faster than me under certain circumstances, then your job is to just figure out what circumstances you can uh, use to your favor. How to get them to write good code, to write organized code, to write performance and secure code for your projects. And hopefully the tips that we've gone over in this course will get you there. 'cause again, these things are super fun and I hope you have a blast.

'cause again, these things are super fun and I hope you have a blast. Five coding. Thanks.