Vibe coding is the shiny new thing. Maybe you’ve already seen it in the wild:
- A salesperson builds their own tool with AI.
- A designer pushes UI changes straight to GitHub.
- A marketing team writes campaign software instead of renewing a vendor contract.
As Steve Yegge said on The Pragmatic Engineer podcast, AI has blown the doors open. Code isn’t just coming from developers anymore. Anyone with a prompt can ship an app. Most people doing this don’t even know they’re vibe coding. They’re just describing what they want in plain English and letting AI generate the code. That shift has changed who builds software and how fast it ships. That speed is exciting, but it also comes with a serious problem. Most of that code is running blind with no reviews, no tests, and no security.
What is Vibe Coding?
Vibe coding is when you describe what you want in plain English and let an AI generate the code for you. Platforms such as Lovable, Windsurf, and Replit pitch themselves as letting anyone go from idea to app in hours. It feels like magic because you don’t need technical syntax or formal training. You just say what you want, copy-paste, run it, and see if it works.
It’s fast and frictionless, which is why it has spread outside of engineering teams. Designers, marketers, and sales teams can all now ship apps or features without waiting for developers.
The catch is that vibe coding prioritizes output over safety. Most of the time there are no reviews, no tests, and no security baked in. That’s where the problems start.
When the Vibe Turns Sour
There are a number of examples of vibe coding turning sour:
- Replit incident: SaaStr’s Jason Lemkin trusted Replit’s AI agent to build a production-grade app. At first it was exhilarating: prototypes in hours, QA checks, rapid progress. Then things unraveled. The AI started lying about unit tests, ignored code freezes, and eventually deleted the entire SaaStr production database. Months of curated executive records were gone overnight. As Lemkin told ZDNet, “you can’t overwrite a production database. Nope, never, not ever.”
- Tea app: admin routes left unlocked, exposing user data to anyone who stumbled across the endpoint. What looked like a fun experiment quickly became a data privacy liability.
A decent proportion of apps built by hobby developers contain serious vulnerabilities before they even launch; if you tried ten apps built this way, odds are at least one would be hackable.
These failures matter because security flaws in vibe-coded apps aren’t just minor bugs. They often involve core protections like authentication, data access, and secrets management. If an app handles payments or personal data, the consequences aren’t just technical. They are financial, regulatory, and reputational.
Mackenzie Jackson, developer advocate at Aikido Security, puts it bluntly:
“AI doesn’t write secure code by default. It just spits out something that works. Under the hood, it can be wide open to attacks.”
Why This Spreads Fast
The key difference with vibe coding is that everyone is doing it now. Designers, PMs, sales, and marketing teams are all shipping code. Attackers don’t care if it’s a side project or enterprise software. They only care if the door is unlocked.
Speed is an advantage but it's also a problem. An app that used to take weeks can now be built in an afternoon. That means an entire team can spin up prototypes and tools without waiting for engineering. The catch is that none of these new developers are thinking about access controls, input sanitization, or dependency updates.
Willem Delbare, Founder and CTO of Aikido, described this shift to ZDNet as a perfect storm:
“Vibe coding makes software development more accessible, but it also creates a perfect storm of security risks that even experienced developers aren't equipped to handle. SQL injections, path traversal, hardcoded secrets.”
Mackenzie Jackson warns this is going to get worse. As he told TechMonitor:
“More folks without a strong background in engineering or security are using these tools to build software… which means we’ll end up with even more AI-generated code that nobody’s really looked at carefully.”
This is how vibe coding ends up as what Mackenzie calls “vulnerability-as-a-service.” The faster untrained hands ship apps with AI, the faster the security holes multiply across the web.
Securing the Vibes
We already published a Vibe Coders’ Security Checklist for people who are building. That covers the basics: authentication, input sanitization, scanning, and secrets management.
But the bigger point here is awareness. If you’re experimenting with AI coding, or if your team is, you need to recognize that the shiny prototype you ship in an afternoon could also be the backdoor that lets attackers in.
What can teams do?
- Treat AI code like a junior developer wrote it: review, test, and lock it down.
- Outsource authentication to services built for it instead of rolling your own.
- Keep secrets out of the frontend and repos.
- Don’t just run scans. Actually think about logic flaws.
It sounds obvious, but most vibe coders aren’t doing it. That’s why security has to be part of the conversation, even for roles outside of engineering.
What is Agentic Coding?
Agentic coding is the step beyond vibe coding. Instead of you asking an AI for snippets and pasting them in, AI agents take over the process of writing, running, and modifying code automatically. They can install dependencies, run tests, refactor files, and even update infrastructure.
This approach is used more by developers and technical teams than casual users, which makes it feel more trustworthy. The problem is that this trust is misplaced. Agentic coding creates cleaner, more professional-looking code, but that appearance hides the risks.
Agentic Coding Cranks It Up
Where vibe coding often creates messy, obviously fragile code, agentic coding produces code that looks flawless. That’s part of the danger. A single bad decision can ripple across an entire system and spread through dependencies and environments before anyone notices.
AI tools are producing more of this code faster than ever, and none of it is security-aware by default. Clean code is easier to ship and reuse, which means vulnerabilities spread quietly and quickly.
The only way to control the risk is to catch mistakes before they go live. That means plugging directly into CI/CD pipelines, scanning every dependency, and validating assumptions with immediate feedback.
What CISOs Need to Think About
For security leaders, vibe coding isn’t just a developer trend. It’s changing how software gets built across the org. The job of the CISO is shifting from enforcing gates to designing guardrails that let people experiment without taking down production.
Some key ideas to anchor on:
- MTTG (Mean Time to Guidance)
Traditional metrics like MTTD and MTTR measure what happens after things go wrong. MTTG measures how fast vibe coders get actionable guidance before their code becomes a vulnerability. The lower the MTTG, the fewer incidents materialize at all. - PromptBOMs
Think SBOMs, but for AI code. A simple record of the model, prompt, and parameters that generated a snippet. If something breaks, you know where it came from and why. Provenance equals accountability. - Vibe-Coding Assurance Levels (VCAL 0–5)
Like autonomous driving levels, but for AI-assisted coding. VCAL-1 means AI is just suggesting. VCAL-3 adds guardrails and provenance capture. VCAL-5 is fully autonomous merges for low-risk changes with continuous attestation. The framework gives CISOs a way to calibrate expectations instead of reacting blindly.
The takeaway: don’t try to teach every employee to “do security.” Instead, ship security UX that’s invisible, embedded, and scaled to how people are actually building with AI.
Bottom Line
Vibe coding is not going away. Code is being written at AI speed by people inside and outside of engineering. If you don’t plan for security, you aren’t just moving fast, you’re also spreading vulnerabilities just as fast.
The vibes are good. Just don’t forget the security check.
Want the practical steps? Read the Vibe Coders’ Security Checklist.
.avif)
