Every few weeks I get some version of the same call. Someone built an entire product in an afternoon using Lovable, or Replit, or Claude, or one of the thousand other vibe coding tools flooding the market right now. The demo looked incredible. The client was thrilled. Then, a few weeks in, something breaks in a way nobody can quite explain, because nobody actually defined what the system was supposed to do in the first place. Right?
That is not a tooling problem. That is a thinking problem. And it is the conversation I want to have before we talk about any specific tool, because the tool was never going to save you. The engineering was.
The data already told us this was coming
By late 2025, 84 percent of developers were already using or planning to use AI coding tools, according to Stack Overflow’s own survey of its community. That adoption number is not the problem. The problem is what is happening underneath it. GitClear analyzed 153 million lines of code between 2021 and 2024 and found that code duplication, the technical term for copy-pasted logic standing in for reusable, well-designed components, jumped 48 percent, while refactoring, the disciplined work of cleaning up and restructuring code as a system grows, collapsed by 60 percent. People are generating more and revising less. That is the opposite of good engineering.
Then there is security, which is where “it worked in the demo” turns into “we have a breach notification to send.” Apiiro’s research across Fortune 50 codebases found a tenfold increase in security findings tied to AI-generated code between December 2024 and June 2025, with 45 percent of AI-generated code containing a security vulnerability of some kind. Carnegie Mellon researchers found something even more specific, and honestly more useful: 61 percent of AI-generated code functioned correctly on the first pass, but only 10.5 percent of it passed a real security review. Functional and secure are two completely different tests. A vibe coding tool will tell you when your code runs. It will not tell you when your code is a liability.
Why this happens, in plain terms
Here is the plain-English version of what is going wrong. A large language model is a prediction engine, the technical term for a system that generates the statistically most likely next piece of code based on patterns it has seen before. It is not a systems engineer. It does not know your business rules, your compliance obligations, your data retention policy, or the fact that your billing logic and your user authentication have no business touching the same function. A software engineer knows those things because a software engineer does the thinking before the typing. A vibe coding session, by design, skips straight to the typing.
So the fix is not “stop using AI to build.” Tool agnostic has always been our position at UnDesto AI, and that has not changed. The fix is applying the same design discipline to a fifteen-minute AI build that a good engineer would apply to a fifteen-week build. Just faster.
What to do before you ever open the tool
This is the part almost nobody teaches, because it is not exciting and it does not demo well. But it is the entire difference between a tool that compounds your business and a tool that compounds your technical debt. Before you type a single prompt into Lovable, Replit, Claude, or whatever launches next month, walk through this.
- Write the requirement in plain language first. Not a prompt. A requirement. What does this system need to do, for whom, and what does it need to never do? If you cannot say it in one clear paragraph without the word “AI,” you are not ready to build it with AI.
- Draw the boundary. Systems engineers call this scoping the system boundary, the technical term for deciding exactly what is inside your system and what is outside of it. What data does this touch? What other systems does it talk to? Where does it stop?
- Separate your concerns before the model does it for you, badly. This is the single responsibility principle, the old, unglamorous rule that says one piece of your system should do one job. Vibe coding tools love to jam authentication, business logic, and data handling into the same function because that is the fastest path to a working demo. Fast and correct are not the same thing.
- Decide your definition of done before you start, not after. What does finished actually mean here. Working. Secure. Documented. Tested. Pick your criteria before the tool hands you something that looks finished but is not.
- Know what you are willing to hand to the machine, and what stays with a human. This is the heart of our A.S.K. Framework™: Automate what should be automated, Share the work that benefits from a human and a tool collaborating, and Keep Human the judgment calls a prediction engine has no business making alone. Architecture decisions, the ones that determine whether your product can scale or collapses under its own weight, stay in the Keep Human column. Always.
Do that work first, and the tool becomes what it was always supposed to be: a fast, capable pair of hands attached to a brain that already knows what it is building. Skip that work, and you are not vibe coding. You are gambling with other people’s data and calling it innovation.
Want an easy guide that you can use to adopt this new way of thinking about your next vibe code project? Download our guide: Vibe Engineering Guide_1
The BS detector is on
There is so much noise in the AI space right now that it is genuinely hard to tell who is building something real and who is selling you a slide deck. A lot of AI consultants will hand you a strategy document and disappear before the execution gets hard, leaving you exactly where you started, minus the money. We do not do that at UnDesto AI, and it is exactly why we built our Shadow IT Audit and our Prompt Architecture training the way we did: to help teams find where unmanaged AI tools are already quietly running through their business, and to teach the habit of building rigorous, repeatable logic before anyone opens a coding tool at all.
You do not need to abandon vibe coding. You need to stop treating it like a shortcut around thinking and start treating it like what it actually is: a power tool that rewards the operator who already knows how to build.
Related reading
- Maximize ROI by Evaluating AI Tools for Business Automation
- Why Copilot Is the Best Solution in an M365 Tenant
Want your team to work through this hands-on? UnDesto AI runs AI training and workshops built for enterprise teams. Start a conversation.