Building a rope bridge over a chasm takes few resources and little time. It’ll get the job done for a few people traveling across, but probably won’t hold when a truck goes across. That’s not what that design is meant to do.
The world of vibe coding is much the same. It’ll get your idea up and running enough to test and refine, but, like a rope bridge, isn’t built for all goals. You have to know when and what to use vibe coding for to make the best use of the technology, especially now that vibe coding is growing in usage.
According to a 2025 Stack Overflow Developer Survey, around 84% of devs say they use or plan to use AI tools in their workflows, and 51% of professional developers use them daily. A similar State of Developer Ecosystem 2025 report from JetBrains puts AI use higher, at 85%, with about 62% of devs relying on at least one dedicated coding assistant.
At Innowise, we take the time to test and review AI-generated and vibe-coded applications. That includes projects our own teams have accelerated with these tools, as well as code from other teams that we are asked to inherit, secure, or rebuild. However, it’s important to put those observations in perspective. The insights here come from that practical experience rather than general commentary about where vibe coding is headed.
What is the Current State of Vibe Coding?
Vibe coding means writing out what you want in a plain-language prompt via tools like Claude Code, GitHub Copilot, Cursor, Replit, or Lovable, and letting the tool produce a working implementation. In the beginning, this meant you could quickly test whether an idea was worth pursuing, with something built to be judged and potentially discarded. That was the first use, and it hasn’t disappeared.
Now, AI-generated modules can also integrate into the outcome, becoming permanent parts of the product, but sometimes not carrying a record of how they were built. In the example of a sign-up flow, the prompt may request something modern and secure, and the interface may appear to deliver on that request. But the password reset step often accepts a request based only on an email address, without proper verification behind it. The flaw only appears when put in use, often hidden in the interface until someone asks the wrong question.
“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,” says Dmitry Nazarevich, Chief Technology Officer of Innowise.
Where Vibe Coding is Beneficial
There is an undeniable business case for getting into vibe coding development. It’s most often seen when applied to:
- MVPs/Investor-Facing Prototypes: Getting a working model going quickly rather than a polished finished product.
- Internal Tools/One-Off Automations: Solves a simple problem without the need for enterprise-grade architecture.
- UI/UX Drafts: Testing customer-facing interactions before committing engineering time and resources.
- POC Work: Proving the concept of an idea before anyone worries about whether it is secure.
Consider the use case of a small logistics team. They’ve been tasked to build a freight shipping quote tool. Over the weekend, they use prompt-based vibe coding to get a working model up and running. By Monday, they can present a clickable proof of concept to investors instead of a static slide describing what the product will eventually do. Being able to compress that distance between ideation and a decision about whether to fund it is the best argument for using vibe coding.
The risk shows up later. The tool shows that the idea can work, but continues to run long after the business should ask a much different question: can it be trusted with paying customer data?
Where Vibe Coding Might Break First
The speed of vibe coding is useful in the early stages of building off an idea. What makes it risky is when those ideas turn into code moving closer to production or customer touchpoints.
Veracode tested more than 100 LLMs across Java, Python, C#, and JavaScript. They put out a 2025 GenAI Code Security Report to show those results. They found that AI-generated code introduced a security flaw in 45% of coding tasks. In an update in 2026, that figure had barely moved.
Syntax correctness climbed from 50% to above 95% since 2023. However, security pass rates hover around 55%, regardless of release date or model size. There is no arguing that models are reliable at producing runnable code. Where they fall short is in producing code that is resistant to misuse.
You can see that breaking point in public incidents. Moltbook, an entirely AI-generated application, suffered a breach exposing 1.5 million API tokens and 35,000 email addresses. AI never flagged that there was a misconfigured database.
These common failures appear minor at first. Maybe an admin panel ships without a proper authorization check. Then a comment marks where one should go. That comment may survive review, but the check never arrives.
“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,” says Eugene Govor, Head of Embedded & C++ at Innowise.
Why Speed and Production-Ready Are Not the Same
What catches most teams out isn’t a dramatic failure, but the absence of anything visibly wrong. Features may appear complete with a fully rendered interface, the endpoint responds, and the happy path test passes, so the team moves on — even though they may lack the authorization logic, dependency hygiene, logging discipline, or handling for the case nobody thought to test.
Each new round of prompting in vibe coding can add a new security risk to the code. When a model is tasked to extend what is already generated, it can introduce new gaps, not close old ones.
All that said, vibe coding does have space in business workflows. It fits comfortably in prototypes, internal tools, proof-of-concept work, and UX drafts. It’s more of an accelerator for work that can be disposable if the idea doesn’t pan out.
Vibe coding may not be a good fit in high-security or sensitive-data industries. That includes fintech, banking, healthcare, anything touching payments or personal data, or any system where a regulator will examine it. A rope bridge may work well for a one-off crossing, but not as a reliable supply route for a community. That difference has nothing to do with how well the rope bridge worked on day one.
Where Vibe Coding May Need a Stricter Approach
Most modern teams aren’t choosing between AI and traditional development. They focus on the parts that need different levels of scrutiny. It’s a more flexible workflow, such as:
- Vibe coding the first draft of a feature or boilerplate.
- Reviewing the output before integrating into the real codebase.
- Refactoring duplicated or inconsistent logic before it compounds into technical debt.
- Adding the tests and security checks a human decides the feature actually needs, not just what the model happened to generate.
- Designating an experienced engineer as accountable for the architecture and the final call on security and compliance.
This type of flexible workflow that utilizes vibe coding is more aligned with “agentic” or AI-assisted development. It doesn’t ignore the benefits of vibe coding, but it also ensures AI tools aren’t used without supervision, especially on sensitive information.
Vibe Coding Guardrails Worth Utilizing
“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. None of that is unusual. It is a discipline that has to keep pace with a much faster development cycle,” says Stanislav Kazanov, Head of GRC, Cybersecurity & Sustainability at Innowise.
This framework of utilizing vibe coding provides a much safer solution. A few other practices have proved to strengthen such a framework:
- Security-focused prompts defining 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 (as AI can pull outdated or nonexistent package names).
- Runtime testing because static scans alone can miss issues appearing only when code runs.
How Developers Are Adjusting to Vibe Coding
In commercial aviation, autopilot didn’t mean pilots were suddenly made obsolete. It shifted their work from operating every single control to monitoring the system, understanding what normal looks like, and taking over the moment something didn’t seem correct.
Current developers are moving through much the same transition. Engineers can now direct AI models, review output, and still design systems from first principles — skills that are becoming more valuable. More of the routine writing is being delegated to prompts, while the engineer remains responsible for reviewing and shaping the result.
“AI can build fast, but it cannot reason about trust. Every function it outputs is a potential liability until a person has checked it. Letting vibe coding run unsupervised will not bring much to a business. The real value comes from using its speed to test more ideas, then applying the same engineering discipline to the ones worth keeping,” continues Dmitry Nazarevich, CTO at Innowise.
Asking Crucial Questions Before AI-Generated Code Ships
Before AI-generated code ships, ask the team:
- Which parts of this product were AI-generated? The team should be able to answer this without a special investigation.
- Who reviewed the outputs and against what standard? Have we done more than a passing demo by assigning accountability to a named reviewer with a standardized checklist?
- What happens if one of them fails? The answer determines how much scrutiny that piece of code deserved in the first place.
Teams capable of answering these questions are using vibe coding in a way that leverages its value. They are moving much faster on ideas without losing the architecture, security, and accountability that still belong with people. Teams that cannot answer these questions are not necessarily in trouble. They simply do not yet know the full extent of their exposure.
BIO:
Philip Tikhanovich is Head of Big Data at Innowise, with over 10 years of experience in data engineering and AI. He sets technical direction across Python, Big Data, and ML/AI teams while staying hands-on — reviewing critical data workflows, making core architecture decisions, and contributing directly to solving complex data challenges. Over the past decade, Philip has worked across eCommerce, FinTech, game development, and manufacturing, helping businesses turn raw data into actionable insights and business value. His expertise spans Big Data and AI/ML platforms including Databricks, Snowflake, Apache Spark, and Apache Airflow, across AWS, Azure, and GCP.
