Vibe Coding Has a Security Problem, and Shipping Code You Do Not Understand Is Not a Strategy

There is a version of the AI coding conversation that feels way too casual for what is actually at stake.

A prompt goes in. A working app comes out. The demo looks clean. The login page loads. The API responds. The build passes. Everyone moves on.

That is exactly where I think the trouble starts.

“Vibe coding” has become the catch-all phrase for building software mostly through prompts, iterations, and AI-assisted generation instead of line-by-line engineering. Some of that is genuinely useful. I am not anti-AI, and I do not think serious teams should pretend these tools are going away. But I do think a lot of people are getting dangerously comfortable shipping code they do not really understand, on stacks they did not really design, with security assumptions they never actually validated.

That is not innovation. That is borrowed confidence.

The scale of adoption is real. Stack Overflow’s 2025 developer survey found that 84% of respondents were using or planning to use AI tools in their development process, and its AI section showed something just as important: more developers actively distrust the accuracy of AI output than trust it. That gap matters. If people are using the tools constantly while trusting them cautiously, then the missing piece is not speed. It is verification.

And right now, verification is where too many teams are falling apart.

The convenience is real, but so is the blast radius

I get why vibe coding is attractive.

It compresses time. It lowers the barrier to building. It helps experienced developers move faster and lets less experienced builders create things they would not have touched a year ago. For internal tools, rough prototypes, automations, and first drafts, that can be a huge win. In the right environment, AI really can be a multiplier.

But the same thing I wrote recently about AI in managed services still applies here: AI is not going to save an undisciplined operation. It rewards the teams that already standardize, document, secure, and review well. If the environment is messy, AI usually amplifies the mess.

That is the part the sales pitch rarely emphasizes.

AI can generate code fast. It can also generate weak access control fast, insecure object references fast, hardcoded secrets fast, sloppy logging fast, and dependency mistakes fast. It can scaffold a whole workflow before anyone has asked basic questions like:

• Who should be allowed to access this?
• What happens if an attacker controls this input?
• Where are secrets stored?
• What is the trust boundary here?
• What happens if this dependency is malicious, fake, or compromised?
• Who on the team could explain this code under pressure?

If nobody can answer those questions, the application is not done. It is just deployed.

Recent warning shots were not hypothetical

This is not a theoretical problem anymore.

On July 29, 2025, Wiz disclosed a critical vulnerability in Base44, an AI-powered vibe coding platform, that allowed unauthorized access to private applications hosted on the platform. Wiz said the issue could expose enterprise apps used for internal chatbots, knowledge bases, and even PII and HR workflows. That is not a harmless edge case. That is a reminder that when people build fast on top of managed AI app platforms, platform-level security mistakes can hit every downstream app at once.

Then, on April 20, 2026, Lovable said in its own incident response that data within public Lovable projects could be accessed by any authenticated user. According to the company, between February 3, 2026 and April 20, 2026, public project chat history and source code could potentially be accessed if someone had a project link. Lovable said private projects and Lovable Cloud were not impacted, but even the public-project scope is a big deal. Source code, prompts, and internal app logic are not trivial exposures. They are often the map an attacker needs.

And the problem is not limited to app-builder platforms.

On March 18, 2025, Pillar Security published its Rules File Backdoor research, showing how attackers could hide malicious instructions inside rule files used by tools like Cursor and GitHub Copilot. The ugly part is not just the trick itself. It is what it says about the trust model. If the assistant can be quietly steered by poisoned context, then the assistant is part of the attack surface. At that point, you are not only reviewing code. You are also reviewing the invisible instructions that shaped it.

That lines up with NCSC’s warning that prompt injection is not SQL injection. Their point is blunt and important: large language models do not enforce a real boundary between instructions and data, which means prompt injection may never be “solved” in the neat, permanent way people like to imagine. That should change how teams think about agent permissions, tool access, and autonomous workflows.

The real problem is the illusion of correctness

One of the most dangerous things about AI-generated code is that it often looks finished before it is secure.

It is readable. It compiles. It feels coherent. It gives people the sense that the hard part is over.

That is why I think the biggest security risk around vibe coding is not just bad code. It is the illusion of correctness.

Veracode’s Spring 2026 GenAI update said AI coding assistants now exceed 95% syntax correctness, while security pass rates remain stuck around 55% when no security guidance is provided. That is a brutal gap. It means the code can look polished, function properly, and still be insecure almost half the time.

That same pattern shows up elsewhere too. Georgia Tech’s coverage of new research highlighted confirmed real-world cases of AI-introduced vulnerabilities, including command injection, authentication bypass, and server-side request forgery. In other words, the failures are not limited to toy examples or prompt engineering demos. They are turning into real defects with real consequences.

Even code review quality takes a hit. CodeRabbit’s report found AI-authored pull requests contained about 1.7 times more issues overall, with security issues amplified and logic problems showing up more often. That tracks with what many developers already feel intuitively: AI does not just accelerate output. It accelerates review fatigue too.

This is where I think a lot of teams are fooling themselves. They are not replacing engineering effort. They are relocating it downstream, where the cleanup gets more expensive.

What keeps going wrong

The same classes of security failure show up again and again in AI-assisted code because the model is usually optimizing for “working” before it is optimizing for “defensible.”

Failure mode	Why vibe coding makes it worse	What teams should do instead
Broken access control	The app works for the happy path, but ownership checks, role boundaries, and object-level authorization get skipped or assumed.	Threat model access early, test for BOLA/IDOR style failures, and require explicit authorization checks in review.
Prompt-injected or poisoned generation	Agents ingest rules files, issue text, READMEs, and other context that may be attacker-controlled or quietly manipulated.	Treat AI context as untrusted input, minimize agent permissions, isolate tools, and keep humans in the approval path.
Secret leakage and unsafe config	Generated code often reaches for convenience, including hardcoded keys, permissive defaults, and verbose logging.	Use centralized secrets management, run secret scanning by default, and block commits with embedded credentials.
Dependency and package risk	Models can recommend outdated, unsafe, or even hallucinated packages, especially when speed matters more than provenance.	Pin dependencies, verify package legitimacy, generate SBOMs, and review provenance before shipping.
Weak validation and unsafe data handling	The generated app may “work” while still trusting user input too much at the API layer.	Require validation libraries, secure-by-default frameworks, negative testing, and API-specific security review.

To me, that table is the real vibe coding story. Not “AI wrote an app in ten minutes.” The real story is that AI can help create production-looking software before anyone has done the slow, boring work that makes software safe.

And boring work still matters.

That is true in code. It is true in infrastructure. It is true in the browser too. A lot of these tools run through web sessions and dashboards where the browser is still the front door to most modern compromises. It is true in operations, where shared context is the difference between seeing risk clearly and just moving noise around faster. And it is true in software delivery, where modern software trust chains can turn into chokepoints fast.

Vibe coding does not replace those realities. It collides with them.

What I think teams should do right now

I do not think the answer is banning AI coding tools outright.

I do think the answer is treating them like power tools instead of magic.

If a team is going to use AI heavily for coding, then at minimum it should:

1. Treat generated code as a draft, not a deliverable

Generated code should enter the same review path as any other external input. That means human review, security review where it matters, tests, and approval gates. The output is a starting point.

2. Review the trust boundaries before the code style

Pretty code can still be unsafe code. Reviewers need to ask where the data comes from, what the model assumed, and who can influence the context that shaped the output.

3. Lock down agent permissions hard

If an AI agent can access secrets, make network requests, run shell commands, or modify production-adjacent workflows, then it needs least privilege and strong containment. Anything else is asking for trouble.

4. Add security guidance to prompts and rules, then verify anyway

Yes, prompting for secure coding practices helps. No, that does not remove the need to verify the result. Secure prompts reduce risk. They do not eliminate it.

5. Scan everything automatically

SAST, dependency scanning, secret scanning, IaC scanning, container scanning, and policy checks need to be part of the default path, not the “if we have time” path.

6. Keep provenance and audit trails

Teams need to know what was AI-generated, what dependencies were introduced, what context shaped the output, and who approved it. Otherwise, incident response turns into guesswork.

7. Do not let non-technical stakeholders mistake velocity for safety

This one matters more than people admit. Faster generation is not the same thing as faster secure delivery. If leadership only sees speed, security debt will pile up quietly until it stops being quiet.

Speed without review is just faster risk

That is really my bottom line.

Vibe coding is not inherently reckless. Shipping code you do not understand absolutely is.

There is a real place for AI-assisted development. I use AI. I expect serious teams to keep using it. But security people, developers, MSPs, and technical leaders need to get more honest about what these tools are actually doing. They are compressing the time between idea and implementation. They are not compressing the need for judgment.

If anything, they make judgment more important.

Because once code can be produced this quickly, the bottleneck shifts. It is no longer “can we build it?” It is “can we trust what we just built, can we explain it, and can we defend it when something goes wrong?”

That is the part that decides whether vibe coding becomes a force multiplier or just a faster way to ship avoidable security failures.