Vibe coding works until it doesn’t: a practical risk map
Vibe coding is not a shortcut to production. It’s a shortcut to a decision. That distinction is worth keeping in front of you, because the tools are moving faster than the habits around them.
According to the 2025 Stack Overflow Developer Survey, roughly 84% of developers say they use or plan to use AI tools in their workflows, and 51% of professional developers use them daily. A JetBrains State of Developer Ecosystem 2025 report puts AI adoption even higher, at 85%, with about 62% of developers relying on at least one dedicated coding assistant.
The adoption curve is not the problem. The problem is that the understanding of what AI-generated code can and cannot be trusted with has not kept pace with how often it’s being shipped.
️ Where vibe coding actually earns its place
The strongest argument for vibe coding is compression: the distance between an idea and something a person can click on and judge. That argument is most valid in four contexts:
- MVPs and investor-facing prototypes: A working model to show instead of a slide describing what the product will eventually do.
- Internal tools and one-off automations: Solving a simple problem without building enterprise-grade architecture around it.
- UI/UX drafts: Testing customer-facing interactions before committing real engineering time.
- Proof-of-concept work: Proving an idea is viable before anyone asks whether it is secure.
A logistics team that needs a freight shipping quote tool by Monday morning is a clean example. Over a weekend, prompt-based vibe coding gets a clickable proof of concept into the room for an investor meeting instead of a static deck. The idea gets a fair hearing faster. That is the legitimate use case.
The risk shows up when that prototype is never formally replaced. The tool shows the idea can work. The business never asks the harder follow-up question: can it be trusted with paying customer data?
⚠️ The security gap that data makes hard to argue with
Veracode’s 2025 GenAI Code Security Report tested more than 100 LLMs across Java, Python, C#, and JavaScript. They found that AI-generated code introduced a security flaw in 45% of coding tasks. In a 2026 update, that figure had barely moved.
Syntax correctness climbed from 50% to above 95% since 2023. Security pass rates stayed around 55%, regardless of model size or release date. Models are reliable at producing runnable code. They are not reliable at producing code that resists misuse.
The real-world version of that gap is Moltbook, an entirely AI-generated application that suffered a breach exposing 1.5 million API tokens and 35,000 email addresses. A misconfigured database was never flagged.
“People tend to picture vibe coding security as a web problem. SQL injection, exposed API keys, that kind of thing. In embedded and hardware-adjacent work, the failure mode is different and usually less forgiving. AI-generated C and C++ often leans on unsafe memory handling. Buffer overflows, pointer misuse, because the prompt asked for a working feature, not a memory-safe one. In a web application, that becomes a bug ticket. In a medical device or an industrial controller, it becomes a safety incident.” — Eugene Govor, Head of Embedded & C++ at Innowise
A sign-up flow is a useful illustration. A prompt requests something modern and secure. The interface appears to deliver on that. But the password reset step accepts a request based only on an email address, without proper verification behind it. The flaw only appears when someone asks the wrong question of the system.
Why the failure mode is invisible until it isn’t
What catches teams out is usually not a dramatic failure. It’s the absence of anything visibly wrong. The interface renders. The endpoint responds. The happy path test passes. The team moves on, without noticing that authorization logic is missing, dependencies are stale, or edge cases were never considered.
Each additional round of prompting can add new gaps rather than close existing ones. When a model is asked to extend what it already generated, the compounding effect works against you.
“A few years ago, if a client asked us to prototype something with AI, everyone understood it would be rebuilt or replaced before a real user touched it. That understanding has not kept pace with how the tools get used now. We regularly find AI-generated modules sitting inside systems that went live. Those modules often carry no documentation that they started as a prompt instead of a specification. That gap is exactly why review habits need to catch up.” — Dmitry Nazarevich, CTO of Innowise
The pattern repeats: an admin panel ships without a proper authorization check. A comment marks where one should go. The comment survives review. The check never arrives.
The workflow that actually handles this
Most teams are not choosing between AI and traditional development. They’re choosing how to apply different levels of scrutiny to different parts of the codebase. A more defensible approach looks like this:
- Use vibe coding for the first draft of a feature or boilerplate.
- Review the output before integrating it into the real codebase.
- Refactor duplicated or inconsistent logic before it compounds into technical debt.
- Add the tests and security checks a human decides the feature actually needs, not just what the model happened to generate.
- Designate an experienced engineer as accountable for architecture and the final call on security and compliance.
“The teams that get burned by AI-generated code are almost never the ones using AI. They are the ones treating AI output the same way they treat code a senior engineer has already reviewed. At Innowise, we treat AI code as untrusted input by default. Our developers run security scanning inside the same pipeline where the code gets generated, not as a separate step days later. We keep a named person accountable for anything that touches authentication, payments, or personal data.” — Stanislav Kazanov, Head of GRC, Cybersecurity & Sustainability at Innowise
A few additional practices strengthen that framework: security-focused prompts that define what done actually means (including input validation and authorization rules), a self-review pass where the AI checks its own outputs against known vulnerability classes, dependency and supply-chain checks (AI can pull outdated or nonexistent package names), and runtime testing because static scans alone miss issues that only appear when code runs.
Three questions to ask before any AI code ships
Before AI-generated code reaches production, the team should be able to answer these without a special investigation:
- Which parts of this product were AI-generated? If nobody knows without digging, that’s a signal.
- Who reviewed the outputs and against what standard? A passing demo is not a review. There should be a named reviewer and a checklist.
- What happens if one of them fails? The answer tells you how much scrutiny that piece of code actually deserved.
Teams that cannot answer these questions are not necessarily in immediate danger. According to Innowise’s Nazarevich, they simply don’t yet know the full extent of their exposure. That’s a different kind of problem, but it’s still a problem worth solving before a user does it for you.
When this works and when it does not
Vibe coding fits comfortably in prototypes, internal tools, proof-of-concept work, and UX drafts. It’s an accelerator for work that can be discarded if the idea doesn’t hold up.
It’s a poor fit in fintech, banking, healthcare, anything touching payments or personal data, or any system a regulator will examine. Speed to a working demo and fitness for production are two entirely different properties, and the tools don’t advertise the difference.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
