5 Vibe-Coding Mistakes to Avoid Before Your Next App

Bob Starr loved his vibe-coded website. The project, “Boomberg,” tracked how much U.S. tax money flows to tech companies, and he pushed it live immediately after building it. Months later, he discovered a hidden SQL injection vulnerability that could have let attackers read or alter data without authorization.

“It was just a glaring oversight on my part. It was a complete blindspot in my state of learning this new technology and understanding it, and I’m sure there are others making the same mistake,” said Starr, a tech sector project manager.

Starr patched the flaw, but his experience is far from unique. Social media is filled with cautionary tales about vibe-coded apps riddled with security holes. Jer Crane, founder of PocketOS, posted on X about an AI coding agent that wiped his company’s production database. Joe Procopio, a serial entrepreneur and former developer, built a web app to privately demo other projects. Hackers found it, so he took it down. “Now I do demos the old fashioned way, from my local machine over Zoom,” he wrote. “It’s sooo 2023.”

We’ve entered what The Verge’s David Pierce calls a new “era of personal software,” where anyone can use AI to craft private apps that do exactly what they want. But this era brings a fresh wave of security risks. Building apps is easy; securing them is hard, especially when AI can also be used to attack them.

“My general core take is that vibe coding is not bad because amateurs can build software. That’s actually the good part,” says Gabriel Bernadett-Shapiro, distinguished AI research scientist at SentinelOne, an AI-powered cybersecurity firm.

The real danger, he explains, comes when a personal app drifts into business territory, storing shared, hosted data without anyone realizing the shift. The stakes change when vibe coding moves beyond local tools for tracking migraines or meals and into apps handling customer logs, medical data, financial records, or internal documents.

“Those need to be held to a different standard. Even if it was built by one person in an afternoon. Even if the software creating the software was trivial. The moment that it touches other people’s personal data, then that’s when I think the standard changes.”

Jack Cable, CEO and cofounder of Corridor, a security platform for AI-native software development, agrees. “Vibe coding is great for lower risk things,” Cable says, like a prototype or a fitness tracker that isn’t sensitive. But financial records deserve more scrutiny, as does anything on the public internet. “Are you exposing any of your own or other people’s data there?” he asks. “Think through what the threat model looks like, and if you’re not sure if something you’re doing is secure, better safe than sorry.”

Max Segall, COO at crypto wallet firm Privy, followed that advice. He vibe-coded EzRun as a fun way to reward his kid with $10 in Ethereum after runs together. Before launch, a colleague found a critical flaw that would have let anyone modify user accounts to gain access. He fixed it in time.

In a more alarming case, developer Matt Schlicht launched Moltbook in late January, a viral social network built entirely for AI agents. He wrote zero lines of code. Within days, researchers at Wiz found the app’s entire production database exposed, leaking tens of thousands of email addresses and private messages. Moltbook patched the bug quickly, but it wasn’t an isolated incident. Wired reported that Red Access researchers found roughly 5,000 publicly accessible apps built with popular vibe-coding tools that lacked authentication. Nearly 2,000 appeared to leak sensitive data like medical and financial information, strategy documents, and chatbot conversation logs.

To be fair, plenty of professionally made pre-AI software is also insecure. But as vibe coding exponentially increases the number of apps produced, the number of security vulnerabilities is likely skyrocketing too. It also adds the risk of overconfidence. When an AI tool tells you code is secure, it’s easy to believe it.

In a typical vibe-coding session, nothing stops to check for flaws unless you’ve installed something that does, which most casual coders haven’t. The build just keeps going. Security tools must be invoked. Claude Code has a /security-review command, but you have to ask for it. An automatic version exists, but only if you set it up on pull requests in advance, something most casual builders skip.

OpenAI’s Codex has a built-in security agent that scans commits and re-scans its own patches, but it targets developers with real version-control workflows, not someone chatting an app into existence. For everyone else, the lesson is simple: Prompt for security up front when you build, and again at the end, especially when the tool has access to data you care about.

“A lot of security is contextual,” Cable says. Running a coding agent’s review helps, but he warns against a false sense of security, especially when the agent doesn’t understand your threat model or you haven’t given it correct guidance.

Bernadett-Shapiro’s biggest concern isn’t buggy AI-generated code. It’s a lack of authentication when developers move a local app to the cloud with configuration options they don’t understand, exposing sensitive data. This is the failure that worries him most. Apps that run fine locally, when put on the cloud, can be like leaving a box of secrets open on the sidewalk, something researchers keep finding.

AI is good at finding bugs when prompted. Models like Mythos, the same Anthropic model that excels at finding vulnerabilities to attack, can also harden apps. Bernadett-Shapiro says GPT-5.5-Cyber or base models can assess security and identify issues even skilled developers might miss. But people may not understand the security tradeoffs they’re making or may ignore warnings as acceptable risk.

Some scaffolding is emerging. OWASP has published an AI security verification standard for organizations. Firms like Trail of Bits have released “skills,” add-on instruction packs that point a coding agent at specific security tasks, like flagging insecure default settings or hardcoded passwords before they ship. But skills must be triggered, so they don’t fit naturally into development flow, Cable says, and keeping them updated across coding agents and codebases is difficult.

Skills can also cut both ways. Malicious skills exist. In February, 1Password’s Jason Meller examined the most downloaded skill on a popular OpenClaw skill registry and found it directed users to install a malicious dependency. It’s still the Wild West, and it’s hard to tell whether a skill will harden your app or hand an attacker your credentials.

The problem isn’t limited to hobbyists. Cable says engineers and even sales and marketing teams at big companies are shipping far more agent-written code than before. Security teams need baseline visibility into how agents are used, along with guardrails enforced through skills or products like Corridor’s, which aim to stop flaws before code is written.

For individuals, Cable’s guidelines are simpler: A model running locally on your own computer is far less risky than one made public, especially if it contains sensitive data.

“Literally overnight, the way most companies produce software has changed completely,” Cable says. He’s not especially worried about coding agents themselves, as long as they’re given the right guardrails. Models are increasingly built on a memory-safe stack that eliminates entire classes of vulnerabilities. “I do think there is reason to be optimistic here,” he says.

Government affairs specialist Jeff Rothblum vibe-coded an app for tackling tedious data entry with security in mind. He thought about what information the app holds, how sensitive it is, and what could happen if it got out. His approach is striking because it’s so rare, and because the ground beneath us is shifting so quickly.

While working as head of government affairs and strategy at Lilt, he had to submit input forms to various government committees. No two forms are alike, so lobbyists may submit dozens or even hundreds in a six-week period. After eight 75-hour weeks and a layoff, he built a tool in case he ever had to do it again. The app scrapes links and due dates into a single dashboard and uses an LLM to prepopulate each form, so users only need to review and edit before submitting.

He was well aware of the risk because he didn’t write his own code. “The last time I wrote code was probably in undergrad in 2006 writing Fortran to analyze fluid flows as an aerospace engineer,” Rothblum told The Verge. The biggest risk is that companies could inadvertently leak strategies or sensitive lobbying rationale. He mitigates this by running regular security reviews in Claude, keeping user data local, and building toward stricter retention safeguards.

He has vibe-coded his app to clear the browser and is upfront about data being sent to Claude, linking to its retention policy. He’s working on a version where nothing a user types is stored by AI, even briefly, and a separate version that lets users route everything through their own LLM.

While Rothblum has thought of building a broader lobbying intelligence tool, he says if he starts working with more sensitive data, he intends to pay a security engineer four to five figures to review his code. “I’m happy with open-source stuff and I’m happy with ephemeral stuff, but everything else kind of scares me,” he says.

Having a human expert review code is ideal, but Cable says that’s becoming a bottleneck. The open question is what the world looks like when most code ships without any human reading it and how we secure that world.

For now, the answer for the rest of us is smaller and more within reach: Vibe-code the app of your dreams, but think through what data the app stores and has access to and what could go wrong. Ask it to build with security in mind, and run code reviews after each change, including the patches the AI writes itself. Pay extra close attention before moving it from your own device into the cloud or giving it access to sensitive data or accounts. The difference between a fun project and a horror story starts with knowing what questions to ask.