When AI Builds the App, Who Owns the Risk?

Brian Moody: Good day and welcome back to WhiteDog SoundBytes. Today we're going to be covering an additional topic kind of along our lines of AI agents and it's when AI develops the app, who owns the risk? And really what we're tying back to now is touching into the area of vibe coding and really how AI and kind of automated apps and automated products are coming into production. And here to help me unpack this topic a bit is the expert I lean on, Shahin Pirooz.  

Shahin Pirooz: Hi, thank you. Yeah, this is a fun topic. I've got developers on my team who are like, there is no chance I'm going to support a vibe coding app. I don't care who wrote it. And then there's the other side, which is there's a ton of productivity that comes out of being able to leverage vibe coding to accelerate development.

Brian Moody: Well, I think if we look at kind of historically how applications kind of came to be, the kind of level of testing, proofing, understanding security. You know, really there's applications that look at the code to make sure that everything is as efficient as it could be. Today, now we're plugging into AI and AI is doing all that and doing it very quickly.

Shahin Pirooz: Yeah, the big issue is we've got people who don't have development experience that are leveraging—let's just focus on Claude Code since most developers and most people are shifting towards Claude Code for development. There's other AI platforms, frontier platforms that can do code, but a lot of people are leveraging Claude Code right now for doing their coding. And the fundamental issue isn't that we've got AI writing code because it can accelerate a developer's timeline by, let's say you get stuck oftentimes as a developer, you're stuck on a thing, you don't know how to write a specific algorithm and you say, to a teammate, to a peer, I'm trying to do this thing. I'm kind of stuck on this. What do you think? And you're able to break through that and move forward.  

‍

Take that now and accelerate it 100-fold by being able to go to Claude and say, I want to do this thing. What are the best options for it? And it pumps out an algorithm, a function, and you're able to take that function and tweak it and adjust it to meet what you want, either by having Claude making the tweaks or as a developer doing the tweaks yourself. And now you've accelerated development by 100-fold. So phenomenal potential productivity that comes out of it. When you're not a developer and you say, I want to build an app that takes a rocket and goes to the moon, I will never get on that rocket. That's all I'm saying.

Brian Moody: Well, I think one of the key things that you— the kind of scenario you're bringing up is you said, okay, folks that are working internally within the organization. So within your organizations, your teams may be using vibe coding to advance, and as Shahin just mentioned, 100 times productivity of getting something to market or getting something to the—

Shahin Pirooz: Yeah, that's more of a feel the air, don't quote me.

Brian Moody: But there are a lot of really good things about utilizing AI and utilizing vibe coding in order to advance an application. But the scenarios brought up are colleagues that are working with kind of internally within your organization where we are, we're fact-checking or even co-checking one another back and forth. I think one of the greater concerns is the amount of organizations, the amount of companies, the amount of consultants now that are presenting themselves to you, to your companies, to businesses that are calling themselves experienced application builders, and they're not. So talk a little bit about that, and really kind of, as we say, if AI builds the app, who owns the risk?

Shahin Pirooz: Well, that's a million percent the issue here. The fundamental problem with vibe coding is—and it's not as much organizations, it's typically individual consultants. So sole proprietor consultantship that's coming to you and responding to an ad you might have, or reaching out to you and saying you need a website redesign. And then you get that done quickly and you're like, oh wow, this guy's great. And then, hey, I got this problem. Are there any other things you want fixed in your environment? Yeah, I've got this linkage I'm trying to do between my ERP and CRM. Knock that out.  

And pretty soon you're starting to develop core systems that are running your business and potentially core systems that you're exposing to your customers. And this person has zero to no development experience. They're just articulate. They know how to talk to AI. They know how— they've learned how to do prompting, and they've learned how to implement skills that do what they need. So they've taken some training and they're pumping out code what seems incredibly fast in a really cost-effective way.  

However, the challenge with AI is not the first iteration. I'm sure everybody has seen all over LinkedIn and social media, the two pictures side by side, a beautiful pristine tower that says AI vibe-coded app when it first launches, first iteration. But after modifications and changes and tweaks, it looks like the apocalypse happened and the thing is covered with moss and it's like—and the reason that's the case is because of this tiny little thing called context window.  

These generative AI platforms have a context window of a certain size. So if I'm talking to an AI platform, let's pick Claude Code—not to pick on them, but just let's pick that one—and I'm having a dialogue with Claude and I'm trying to build a web application. And let's say, for example, for simple context, I want to write a mortgage calculator application. So I start with a mortgage calculator, I build this thing, then I realize mortgage calculator isn't enough. If I'm a lender, I need probably 14 other calculators and some forms to feed into this thing. I need an application to integrate all of them together and make it unified so that I can present that to my customers. I need an intake form for customers. I need a place where they can go find their documents, and scopes keeps getting bigger and bigger.  

As that scope increases, I have to go back to that original application that was a mortgage calculator that I wrote that I added features to. And every time I added features, I increased the context that Claude has to read every time I go back in to add a feature. There is a point where Claude exceeds its context window when it's reading your application in. And when it does, that means—think about as I get older, I have to have little notes to remind me of things because my context window has shrunk as I got older. I don't remember what I talked about a week ago, 2 days ago, whatever it is. Same thing happens with Claude, except it has a hard limit on memory, not just getting old. It has basically got a context window of a certain size.  

And if you exceed that size, now everything that happens is what you hear in the market as hallucination. So it starts hallucinating. It starts creating pathways in your code that make no sense, that go nowhere. It starts duplicating code. It's not creating reusable code. It's rewriting the same code over and over again in different areas of your application. So you get a ton of technical debt 100 times faster than building the application yourself.

Brian Moody: Well, I think the other aspect, if you go back to, again, historically the governance and security aspect—

Shahin Pirooz: We're not even there yet. I'm just simply talking about bad code.

Brian Moody: Well, right.  So let's go there. Talk about that. So, before the proofing of the code, the proofing of the application, the governance needed to integrate it into our environment, the security protocols of how it interacted, who had permissions, what it had permissions to, as you start to grow that piece of the puzzle, you know, we're not just talking code now, now bring in that security compliance and governance aspect of it.

Shahin Pirooz: Yeah, it's less about what it has access to, because ideally the application is a constrained ecosystem. It's probably going to have its own database, it's probably going to have its own whatever to build, because frankly most of these 5 coders don't have the knowledge how to integrate it with your enterprise applications.  

So, first pass, let's just say it's a dedicated isolated application. Well, we can expand on enterprise integrations and how much more risk there is with that, but let's just narrow the scope down to a single application that has its own components and stack. We spent decades teaching our developers to shift left, which meant move security context or awareness to the beginning of the development cycle as opposed to writing an application and then trying to figure out how to layer security on top of it. That shift-left methodology went to the path of when you're doing a CI/CD pipeline and you're doing continuous integration and continuous deployment, that continuous integration piece needs to embed in it functionality and features that test the platform for security, not just for operations.  

As we go down this vibe-coding path, that isn't an inherent part of the way these applications are written by the AI. AI is just learning from code samples that other people have. So if those code samples had a SQL injection in it, that piece of vibe code will probably have a SQL injection in it. So what's the way we solve this problem?  

We started out with doing static application security testing, SAST. SAST was, we point at the code repositories and we look for flaws in the code. We have a scanner that goes through the code and looks for things—using the OWASP Top 10—are there problems in this code that are going to create a flaw when we launch it. You need a SAST solution. Bringing in a vibe coder that doesn't have that knowledge and doesn't know SAST is critical, and they just built an application and threw it over the fence and said, "Here's the code." It goes in your repository. Good luck. Have a nice day. If you want another feature, I'll go back and talk to Claude. That's not gonna get you that SAST capability.  

The next level we went to was Dynamic Application Security, DAST testing. And DAST was basically DLLs that you would embed into your code or objects that you would embed into your code libraries that could see flaws in the code dynamically while it was running. So, as it's running, it would see what's going on and what's active and find flaws in the code. And then we said, "You know what? That's not enough. We need to do pen testing."  

So, we need to do application pen testing and see if we can black box break into an application and see if there's flaws or vulnerabilities or exploits. Now, fast forward to today, and if you do not have an application security posture management solution that covers all of those areas, you darn well better not leverage somebody who writes a vibe code application and throws it at you, even if you got it for $500 and it was so quick. It will be fine for the first iteration, but the minute there's a bug in it, the minute there's a flaw in it, code duplication rather than code reuse will cause more problems for you and create more paths of an attack surface that a bad actor can take advantage of.  

And if you start putting your customer data into these applications and that data gets exfiltrated from this application that has no security context, you are now—you're at risk.

Brian Moody: You're at risk.

Shahin Pirooz: Nobody's going to go after the developer. You're the one who put the customer data in that application.

Brian Moody: Are there methods that a customer, if they do hire someone, I mean, how would they know necessarily if firm or the consultant that they've hired has just vibe-coded something and tossed it over the fence?

Shahin Pirooz: There's no quick and easy way to see if something was vibe-coded or not, unless you look at the code. And it's pretty obvious to a developer that something is vibe-coded. We can figure it out in minutes. And it really has to do with a lack of application code reuse. So code reuse means if I have a function that prints something, I'm not going to write that print method in every place I need to print. I'm going to write a function, and I'm going to call print every time I want to call print. So I wrote that code once, and I can reuse it throughout my application all the time.  

Typically, in vibe coding apps, because of the context window and they forget that they wrote something, they're going to rewrite that print function throughout every single piece of code that they wrote. Every time you need to print, they're going to write a print function. And sometimes you're going to get paths that don't go anywhere because it was rewritten, but later on they realized there was a piece of code and they reused it. So there's a function that never gets touched. So you'll start to see little anomalies like that in vibe code. So a developer would be able to pick it out, but if you had a developer, you probably wouldn't outsource to a vibe coder in the first place.  

So the short answer is it's hard to tell that. What can a company do is, if you just knew a company that was really good at security and had an application security posture management solution, you could pick up the phone and call WhiteDog and say, "I want to scan this application. I've got this thing before I accept it and put it in production. Let's see if there's any problems with this code."  

And that scan can quickly identify, wow, there's all these exploits, there's all these vulnerabilities in that platform. We can do the static, the dynamic, and the pen testing side of it to be able to tell you there's a flaw, and not only be able to tell you there's a flaw, be able to tell you when we pen tested it, here's what we were able to do, and by the way, here's where it was in the dynamic run of the code, and finally, here's in the actual code, the static part of it, where it is and what you got to do to fix it. So that helps to fix the flaw. It doesn't help to fix bad code. So the bad code exists, the duplication of code is there, the lack of reuse, the lack of proper coding cleanliness and technique, those things are all still there with vibe coding.  

But the key thing to pull away from this, I'm not saying don't take advantage of it, I'm not saying, walk away from every vibe coder because, hey, they're putting out a product that needs and meets your needs and gets something done. Just don't do it blindly because at the end of the day, when something goes wrong, nobody's going after the developer of the application. They're going after the person who has that application in production.

Brian Moody: So it's interesting, if you followed along our SoundByte series, we've talked about shadow IT and the security risks that were associated with shadow IT. But the interesting thing about shadow IT was really folks within the organization setting up IT infrastructure and, in most cases, applying approved application to that infrastructure. But they needed the compute and the storage or whatever to set up.

Shahin Pirooz: And now they went to AWS and spun up some servers without telling anybody.

Brian Moody: Well, right. The security aspects of that were one thing that we've talked about at length. What we're really talking about here is shadow engineering.

Shahin Pirooz: To a degree, it's shadow engineering. There's shadow AI. There's all kinds of shadow people out there.

Brian Moody: Got to watch out for those shadow people.

Shahin Pirooz: I know.

Brian Moody: So, so talk a little bit more on kind of the security side of this. Where do the cybersecurity aspects of this emerge in this? For our customers and partners and folks listening, where are some key things that they need to be concerned?

Shahin Pirooz: So let's take the concept of shadow anything and talk about why it's important. So shadow IT really came about when all the SaaS companies started coming out. You had marketing going out to an online marketing firm like Marketo—or any pick any marketing company—and outsource CRM to a hosted SaaS-based CRM solution. Because IT wasn't maintaining and keeping up with the requirements for marketing. You had sales going out to Salesforce and other SaaS-based CRM solutions because IT wasn't able to spin up a CRM solution for them. So people were going and finding a way because IT wasn't able to keep up with the demand.  

Marketing or sales needed a server to test something, and IT couldn't keep up with the demand. They went to AWS and spun up a server in AWS, and now all of a sudden the company has IT spend on corporate credit cards across hundreds of people, and finance has no visibility into that IT spend. IT has no visibility into that IT spend, and it just looks like expense budget that's coming through for miscellaneous. So similarly, there's a limited amount of developers or engineers in your company, and those same shadow people within your company need an application to do a thing, and when they come to engineering and they say, we want this thing. “Yeah, it's on the list, there's 500 things ahead of it, we'll get to it when we can, sorry.” Brian's heard this from me 1,000 times, which is why he's laughing.  

Brian Moody: It's on the roadmap.

Shahin Pirooz: But in any case, you get this issue where people are having to go outside to get what they need done, because there aren't enough resources, time, money, whatever, in the organization to meet everybody's demands. And the implication of that is now you've got these applications that are potentially written by somebody who's not a developer, vibe-coded, brought into your environment. IT and security have no visibility over the fact that it was written. They have no visibility in the fact that it's now running on AWS on a credit card. Or some Substack or some other place that you're not aware of.  

So these platforms are coming up and running without any visibility, and you won't know they're there. They're just operating in your environment. You've got the security hole, this risk that's happening, and that's where being able to detect these applications, being able to detect things that are coming into the environment is critical. And that's where our Shadow IT and Shadow AI capabilities really shine because we can help give visibility to what's running, what are people going to. If all of a sudden everybody in marketing is going to this AWS server that nobody knew about, what's going on here? Let's take a look at this and oh, what's this application? And that gives you visibility into what's going on.

Brian Moody: So for enterprises, there's a lot of productivity components. There's a lot of positive to vibe-coding with respect to productivity and advancement in your application.

Shahin Pirooz: AI in general, like we've been saying for ages, if you don't enable your people to be able to leverage AI—we've said repeatedly, don't be an ostrich, don't dig your head into the sand and hope this problem goes away. I just wrote an article this morning that basically is about Mark Zuckerberg just came out with a manifesto for AI and about how AI needs to be open and we can't prohibit innovation. We have to enable innovation. And it's so accurate in the context of what we're talking about right now. You cannot hide behind this, "Let's restrict access." You have to figure out how to govern and secure it and put guardrails around it, but enable innovation, enable productivity, because these things are making your people faster. They're making your output to the customers faster and potentially in some cases even more clean and better because they're writing better English than some of us are capable of doing.

Brian Moody: We just came back from an event in New Jersey, and the entire talk track of the event was from an AI perspective: you need to move your business to utilization of AI, agentic workflows, or you're going to fall behind.  And it wasn't that you are going to be replaced because you do things traditionally. You're going to be replaced by somebody that's got better, faster, more productive processes than you because they're more efficient, and they're bringing a greater advantage to a business.

Shahin Pirooz: A great friend of mine, Niraj Tenany, he's the CEO of Netwoven, paid me a compliment on LinkedIn and said, “I saw Shahin speaking about this. And once you hear it, you can't unhear it. Start hearing it everywhere. It's not that AI is going to replace your employees. AI will not replace your analyst. You will have an analyst that is AI empowered. AI will not replace your salesperson. You have a salesperson that is AI enabled. AI will not replace marketing. You have a marketing person that is AI enabled.”  

So it's enhancing their capability to do what they do better, faster, and with more accuracy. And as soon as we get our head wrapped around this notion of AI-enabled workers, whether they be agents that are digital workers or humans that are carbon workers, AI-enabled workers are going to help your company move forward. Without them, you will fall behind and your competitors will take the advantage.

Brian Moody: Well, I think some of the things we've talked about too is around AI agents or you can apply it here to applications is assign an owner. So one of the things that I really have learned from you and taken from you, because you talk about this all the time,is assign an owner to it, someone that has oversight. Set the guardrails, set permissions. Do not over-provision the agents and/or applications. Do not allow them, in a sense, to go outside of these so-called guardrails. And better, tighter guardrails, global to start off with and then find a mistake.

Shahin Pirooz: And just like Tolkien, you have to have one ring to rule. It's one owner per one thing. You can't have multiple owners for a thing. Everything has to have a single owner for accountability. And if you have applications, agents, whatever, without owners, you have a lack of accountability and a lack of visibility.

Brian Moody: So some takeaways. One of the questions I was getting to is your recommendations on how enterprises take advantage of this feature functionality, take advantage of vibe coding, but how do they take advantage of what they can do with it today, but then also implement some guardrails to protect themselves?

Shahin Pirooz: Again, with these things, we like to leave you with something. So there is a one-sheet that talks about the takeaways from this and what to look for. And what to inspect and what to think about. So that will be posted along with this livestream, so you'll be able to get that after this event.  

Also, think about some of the things we talked about. You have to be able to understand the shadow IT engineering AI that's happening in your environment, and if you don't have a partner company that can help you figure that out, give us a call. We do that and we do it very well. And in addition to that, if you don't have standard security posture management capabilities for being able to do what's your external posture look like, your internal posture, your application posture, your identity posture, those are all products in our portfolio capabilities in the attack surface management space that help you understand, what would a bad actor take advantage of if they came into my environment and tie those together. And now you've got a system to go forward with that gives you visibility.  

Visibility is the first step. Know what you have before you understand how to govern it and how to govern it. And then there's tools and technologies we can help you with as well there. The one thing I would say is I encourage everybody who's got developers to empower those developers with something like Claude Code, enable them to be able to accelerate their development. Developers are going to do more with less if they have access to an AI coworker. The other side of this, the vibe coding side of this, I think there's a significant amount of risk of taking on vibe coded applications from external developers that potentially have no coding experience. There's some vibe coders that are doing all the right things. They're hiring proper developers to inspect the vibe-coded work just to make sure everything looks good and there's no obvious security flaws in the platform, and look for things like code reuse rather than code duplication.  

So there's some vibe coders that understand the implications of what they're doing and are trying to help. But generally speaking, vibe coding without any kind of governance or control or having a subject matter expert on your own that could look at that code is a huge risk. And I highly encourage you to be cautious on that front.

Brian Moody: So I think that's the biggest point. You kind of brought up that first example, where you have your experienced developers.They've got the ability to be able to look through the code and understand if there's something wrong there. So I would say really, as you reach out and try to expand your capability here, make sure that you've got a qualified, experienced developer on your staff, or maybe even as a consultant. Really, really vet the external organizations that you might be going to for this, because AI makes everybody look good.  

And then, as it comes down to security pieces, make sure you have the experience. And that's one of the things that I think I've been most impressed with WhiteDog. You've brought over 30 years of experience to this company. The expertise that our SOC has, that our tech team has, we're happy to engage with you on this conversation openly to either advise, or if there are things going on in your company, we can help to secure those. So please reach out to us. Always available to have a conversation. So with that, thank you for joining us today, and we look forward to next month.

Shahin Pirooz: And watch out for those vibe coders.

Brian Moody: Watch out for those vibe coders. Thank you.

‍