Six months ago, "we built it with AI" was a flex. Founders said it on stage at demo days. Investors leaned in. Now it's starting to show up in a different kind of conversation, the one where a business owner is explaining to a development team why their app crashes every time more than a few hundred people use it at once.
This isn't a story about AI tools being bad at writing code. It's a story about what happens when speed and understanding part ways, and what that gap costs once real users, real data, and real money are involved.
What Vibe Coding Actually Means
Vibe coding is the practice of describing what you want in plain English and letting an AI tool generate the code, then shipping it without a close read of what was actually produced. The term has only been around for a couple of years, but the workflow took over fast. Tools like Lovable, Cursor, Replit, and Bolt let non-technical founders go from idea to working app in days instead of months.
For prototypes, internal tools, or anything low-stakes, this is genuinely useful. The problem starts when the prototype quietly becomes the product. Nobody sits down and decides to ship the AI-generated throwaway version to paying customers. It happens gradually, one "while we're at it" feature at a time, until the demo is the live product and there's no real architecture holding it up.
The Pattern Almost Nobody Sees Coming
Here's what this usually looks like in practice. Week one, everything works. Users sign up, the core features run, nothing's on fire. The team feels great. They're shipping fast and nobody's had to maintain anything yet because there's been nothing to maintain.
Then a small bug shows up. Someone opens the relevant function to fix it and finds it's 300 lines long, handles four different responsibilities that have nothing to do with each other, and was clearly stitched together from several AI-generated pieces that nobody connected into something coherent. Fixing the small bug means understanding the whole function. Understanding the whole function means understanding why it was written that way in the first place, and there's no commit history or comment that explains it because nobody wrote one. The AI did, and the AI doesn't leave notes.
This is the moment a lot of teams describe as the wall. Tickets that used to close in an afternoon start taking two days. Every fix opens three new questions.
What's Actually Breaking Under the Hood
The reason this happens isn't mysterious once you look at how these tools actually generate code. An AI model optimizes for the prompt directly in front of it. It doesn't hold a mental model of your entire system the way a developer who's been working on it for months does. Each function looks reasonable in isolation. The way they all fit together is where things fall apart.
Security is where this shows up most clearly, and there's solid data behind it. Veracode's 2025 GenAI Code Security Report tested output from more than 100 large language models across 80 real-world coding tasks and found that 45% of the code samples introduced exploitable security flaws, including issues from the OWASP Top 10 list like SQL injection and cross-site scripting. Java fared worst, with a security failure rate over 70%. The report's most uncomfortable finding wasn't the 45% number itself. It was that newer, larger models didn't perform meaningfully better than older ones. Scaling up the model doesn't fix this, because the models aren't getting better at understanding security risk. They're getting better at writing code that runs, which is a different skill entirely.
The Salesforce ecosystem has been tracking a similar pattern outside the security angle. In a piece for Salesforce Ben on 2026 predictions, Salesforce MVP Paul Battisson put it about as plainly as it gets: building things faster doesn't mean you're building better things faster, it just means you're making more, faster. That sentence should probably be printed out and taped above a few investor decks.
Why This Matters More for Some Apps Than Others
Not every vibe-coded app is sitting on a ticking clock. A simple marketing landing page or an internal scheduling tool with no sensitive data attached can absolutely tolerate some messy code underneath. Nobody's getting hurt if that breaks for a day.
It's a completely different situation for anything touching payment data, health records, personal information, or financial transactions. An app handling those categories with security flaws baked into 45% of its codebase isn't carrying minor technical debt. It's carrying real legal and reputational exposure, and the bill for that doesn't show up gradually. It shows up all at once, usually after something's already gone wrong.
How to Tell If Your App Is Already in Trouble
A few signs tend to show up before things get genuinely bad:
Small feature requests are taking noticeably longer than they used to, and nobody can clearly explain why
The original builder can't walk through how a core feature actually works under the hood
Bug fixes in one area keep causing unexpected breakage somewhere else entirely
Nobody on the team has done a security review of the app's authentication, data access, or payment handling
The app has grown well past what it was originally scoped for, but the underlying structure hasn't changed since day one
If two or three of these sound familiar, that's worth a real conversation before the next feature gets added on top.
What a Proper Fix Actually Looks Like
The good news is that none of this means starting over from zero or treating AI tools as the enemy. What it usually means is bringing in developers who can read through what exists, figure out what's solid and what isn't, and rebuild the parts that need rebuilding with an actual architecture underneath them. That's a fundamentally different exercise than continuing to prompt your way through new features on a shaky foundation.
For apps that need to perform well specifically on Apple's platform, this often means working with a team that specializes in custom iOS app development services rather than a generalist shop trying to patch things up feature by feature. A native rebuild done properly accounts for Apple's review standards, device-specific performance considerations, and the kind of access control that AI tools tend to skip by default. It costs more upfront than another round of prompting. It also tends to be the last rebuild a business needs for a while, instead of the third one in eighteen months.
Vibe Coding Isn't the Problem. Unmanaged Risk Is.
None of this is an argument against using AI to build software. The productivity gains are real, and plenty of legitimate products got their start this way. The issue is treating AI-generated code the same way you'd treat a finished, reviewed product, when it's closer to a fast first draft that still needs a second set of eyes.
The businesses handling this well aren't the ones that avoided AI tools altogether. They're the ones that treated the review step as non-negotiable from day one, and brought in experienced developers before the cracks turned into a wall. The ones skipping that step are going to find out eventually. The only real variable is whether it happens on a Tuesday afternoon during a routine update, or during a security incident with customer data on the line.
