Vibe coding has made it easier for people to turn ideas into working apps. That speed is the appeal. It is also where the risk begins, because an app that works is not automatically an app that is safe.
The source article describes a simple but important shift: a private project can become a security problem when it is put on the public internet, connected to shared data or used for business-like tasks. The issue is not that amateurs are building software. The issue is that many builders may not recognize when their app has crossed into a higher-risk category.
When a quick app becomes a public risk
Bob Starr launched a vibe-coded website called “Boomberg” to show how much US tax money is going to tech companies. He was pleased enough with the result to put it online right away. Months later, he found a hidden SQL injection risk that could have allowed an attacker to read or change data they should not have been able to access.
Starr fixed the problem, but his explanation matters because it captures the broader challenge. “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 project manager in the tech sector.
The lesson is not that every small app is dangerous. It is that builders can miss security assumptions when the tool helps them move faster than their understanding. A working interface can hide flaws in the database, permissions or deployment settings underneath.
The new boundary for personal software
The article frames vibe coding as part of an “era of personal software,” a phrase used by The Verge’s David Pierce. In that world, people can make private apps tailored to their own habits and needs. That can include low-risk tools for tracking meals, migraines or package deliveries.
But Gabriel Bernadett-Shapiro, distinguished AI research scientist at AI-powered cybersecurity firm SentinelOne, draws a line between personal tools and software that stores shared or sensitive data. “My general core take is that vibe coding is not bad because amateurs can build software. That’s actually the good part,” he says.
The problem starts when a personal app quietly becomes business software. That can happen when it is hosted, shared or connected to customer logs, medical data, financial records or internal documents. Once other people’s personal data is involved, Bernadett-Shapiro says the standard changes.
“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, makes a similar distinction. He says vibe coding can be useful for lower risk work, including prototypes or a fitness tracker that is not highly sensitive. But he says financial records and anything placed on the public internet require more scrutiny.
What the failures have in common
The source article gives several examples that point to the same underlying issue: security does not appear just because the app runs.
- Jer Crane, founder of PocketOS, posted on X about an AI coding agent wiping out his company’s production database.
- Joe Procopio, a serial entrepreneur and former developer, vibe-coded a web app to privately show demos of other apps he had built. Hackers came, and he took the app down.
- Max Segall, chief operating officer at the crypto wallet firm Privy, vibe-coded EzRun to reward his kid with $10 in Ethereum every time they ran together. A colleague found a critical flaw before launch that would have let anyone modify user accounts to gain access.
- In late January, developer Matt Schlicht launched Moltbook, a viral social network built entirely for AI agents. Researchers at the security firm Wiz says it found the app’s entire production database wide open, exposing tens of thousands of email addresses and private messages.
The article also cites a Wired report that researchers at cybersecurity firm Red Access found roughly 5,000 publicly accessible apps built with popular vibe-coding tools that had no authentication. Close to 2,000 of those appeared to be leaking sensitive data, including medical and financial information, strategy documents and logs of chatbot conversations.
These examples are different in purpose and scale, but they share a practical pattern. Data was accessible when it should have been protected. Authentication was missing or insufficient. Deployment choices created exposure that the builder may not have expected.
AI can help, but only if security is part of the workflow
The source article is careful not to claim that pre-AI software was secure. Professionally made software has long had serious flaws. What changes with vibe coding is volume and confidence: more apps can be produced quickly, and an AI tool’s assurance may make builders too comfortable.
Security checks also may not happen automatically. In a typical vibe-coding flow, the system keeps building unless a security tool has been installed or invoked. Claude Code has a /security-review command that scans for vulnerabilities, but the user has to ask for it. There is an automatic version if it has been set up to run on pull requests in advance, which the article says most casual builders are not doing.
OpenAI’s coding agent Codex has Codex Security, described in the source as a built-in security agent that scans commits as they land and re-scans its own proposed patches. But the article notes that this is aimed at developers with real version-control workflows, not people chatting an app into existence.
That makes the practical takeaway straightforward. Security has to be prompted and considered early, then checked again before release, especially when the tool can access data that matters.
The simplest question before publishing
Cable’s question is the one every vibe coder should ask before an app leaves a private environment: “Are you exposing any of your own or other people’s data there?” If the answer is yes, the app belongs in a different category than a local personal tool.
That does not mean vibe coding should stop. It means the deployment decision matters. A prototype, a local tracker and a public app connected to sensitive data are not the same thing, even if they were all created with the same AI coding tool.
Bernadett-Shapiro says his biggest concern is not simply buggy AI-generated code. It is missing authentication, especially when an app that worked locally is moved into the cloud with configuration options the builder does not understand. The result can be sensitive data exposed in public.
AI can also be useful for finding bugs when prompted. The source notes improvements in models such as Mythos and says Bernadett-Shapiro believes GPT-5.5-Cyber, or even base models in other applications, can assess security and identify issues that a skilled developer may miss. But warnings only help if builders understand them and take them seriously.
Vibe coding lowers the barrier to making software. It does not lower the standard for protecting data. The moment an app is public, shared or connected to sensitive information, security becomes part of the product, not an optional final step.