Aug 7, 2026

Inside the vibe coding playbook: what works, what breaks, and who stays accountable

Head of Big Data, Innowise

FOR PRESS USE: Feel free to use excerpts, statistics, or quotes from this material for your reporting.

A rope bridge can get a person across a canyon in an afternoon. It will hold their weight and get them to the other side, and building it takes a fraction of the time an engineered crossing would. Nobody drives a truck over it, and nobody expects to. Vibe coding occupies roughly the same place in software delivery right now. It is fast, it works, and knowing what it is not built for matters just as much as knowing what it is good at.

84% of developers say they use or plan to use AI tools in their work, and 51% of professional developers use them daily, according to the 2025 Stack Overflow Developer Survey. JetBrains puts regular usage even higher, at 85%, with 62% of developers relying on at least one dedicated coding assistant, according to its State of Developer Ecosystem 2025 report.

At Innowise, we regularly review AI-generated and vibe-coded applications. This 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. This digest draws on that pattern of observation rather than on general commentary about where the technology is headed.

What vibe coding actually is now

Vibe coding means describing what you want in plain language and letting a tool such as Claude Code, GitHub Copilot, Cursor, Replit, or Lovable produce a working implementation. It started as the fastest way to test whether an idea deserved to exist at all, something built to be judged and then discarded. That first use has not disappeared. It has been joined by a second one: AI-generated modules that quietly become permanent parts of a product, without always carrying a record of how they were built.

Consider a typical sign-up flow built this way. A prompt asks for something modern and secure. The interface delivers on the first half of that brief. The password reset step often does not. It may accept a reset request using only an email address, with no verification step behind it. The flaw is invisible in the interface. It only shows up in what the system does when someone asks it 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.

Dmitry Nazarevich Chief Technology Officer, Innowise

Where it earns its keep

The business case for vibe coding development is real. It shows up most clearly in four kinds of work:

MVPs and investor-facing prototypes, where the goal is a working version fast, not a finished product.
Internal tools and one-off automation that never needed enterprise grade architecture in the first place.
UX and UI drafts that let a product team test an interaction before committing engineering time.
Proof-of-concept work that has to answer whether an idea works at all, before anyone worries about whether it is secure.

Take a small logistics team building a freight quoting tool. They build a working version through prompts over a weekend. They walk into an investor meeting on Monday with something to click through, instead of a slide describing what the product will eventually do. That is the strongest argument for vibe coding. It compresses the distance between an idea and a decision about whether to fund it.

The risk shows up later. The tool built to answer whether this idea works keeps running long after the business starts asking a different question: can it be trusted with a paying customer’s data?

What breaks first

The same speed that makes vibe coding useful early on is what makes it risky once the code moves closer to production.

Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across Java, Python, C#, and JavaScript. AI-generated code introduced a known security flaw in 45% of coding tasks. A follow-up update from Veracode in spring 2026 found that this figure has barely moved. Syntax correctness has climbed from around 50% to above 95% since 2023. Still, security pass rates remain close to 55%, regardless of model size or how recent the release is. Models have become reliably good at producing code that runs, but they have not become reliably good at producing code that resists misuse.

Public incidents follow the same pattern. Moltbook, an entirely AI-generated application, suffered a breach that exposed 1.5 million API tokens and 35,000 email addresses because AI never flagged the misconfigured database.

A common failure looks small at first. An administrative panel ships without a real authorization check. Only a comment marks where one should go. The comment survives review. 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.

Eugene Govor Head of Embedded & C++, Innowise

Why speed is not the same as production-ready

The pattern that catches out the most teams is not one dramatic failure. It is the absence of anything visibly wrong. A feature can look complete, the interface renders, the endpoint responds, the happy path test passes, so the team moves on to the next task.

What is missing rarely shows up in a demo:

Authorization logic
Dependency hygiene
Logging discipline
Handling for the case nobody thought to test

Security tends to get worse, not better, with each additional round of prompting on top of existing code. Asking a model to keep extending what it has already generated can introduce a new gap with every round. It does not close the old ones.

Where the line sits between low-risk and critical systems

Not every application carries the same cost of failure. Vibe coding fits comfortably in prototypes, internal tools, proof-of-concept work, and UX drafts. It fits anything genuinely disposable if the idea does not pan out.

It fits less comfortably in a shorter list:

Fintech and banking
Healthcare
Anything touching payments or personal data
Any system a regulator will eventually examine

A rope bridge is a reasonable way to cross a canyon once. It is not the structure a community builds its supply route on. That difference has nothing to do with how well the rope bridge performed on day one.

When vibe coding fits and when it needs a stricter approach

Most teams are not really choosing between AI and traditional development anymore. They are deciding which parts of a build deserve which level of scrutiny. A workable pattern looks like this:

Let AI produce the first draft of a feature or the boilerplate around it.
Review the output before it becomes part of the real codebase. Treat it the way you would treat a pull request from a contractor you have never worked with.
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 the ones the model happened to generate.
Keep an experienced engineer accountable for architecture and the final call on anything related to security or compliance.

This is closer to what people mean by agentic or AI-assisted development than to either extreme. It does not ban AI tools, but it does not let them run unsupervised on anything that matters.

Guardrails that hold up in practice

Beyond that baseline, a few practices have proved effective:

Security-focused prompts that define what “done” means, including input validation and authorization rules, not just working functionality.
A self-review pass, where the model checks its own output against known vulnerability classes before a human ever sees it.
Dependency and supply-chain checks, since AI tools can pull in outdated or nonexistent package names.
Runtime testing, because static scans alone often miss issues that only appear once the code is actually running.

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.

Stanislav Kazanov Head of GRC, Cybersecurity & Sustainability, Innowise

How the developer's role is changing

Commercial aviation offers a useful comparison. Autopilot flies most of a modern flight, but pilots have not become unnecessary as a result. Their work has shifted from operating every control to monitoring the systems, understanding what normal looks like, and taking over the moment something does not.

Software engineering is moving through a version of the same shift. Engineers who can direct a model, review its output critically, and still design a system from first principles are becoming more valuable. More of the routine writing gets delegated to prompts every year.

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.

Dmitry Nazarevich Chief Technology Officer, Innowise

Three questions worth asking before AI-generated code ships

Which parts of this product were AI-generated? A team should be able to answer this without a special investigation.
Who reviewed them, and against what standard? A passing demo is not a review. A named reviewer and a checklist are.
What happens if one of them fails? The answer determines how much scrutiny that piece of code deserved in the first place.

Teams that can answer all three are using vibe coding the way it earns its value: moving faster on ideas while keeping architecture, security, and accountability where they have always belonged, with people. Teams that cannot answer them are not necessarily in trouble. They simply do not yet know the full extent of their exposure.

FOR PRESS USE: Excerpts, statistics, and quotes from this material may be used for reporting, with attribution to Innowise.

Inside the vibe coding playbook: what works, what breaks, and who stays accountable

What vibe coding actually is now

Where it earns its keep

What breaks first

Why speed is not the same as production-ready

Where the line sits between low-risk and critical systems

When vibe coding fits and when it needs a stricter approach

Guardrails that hold up in practice

How the developer's role is changing

Three questions worth asking before AI-generated code ships

Contact our press office

Thank you!

Contact our press office

Thank you!