The Security Nightmare of Vibe Coding

Kera here from the Kera Golden Show. If you're not using Ironclad for contracts, you could be leaving millions on the table. Ironclad's AI instantly surfaces what matters. Renewal dates, pricing terms, and obligations. So you can act quickly before opportunities slip away. That's why they're trusted by great brands like OpenAI, L'Oreal, Salesforce, and so many others. Find the savings hiding in your contracts at ironcladapp.com/podcast. That's ironcladapp.com/podcast. You cannot let the AI just deploy the production as supervised because it has no idea what to do. This is DevOps Paradox, episode number 323, the Security Nightmare of Vibecoating. Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor, pretend we know what we're talking about. Most of the time we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like Kubernetes, serverless, CICD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something but we do not do that often since they might make us look incompetent. The truth is out there and there is no way we are going to find it. Yes, it's Darren reading this text and feeling embarrassed that Victor made me do it. Here at your host, Darren Pope and Victor Farsi. Victor, is there anything wrong with Vibecoating? Well, most people probably start out Vibecoating. I'm assuming you did. I know I did. Yeah. I don't think there's anything wrong with it. I haven't written a line of code that I created in months. Does that scare you at all? No, why? I'm reviewing code done by others. And I'm instructing others how to write code. What's wrong with that? Like somebody told me the other day, the only thing he really understands is fix it because it's not working. He gets back into types, fix it. Okay, that's Vibecoating 101. If you don't know the phrase, fix it. That's what you want to use. Exactly. I think really everybody starts at Vibecoating. I think that's fine. Sometimes you're just trying to figure out what, okay, here are the perfect people to do Vibecoating, in my opinion. Product owners or product managers. Go with me here for a second. Architects. Because those two people probably use word and visio more than anybody else in a company. So why not give them the tooling to be able to just sort of get something going? Maybe, maybe not, right? It's a whole lot better than a visio document or whatever the visio thing is today. Let me just clarify something. If I'm not mistaken, Vibecoating, whoever came up with a term, was trying to say, yeah, explain my vibes, what I want. And AI does everything else. Basically unsupervised. Most people when they say Vibecoating are these days meaning, okay, do this. And I'm watching you. I'm confirming denying you to do things. I'm giving you additional instructions. I don't think about the former or the latter. You say Vibecoating. Probably the former in this case. Oh, that doesn't work. Okay. It doesn't. It doesn't work, which is going to be the key part we're going to get to. But it's not a bad way for somebody that is not a developer at all to sort of get something going. Yeah. But the danger, there's a danger in that, but go ahead and complete your thought. It's very good actually for new applications. Right. And those applications are very focused on specific features. That's it. Think of them as microservices or microsites. Right. So if you're an HR and you need to sort the candidates for to join your company in certain way, that's perfect for Vibecoating. Right. It can do it in one shot. Or if you want to create a website for, I don't know, your hobby, whatever it is, perfect for Vibecoating. Right. So if that's what we mean by Vibecoating, those are the good use cases starting for scratch, relatively small scope, work on it until it's done. Right. Hopefully that person doing that will spend time explaining, you know, the style or intention, what's it not, then it works well. The problem come when you start working on real applications. And real is the wrong word because all applications are real, but you know, existing applications, more complex. Right. When adding a feature means writing, I don't know, thousand lives of code and that being drop in a bucket, 0.001 percent of the total code base. Right. Then things become complicated. Those are the cases where I don't believe in Vibecoating from that perspective. Like I explain you what to do, what you should do. And I come back to you when you're done. I would call it unsupervised AI. Completely breaks apart. That's silly things. But for HR, and I'm using them as example, or your personal something application, you need something that is perfect. It's amazing. Loveable, for example, is a great example of a big success story for that. So you're actually reinforcing a point that I have, I have a couple things written down, some of the pros of Vibecoating, rapid prototyping, and faster initial development. Right. Perfect for that. Oh, yes, perfect. That's what that's the reason why I was saying architects or product owners or product managers that are trying to come up something that's good for them. Right. That's it's better than giving me a, what they think is a requirements document. I would say your examples for right except I'm not sure that I would agree about architects. Okay. That's fine. Right, because I'll pull them out. You know, it's about being an architect, meaning considering all the different variations, doing different types of experiments, figuring out what it's, it's a lot of work. But everything else I agree. Okay. Another one's useful proof of concepts, throwaway code. It's exactly what you want it to be. Yeah. But let's say you've Vibecoated something now and you're ready to turn it into production. It's going to be an internet public internet facing application. I have Vibecoated something and I said deploy to the internet. What could go wrong? Are we still talking about unsupervised? Yes, unsupervised. Yeah, everything will go wrong. I mean, again, if it's the HR something something, then it's going to be fine, most likely. Right. But if you're talking about now, moving into doing that with real business applications, you know, those that make money, those that lose money, they stop working, then everything will go wrong. We are not even close to unsupervised AI. A lot of things that need for that. Think about the basics. As humans, we still do this. When was the last time you hardcoated in an API key and committed it to get? It's been a while probably, hopefully. Yeah. But let's go through a standard Vibecoating session. Hey, I see that you need to interact with thing that needs an API token. What's your API token? Copy paste. Okay, thanks. I'll go ahead and take care of that for you. That's what's going to happen. Think of it in terms of for human. Ignore AI for a second. Right. Let's say that you just hired some kid that just graduated university, but that kid is a genius. Knows everything. It's absolutely the most brilliant person that ever walked this earth. Can you let him on day one operate your production system? And just to give you a clue, so if you don't provide an answer that I don't want you to provide, is that that kid knows nothing about your company. Doesn't even know whether you use AWS or Google or Azure. Let me answer it this way. His day one will be your last day. Period. That's what would happen. Exactly. You need to teach that person. So person knows what that person knows. And let's say that it's very experienced. So you still need to have, I don't know, maybe a week, maybe a month, maybe a year of training so that that person understands how your company operates. No matter how skilled or even if you take a most senior engineer that ever walked this earth, that person is not going to deploy to production day one. Not because that person doesn't know stuff, but because he has no idea what you're doing, how you're doing, where you're doing, kind of, what are your policies, what are your rule books, where are you even running that? Do you have your own data center or you're running it in AWS, right? There are so many things that that person wouldn't know no matter how good that person is. And that's the problem. And I'm going back to your initial question, right? You cannot let AI just deploy to production and supervise it because it has no idea what to do. In the context of your organization, not what to do in general. I don't know the AWS, I have zero doubt about that, right? But again, I'm thinking about security issues primarily in this episode. In a later episode, we're going to be talking about technical debt and vibe coding, but this one want to focus on security. Now, in theory, a well vibe coded app would apply all the O-Wasp top 10 things to everything it creates. Yeah. Should. But guess what, it's not going to. If you think back a couple episodes, we were talking about the MCP servers, and you were just doing a raw agent with no directions at all, going back to your, this is the first day. You're not going to have a good app. Can we agree for a moment that whichever permissions or whatever you're allowing the AI to do are the same things that you're allowing other people in your company to do? We have to say that. Yes. Yeah. You're not giving it more, kind of like, oh, everybody needs to create a pull request, but you specifically, you can just push to main, right? We're not talking about that situation. Correct. This would be, so your agent that's doing the work would have the same level as the standard SRE that's doing the work. Then what makes you think that that would be bigger disaster than a random person in your company doing the same thing? Oh, I'm not saying that the deploy isn't. That could be, it would be exactly the same. What I'm talking about is the actual creation of the application that's going to be deployed. Okay, but why would that be any better or worse? Well, worse is then same applications done by Joe. Okay, so with Joe, Joe knows to go ahead and do input sanitization. Joe knows. Is Joe the day one person? I don't know. Let's say the day one person. Okay, he's the one, yeah, so it'll be host. Yeah, he would have no idea. Yeah. Yeah. A 10-year-old Dan would know because he's been in the company and knows we've got to do input sanitization. Here's our standard frameworks. Here's all of our other things. Okay, so now we're coming to the, we started this, I mean, it's not started, but established a few moments ago that, okay, we tried treating the AI as same as human, give the AI courtesy of giving all the information that you get to that person over that year or whatever period it was there, right? Then would necessarily the difference be that big in the outcome? It should not be. But most people, if they're just vibe coding, they're not going to know that. There are physical limitations, right? We don't allow literally pushing to main branch, right? That's physically not allowed type of situation. And many, Zillian of other policies, right? And for those, doesn't matter whether it's AI, whether it's drove, whether it's Michael, whoever is doing, needs to be the same roles, and that there is a knowledge. And that's a big difference, right? So yes, if the question is, hey, can we give inexperienced person or AI or whatever inexperience in this context does not understand how this company works, permissions to do stuff. And we expect ratings, you're a fool. But that applies equally to people as to AI. This is where AI is not going to solve the problem. I guess that's where I'm getting it back to is. Yeah, no, I don't know me times. I've been on a project to where the phrase comes out, well, we'll take care of security later. Does it ever happen to you? I mean, it happened there. I'm not the good person to us because I was usually the cause of those security issues. But some other person, yeah. Right. But usually we would always push those things off till the end, right? Security is pushed off, testing gets pushed off. All we've just got to get it out. We, you know, that somebody went and played golf and now instead of shipping six months more now, we have to ship in two weeks. These things happen, but vibe coding is not going to make that magically go away. Actually, not magically, but it's one of the ways why I believe we have a chance for those things to go away. Let me explain. All those examples that you just said, you know, all those, we're going to push security for later and we're going to push implementation of this thing for later. And so why are we pushing those things? The reason why we're pushing those things is we don't have the time to deal with them right now. Exactly. Precisely. Now, if they can help reduce the burden in some other area and freeze your time to do those things, isn't that a win-win? Well, that's AI and well-constructed AI. Yes. But in the context of, okay, I'm just going to vibe code my auth in an auth Z for everything. I think if we have false expectations of AI, right? Kind of, people go to extreme. Oh, I'm going to write a single sentence of something and it's going to do something marvelous and then there are two extremes of that outcome. It's kind of, oh, this is horrible, it doesn't work, right? The other extreme usually influences on YouTube. Oh, look at it. Great. It's successfully created a Tetris game, right? It's false expectations. AI is a tool. It's a tool that has a very big potential to be very, very helpful. But then the other tool, the outcome greatly depends on a person using that tool. Stack Overflow is a tool. But you shouldn't blame Stack Overflow for all the mistakes done before AI, right? We should blame people who are actually using that tool. Visual Studio Code can do auto-complete. Now, if an experienced person or somebody just says accept, accept, accept, accept, accept, do we blame auto-complete? It's a tool and you need to be skilled at using it. And that means that you need to understand how the tool works. And you need to have the domain knowledge behind what you're doing. Anything less than that is not going to work. No matter how capable or incapable the tool is. You're sending me down a different rabbit trail. I'm going to try to clean it back. Okay, pull me back. Okay, so we've gone down this really big path of what you should do. But let's go back to the people that are just vibe coding and putting their app out on the internet. Maybe they've never deployed any kind of web application before. What's going to be the first thing that happens? The first thing that the captain says is that those people for the first time in their life got an application running, which is awesome, right? We're still talking about HR for this example, right? Yeah, it's absolutely awesome. It's awesome. But now it's only public. Let's let me spin it around. Let's say that I spent some time this weekend in vibe coded a, let's call it a dating app. Okay. And I've deployed this dating app out to the internet. Okay. And I have said, oh, just come here. And I've actually got some budget. I spend some money on ads. I drive traffic to that site. Okay. There's actually a database behind it. Okay. vibe coded everything. By the way, when it created everything, it went ahead and put in the root password. What I didn't know is it actually put in an administrative, standard administrative console in that everybody in the world already knows it exists. So now all of the data has now been exposed. And by the way, I was charging credit cards. And instead of actually doing the integration with Stripe, I just decided to save the credit cards locally. And because that was, or excuse me, I didn't decide the vibe decided. I'm not going to give it in the vibe decided just to save the credit cards locally because that was the easiest thing to do. Yes. This is what happens when you allow vibe unattended to run your life. Your life becomes miserable unattended because that person wouldn't know what to do by attending it. Okay. Now, let me give you alternative scenarios. Okay. The same person, same knowledge experience doing the same goal, no code, any difference? Ignore the amount of time needed to do it. There should not be any difference. It should be negligible. Yes. Spend more time, but not sufficient, learning the basic of HTTP and JSON, sorry, and JavaScript, just enough to succeed. The bare minimum to succeed somehow, any difference? Should not be a whole lot of difference. Right. What I'm trying to say is that, yeah, that person just accomplished the equally disastrous outcome faster. But it's not that outcome wouldn't happen without AI. I mean, maybe it wouldn't happen because that person wouldn't be motivated kind of, oh, I can do this in a day. Otherwise, it would take me a week. Hence, I'm not going to do that. So the disaster never happened. I give you that. Right. But still, I would even argue that there is a chance, I don't know whether that's today or tomorrow, that maybe actually with no code, something, something or self-code, bare, self-tots, bare minimum, the outcomes would be probably the same. But with AI, maybe there is a chance that day I would be trained in a way to actually tell you, do you understand that you're exposing the password? So now I'm going in a direction that actually maybe actually with AI that is the same scenario, assume that the person is willing in all three scenarios to do it, no matter it takes in other scenarios more. Maybe I would actually warn that person. Maybe that person would learn something that otherwise wouldn't be learned with no code or the bare minimum self-tot. I agree. That's not a bad direction. That's not reality today. No, absolutely. I'm just trying to say that, you know, that was that was being done and happening before. I mean, come on, you can do the same thing with the bare self today. And in a day. No, I understand that. I'm just saying that people that are not aware of what it takes to actually run an application on the public internet, thinking they're going to vibe code something and make a million dollars by the end of the month. Oh. We agree on that 100%. Yes. That's what I'm talking about. Again, I'm going to go back to the beginning. There is a space for vibe coding coming up with the ideas, quick prototype. Heck, I've done it. But let's say you're a senior and you've been tasked with working on a new greenfield project using your idea as well. There is nothing wrong with vibe coding that idea and turning around faster just because your PM doesn't want to do it. Not just failing faster, even better. Or failing faster. Right. Being able to fail fast is a wonderful thing. But now let's say you've vibe coded the example, the proof of concept. Manager sees it. Boss sees it. Let's ship it. And then you as senior says, no, no, no, no, wait a minute, wait a minute. This is the equivalent of shipping in Excel spreadsheet to act like a real database. Yeah. So although you got to a shipable item, now you've got to go back and actually create it as a project. So take your vibe as your input into actually creating the true product requirements. Because if you think about it from the olden days, like two months ago, you would have people work for three to four years to write a product requirements document that would then get reviewed by five or six different teams over the course of one or two years, though within and handed off to somebody about year four to start implementing. And oh, by the way, if you need to talk to those people, they're very left company. Whereas now, you as a senior can take the code that you've written, use it as an input, have your model create initial PRDs. In fact, this is my standard right now is I may vibe a couple of things, just get some ideas going. And I'll say go and create me an epic for this thing. And I'll chat with it a little bit more and sort of get the epic where I want it. And then I'll go in in a new context because I've saved the epic. And I was like, hey, go read this epic. Yep. Got it. Go ahead and create work item PRDs for me and break all those down. And let's work through those. Guess what I can do then? Now I can go to the stakeholders. It's like, here's the epic. What do you all think about this? I probably won't show them the work items. I might show a couple of them because some of the work items that I've seen generated for me have provided items to me. It's like, I didn't even think about that. Yes, I need that. Imagine that same epic. You say it's done. Not done as if we're going to, we're never going to merge this to main. But kind of like, here's the epic. And here's the working solution. That is not good. You know, it's far from what it should be. Right? Because you can, you can feel it, you can see it, you can touch it, you can discuss it. And then we're going to go to throw it to trash. But now I've got budget. And I've got a plan. Yes, we virtually threw it to trash because we could still go back in reference. It's like, oh, okay, yeah, we can do that. Because we could still iterate a little bit on that. But hopefully, because we use that as the baseline, now we have the true base that we're building from. You're probably based on that fastly done implementation. You're probably going to refine a bit more PRD, right? Let's just learn. And then when you start working on it, it will be even faster. No, by the way, I'm actually not doing the coding. I'm having the agent or agents take the work items and go to the work. The PRDs could be issues and get a cure or whatever. It doesn't really matter. It just even mark down files in the repository itself. Lots of different ways to solve it. That doesn't matter. What matters is I got something going. It's probably highly insecure. Probably something I would never want the public world to have access to. Probably not even to my public company. Firewalls, right? I mean, my little team can work with it. I'm fine with that. But as soon as we start exposing it, for anybody else to use outside of my team, that's when the real app has to come into place. That doesn't mean I have to write it going back to the Dan example, being their 10 years, that knows it has to use this framework because it's the company level framework on doing things. It's like, oh, no, I've trained trained. I've taught the model. Going back two episodes about MCP servers. I've got an MCP that understands the workflows of what has to be there when things get created. Greenfield. It's like, so you have somebody come on the team, it's like, well, I don't know how to code and go. It doesn't matter. Your agent that you're managing knows how to code and go. The question is really, if you're doing more seriously than previous examples, the real question is, do you know how to read go? So that you can smell bad or wrong direction. If you know, then you're fine. We're at the point now where this is coming back full loop. You have people today that are vibe-coding applications that are putting them on the public internet and having all sorts of bad things happen. But as you said, they shipped something to the internet that they had never done before. So that's the upside. Do you think they understood whatever was being written? Probably Python or JavaScript? No. Why do we think we need to understand, I mean, yes, we need to understand it. It would be great if we did. I also suspect that those cases, like I'm going to stick with example HR, right? I think that this is very, very temporary solution what we're doing right now with genetic models, genetic agents. I'm pretty sure that very, very soon we will see more focus solutions for HR in general, kind of like HR AI, kind of like that prevents you from exposing passwords. You can still do bad things, it's honest or what, right? But imagine when we start getting more focus solutions. We won't need a ton of developers anymore. You think about, okay, you're using HR. Let's go broader than that. There was usually a team or a certain amount of people that always worked on internal applications for a company. Now if I can have somebody, just the HR person themselves, start working on something. That's the vived solution. That then that gets handed over to the devibers. I'm making up lots of words here. That actually take the vived solution and turns it into a real solution. That might take a day, it might take a couple of weeks. It could take a little bit longer. But if you think about how a typical internal application worked two months ago, that could get really sped up now. Yes, it will be sped up for sure. I have zero doubt. My main concern, whether that being sped up, will mean that team that worked only on internal applications. I'm following your example, will be decimated or that team will stay the same and finally be able to fulfill all the needs, internal needs that they've been struggling to fulfill for 20 years. I think it's the latter. Because internally it feels both. There are companies that they're going, oh, I can cut costs. I'm doing it. They're always those, right? I just hope that there will be a lot of lots of cases. Because sure, you can ship a vived thing. Great. That's all good. But what's the tradeoff on that? It would be no different than. Here's my analogy. You've been using other analogies. Here's my analogy. A vived app is no different than bringing in, back in my days and the 90s, you bring in a busload of consultants from a company, drop them in your office. It's like, hey, we need this app in three weeks. And then they're out and gone in three weeks. This is the exact same thing. They don't understand context. They don't understand the company. Nothing. In fact, they spent the first full week going through consultant onboarding to the company and now you've already burned one week over the three. But as I said, if it's assumed that in this context, you mean vived by inexperience person, right? Still, imagine how helpful that could be if that inexperience person gives you vived application and saying, can you actually make this instead of opening your data ticket and you're the person from that team breaking your internal application? Don't be gray. I would take that over a word document any day of the week. Yeah, kind of. This is, I mean, it's not working, right? It's, it's, it's, I understand that. I've been told by CEO, you know, you remember how last week I exposed passwords. Now I understand that I cannot do that, right? I'm not doing it again. I promise. But here it is, right? This is what we really need. Conceptually, this is a mock that alone is is tremendous help because alternative is I give you a jitter ticket that doesn't explain what they really need because they don't know what they need. Then you work on it and then you give it to me and I say, that's not what they need. You know, the cycles and then it takes half a year just to get to some decent point where and and it's, it's not that we're not getting there because I don't know what I'm doing or you don't know what you're doing, but because we don't understand each other, we don't, we don't really click and manage to speak the same language and you just give me the application that will be thrown to trash, but they know what you want. I think really done correctly a person vibing paired with somebody that knows the full context of the company, whether they actually physically know it or they know how to interact with that full context of the company, that pair, you know, going back to the two pizza teams, this is the one pizza team, having somebody that has the business domain knowledge of the problem to be solved and with somebody that's technical because usually the business person isn't technical and usually the technical person isn't business. You can even say you know what I'm not throwing your outcome to trash. I can build some kind of mechanism system filters, call it whatever you want, that you give me your stuff and then I hands it with with my things to make it production ready. Why not do that? I'm going to pass it through security scanners. I'm going to check whether there are any confident, there is a confidential information, I'm going to check that it applies our coding standards and what's not, right? Whatever the rules are. And guess what? You're probably already having those rules. Anyways, we already do security scanning, right? We already have policies that prevent certain things from happening. We already have code reviews, right? We already do all those things. The major issue with that, a hypothetical HR person by coding it without really knowing what's happening is that the outcome will increase the amount of work we need to do, right? Kind of like it will be a bigger review, correct? It will probably detect more security issues than normally, right? But that's still less work than nothing. I don't know if it's starting from scratch. Starting from a geo-ticket? Yeah, from a geo-ticket, exactly. So do you prefer a working solution that has more security issues to fix the normal or geo-race? What feels better? If you answer geo-issue, you probably shouldn't be listening to us right now. Because I'm thinking about this, I mean, I hadn't really thought about this specific use case we're talking about today. But this is major. And because now I'm the technical person, the technical of the pair, and you're talking about, okay, we're going to security scanning, we're going to do all these other things. Well, again, going back to episodes to the MCP server. Maybe all that didn't exist yet. So now what I'm actually doing is I'm enhancing the MCP server. So as we get these other vibed apps from the company, now we have the standard workflow in place to make sure, okay, security scan in place, look for exposed credentials, look for just all the things. And we just keep refreshing that MCP server. And once we update that, then as new apps come in, or even better, as new things are added to the MCP server, it goes and knows to check all the other apps that it's sort of under its purview. And it's like, hey, it was good before, but we've added this new constraint. And guess what? We found something. Here's the poor request. We already put the poor request in. Go and check it out. Because that's where the human should be, again, especially in corporations. If you're running unattended, any agents, that's dangerous. Period. Today, today, I'm not saying it can't change over time, but today it's dangerous. But you give me a PR as a human to review. It's like, oh, okay, I can do that. That's where companies come in, right? Whenever we got new technology in the past, and correct me if I wrong or if you disagree, right? One of the first things that company do with that new technology is to figure out how that fits into their system. Okay, so Kubernetes, cool. What do we do security? How do we apply the same policies that we have elsewhere? Which ones do we adopt and so on and so forth? It's not something in isolation. We plug that technology into our system and build our processes and which assurances and what's not around it as being part of that system, right? We were doing that always, more or less. You just that this is so new that we haven't gotten to do it yet. But in so not so distant future, I hope that that hypothetical scenario we're talking that that will be some kind of company agent, right, that has certain restrictions and so on and so forth. It goes through the same, essentially, the same conceptually, the same process as anything else. And when that happens, then then we are talking about being faster, while still complying to the same rules or conceptually same rules. That doesn't have to be technically. The problem right now is that it doesn't. We're all assuming that no existing company policies apply to this, we somehow make that assumption. And that's wrong. But because we never did it before, I don't understand why would we do it now. I don't know what's beyond wrong, but it's beyond wrong for not because it's got to apply. I was just thinking about sort of the continuum of this. Let's say we had a vived solution from HR that was about 20% and the technical person had about 80% to do because we're now codifying, agentifying, again, making upwards, all of the processes. So then when the next vived thing comes along, maybe it's closer to 50/50. And then the next vived thing comes along, again, it's cycled through. And the next vived thing is 80/20. Now you're saying, oh no, the technical person's going to lose their job because eventually it's going to get to 100% trust me. It'll never get to 100%. It's sort of like an arrow doing halfway distance to the wall. It's never going to make it to the wall. It'll get close, but it's never going to make it. It seemed like I didn't know I had the same experience. We had this thought of in cloud up here. That was all ups going to lose jobs now. Well, yes, actually ops did lose their jobs. They became SREs. Do I love vived coding? Put me, it depends. There's a good consulting answer. It depends. Am I greenfielding something? I think it's a good idea. Am I vived coding a solution for an existing app? Maybe to test out a new feature for it? It's probably not a bad idea just to see how it works, especially if I'm new to the environment. Am I going to ship that vived code solution? High probability that I'm not going to. I still feel that I agree with you 100%. But what I feel is the main reason for those answers is that whatever you're using for vived coding, that's completely disconnected from everything else. It's almost like for many of us, and I'm the first one to me, this applies to me as well. It's disconnected from the company. It's disconnected from the system. It's completely almost like hobby that we're doing right now. We need to get to the phase that this is serious. This is institutionalized. I'm going to use Kubernetes as an example. You can do QBDM, you can do this and that. But then the company makes a decision and says, "OpenShift." It's set up over there and has the rules and now go use it. That's what's missing. Now, whether or after that it will be helpful 5% or 95%, I don't know, right? But we're missing that phase that actually, it's not, you just downloaded from internet and a plot code, but it needs to be part of the system. Then it will be counter-use. But until that point, expect plenty of press releases about companies that have exposed passwords, credit cards, ages, security numbers, you name it. What do you think? How bad is it really going to be? Whatever it is, the Slack workspace that for the podcast channel, and look for episode 323 and leave your comments there. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. A contact information and a link to the Slack workspace are at DevOpsParadox.com/contact. If you subscribe through Apple Podcast, be sure to leave us a review there that helps other people discover this podcast. Go sign up right now at DevOpsParadox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOpsParadox.