256. Does Vibe Coding Have A Place In Software Development?

Is vibe coding a good thing? Should I avoid vibe coding or should I embrace it? Is the code written by an AI or LLM good enough? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Does vibe coding have a place in software development? Yep, but probably not the place you were thinking of. Vibecoding is the concept of using an AI to build an application or parts of an application for you. Now it does that instead of you writing most of the code. So instead of you writing most of the code, you let the LM write the code and you just tell it what you want. But is that a wise decision? Let's talk about it in today's episode of Dev Questions.

SPEAKER_00 0:36

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:40

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk today about letting an LLM write the code for you. You've probably seen some really cool examples online or on social media of systems, applications, websites, and games that have been built using vibe coding. Some look really amazing. But what does this mean for developers? Should we all be doing this? Vivecoding has a place in development, but let's talk first about the dangers of vibe coding and when to avoid it. Then we'll get into when to use vibe coding. So the number one danger, and this is not an ordered list, it's just one of the dangers, is it's inconsistent with the rest of your code. When an LLM writes code for you, it might not match the rest of your styles. Now you might say, well, I'm vibe coding, I'm building an entire application. That's great, but how does it match with the other applications you've built? You may have walked in on organizations where they do things differently than you do. And it's kind of a culture shock at first. And sometimes you might say, Well, I want to write the way I have done it before. But that creates a mess because now some things are in the old way and some things are in the new way, and you have to kind of shift gears or you're rewriting code that's just changing how things are laid out or what the naming conventions are or things of that nature. So that gets messy. Well, with AI, it's not going to match necessarily your coding styles. Now, eventually in the future, they may start reading style guides to match your style, but it'd probably be a little bit. So for right now, they're in your that code will be inconsistent with the rest of your code base, whether it's in that application or other applications you've written. Number two, sometimes it writes code you don't understand. Now, why is this a big deal? Because if it runs, it's great, right? So you know, so if if it fits, it ships, kind of like that old motto. Well, if it if it runs, it goes to production, right? Please don't. Please don't do that. If you don't understand why it runs, well, you might have a major problem. Because if you don't understand why it runs, well, then how do you know it's running correctly? How do you know it's running the right way? How do you know it's not doing things you don't want it to do, or being less efficient than you want it to be, or the fact that it might not be taking into account certain variables or ways of doing things. It might be the wrong way, but it still kind of works. So understanding your code is important. And if it writes code you don't understand, well, then that's gonna be a problem for making sure that you can maintain that. Which leads us right into number three, which is an LLM does not necessarily write easily maintained code. Remember that code is meant to be read by humans. When we write code, we're writing codes for others to read. Because when you write code, you might write it once, but then it might be read dozens, if not hundreds of times by other developers. You might say, well, Tim, why would you ever do that? Well, what are you doing when you're debugging? You're reading the code. You're trying to figure out what that code is doing and where the error is in the code. You read through big blocks of code, trying to figure out what's going on. That happens over and over and over again. So you want to make sure that your code is easy to read for other developers. But that's just one part of easily maintained. You know, well-written code, that's great. But there are another other parts to that as well. For example, when you're writing easily maintained code, you're writing code that is modular, that can be easily swapped out with a different version, that is written in a way that matches, for example, you're using an object-oriented programming language that's written in an object-oriented way to best work with the rest of the components in the system. It's dry, it's solid, it's all these other things that we talk about, but an AI doesn't necessarily do that. So it makes it potentially harder to maintain as well. Now you may say at this point, well, Tim, you know, these are overcomable things. We'll get there. Okay. And none of these are like on their own, kill it, don't do it necessarily. But I want you to keep thinking about these dangers as we go along. We'll get to why you can overcome how to overcome these and also if it matters. Okay, so number four in the danger list is it does not typically handle edge cases. So this is what I call the happy path, right? So when you build an application, it's going to be a form that a user fills out and it gets put into the database. The happy path is the user fills out all the fields correctly, and then the application sends that data over to the database. That's great. But what happens when the user doesn't fill out all the fields? Did the AI take that into account? What if when you ask for a numeric field? Maybe you say, how many years old are you? And you expect one, two, three, four, five, six kind of thing, and they give you O N E or TWO. Like that's spelled out. That's that's that's an age, but that's not what you're expecting. You're expecting a number. Did it take that into account? Users will always give you something you don't expect. So are you handling that properly? Are they giving you a SQL injection attack in one of the fields? Did the LLM take that into account, or did it just try to put that directly in the database and forget about making sure it cleaned up that data and made sure there was no uh potential danger in that data being sent to the database? Because if not, you might have just dropped the database or might have dropped your tables or sent all of your data to the attacker. These are big things that are off the happy path, that are not on the normal how things work. They're edge cases. And with an LLM, or especially with vibe coding, you don't always get those things. You don't get the handling of edge cases necessarily. That leads us to number five, which is that vibe coding does not typically have error checking, logging, and other things in place to handle the way your application should work. So when your application has an exception, do you know about it? How do you know about it? Where when were you told? How are you told? Well, if you're not logging and if you're not sending those logs in the correct place, you don't know. It's a black box. You just know that your application probably crashed because the user said it doesn't work anymore, but you don't know why. This is where error checking, logging, and all the rest is a good thing. But also let's go one step further. Let's say you told the LLM, hey, I want to talk to this API, it needs an API key. And here's the key, okay? Which don't give your LLM a key. That's no whole other thing. But let's just say it did, or maybe it said, hey, put the key here. Where did it tell you to put the key? So even if you didn't give it to the LLM, don't, it probably said, hey, if you need a key, then put it here. Where did it say to put that key? It probably said to put it right in the code, which is going to get checked in a source control. Hopefully, you're doing that right. But it gets checked in a source control, which means that now your key has been exposed to everyone who's has access to your repository. That's a security breach. So the LLM told you what to do. It was the wrong move. What should it have told you to do? It probably should have told you what I would have told you to do. Hey, put a place in app settings.json for this key. But don't put the key there. Just put an empty spot there, okay? And now access that value using the uh i configuration and say, hey, iconfiguration.value string and location, right? And then take that key and put it in secrets.json. And that will come through locally to your application, allow you to test. But then I want you to either put it in your dependency injection system or key vault or in your Azure app configure environment variables, you know, wherever it's going to be, put it there as well for production. Those are things that I would tell you to do, but that your LLM typically will not tell you to do. It will say, hey, put your key here in the code, and it will work. Just because it works doesn't mean it's right. Again, going back to if you don't understand the code, you might not understand how big of a problem that is. So, number six, the last of my my big ones, and there's more, but number six is the LM is not always gonna write the most efficient code. There are ways to get data in and out of your SQL database. There's ways to show data to the user that work that are terribly inefficient. And I've got a demo coming up in a, I think, a couple weeks now, um, where I'll have a demo on a Monday where I'll show off some of the ways that you can accidentally abuse your SQL Server, either using bad SQL calls or bad entity framework calls, where you can actually get the data and it will work in development. But as soon as you put any size to your database, it's going to start crashing your application, it's going to start taking up too much memory, it's going to take up your entire SQL Server processing power and more because you wrote a bad query or because you wrote things in an incorrect way. So just because it works doesn't mean it's the most efficient code. And that's problematic. So that's something else. Again, you need to understand your code to understand is this the right way? Okay, so those are the kind of the six that I see are dangers, right? And there's more, but those are the major dangers of code written by an LA, especially an AI, especially a vibe code application. Now, these issues are all magnified when you vibe code an application because of the fact that you're not writing most of it and telling the LLM, hey, I want you to do this piece of it. You're saying write everything. So those issues get magnified because you're not constraining it or giving it the things like the boundaries to work inside and so on. Now, you can mitigate a lot of these issues with enough prompting. If you get really good at prompting, and if you're specific enough, and if you have the AI try again when it doesn't get it right, you can avoid most of these issues. But at that point, what you've done is invented a less efficient means of coding. You give it the exact logic you want, you re-ask for the solution multiple times, you wait for it to process over and over, you break it apart into steps, and then you check every step. That's just inefficient coding. So that seems problematic too. Um, so why would you ever vibe code? Well, the answer is for prototyping. If you want to try something out, a vibe code app can be a good option. You can test a theory, sketch out a concept, try out a workflow, and more using vibe coding. But here's the kicker. We've been doing this for basically decades now. Sure, we haven't used an AI to write code, but again, we aren't really spelling out, we're really spilling out everything for the AI to do. What we're describing here is just regular prototyping. For every app I have ever built, pretty much, I have created one or multiple test projects where I try out various concepts. My hard drive is full of console app 35 and Blazor App 23 and other similarly named projects. Those projects are there just for me to test various bits, to prototype something. And the difference is that now we can make these concepts even faster. It doesn't matter if the prototypes aren't written well or if they don't follow best practices or have error checking. You aren't testing for those things. You're testing a concept. That means that roughing in a bit of testing code to see if something is working the way you expect is a great option. And that's a great place for vibe coding. Now, just a word of warning. Just like with prototypes, be very careful how you show them off or who you show them to or what you do with them. Prototypes have a way of accidentally being put into production. How do I know? Been there, done that. Okay, where I write something and say, hey, this is a little bit of code, I think this works, and I try it out, and like, yep. And my boss is like, we need to get this now. And I've got something working, and he's like, cool, send it. And before I know it, that's in production, and it's poorly written code, and it's it's not optimized, and it's not error-checked, and it's doesn't have all the things around to make it a good production code, and yet it's in production. And that happens a lot. So be very careful of that. But then also be careful that you don't set the wrong expectations for management. I work with a designer who is excellent. Not that long ago, she showed me a prototype for our new website in Figma. Using their prototype mode, I could see the entire design as an actual functioning website. It was amazing, but also kind of freaked me out. And we actually had talk about it. I said, hey, before you go any further, I just want to talk this through with you. Because I want to make sure that I set you up for success should you ever go somewhere else and work for somebody else. I said, you know, this is awesome. This website looks amazing, but be careful who you show it to and how you communicate what it is. Because if a prototype looks too much like a functioning product, a manager might expect that it can be implemented quickly because it appears done already. Okay. And really things like Figma start to blur that line because they can output HTML code, right? So why wouldn't you just toss that into production? It doesn't matter that it's not really optimized, it's not really the best code, it's it's not human readable or not as human readable as it should be, all those other things, because it works. So be careful of that. Be careful that you make sure it's a prototype. There's actually studies that have worked through the idea of how do you show off prototypes? Well, and one of the ways that you do that is by showing things that are obviously sketches. So that even if you have app designers, and I worked with different app designers, where you could prototype something and it would look like it's a sketch drawing, but kind of quote unquote work. So you can kind of show off the process while at the same time making sure it's clear that this is a prototype, not the real thing. Okay. So you gotta make sure you set expectations carefully when you build a Vibecode app, that you don't have your boss see that and they go, cool, send that to production. Don't do that. Okay, don't let your Vibecode project set the wrong expectation for yourself or for management. So use vibe coding for prototyping, but rebuild it entirely for production, just like I do with my Blazor app 23 or my console app 35. All right. So vibe coding absolutely has a place in development. It absolutely can help us be better and faster as developers, but it's not going to, it should not replace you actually building an application. Okay, so thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 16:55

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to Iamtimcorey.com and enroll in a course.