Your vibe-coded MVP works. That doesn't mean it's ready.

22 October 2026

In January 2026 Moltbook, a social network for AI agents, went viral. Its founder was open about how it was built: “I didn’t write a single line of code for @moltbook.” Then Wiz looked at it. The site ran on Supabase, a hosted Postgres database, and the Supabase key in the site’s JavaScript gave anyone read and write access to every table, because the tables had no Row Level Security (RLS) policies. RLS is a database rule that decides which rows a given user may read or write, so one customer can’t query another customer’s data even with a valid key. About 1.5 million agent authentication tokens, about 35,000 email addresses and 4,060 private conversations were open to the internet.

What stays with me is the timeline in the same Wiz write-up. The problem was reported at 22:06 UTC on January 31, and all tables were secured by 01:00 UTC the next day. Under three hours. The fix was easy; the problem was that nobody had looked until an outside security team did, and most of this article is about that gap.

This piece was prompted by a DOU article by Fedir Kompaniiets (in Ukrainian). I agree with his thesis: vibe coding is the fastest way to find out whether an idea is worth anything, and “it works” is not “it’s ready”. A disclaimer applies to both of us, though. His company sells DevOps services, and I’m a platform engineer, so we’re both inclined to conclude that you should call the ops people. Below I rely on incident reports, papers and platform documentation rather than on anyone’s opinion, his or mine.

What vibe coding is good at

Throwaway code is a legitimate engineering decision. Martin Fowler calls it sacrificial architecture: “often the best code you can write now is code you’ll discard in a couple of years time.” A weekend prototype that proves nobody wants your product has done its job. It doesn’t need connection pooling or a disaster recovery plan.

The productivity evidence is mixed but leans positive. A Google randomized trial estimated a speedup of about 21%, with a wide confidence interval. A field study at Microsoft and Accenture found a 26.08% increase in completed tasks across 4,867 developers. METR’s 2025 study pointed the other way: experienced open-source developers took 19% longer with AI tools while believing they had been sped up by 20%. METR’s February 2026 update says developers are now likely sped up, and calls its own measurement an unreliable signal.

So speed is not where it goes wrong. It goes wrong the day someone you don’t know signs up.

The missing role

A production system has a role you don’t see in a demo: the person whose job is to ask what happens when something goes wrong. On a normal team it’s spread across a security reviewer, whoever owns the database and whoever gets paged at night. In a one-person vibe-coded product, that role is empty.

Vercel, which sells a vibe coding tool, says about 63% of the people exploring these tools are not developers. It’s a vendor number with no stated method, so treat it as rough. You can’t skip a security review you don’t know exists.

The platforms know this. Lovable has a built-in security scan. Then a researcher found that an app showcased by Lovable leaked data on more than 18,000 people, with an authentication check written backwards: “The guard blocks the people it should allow and allows the people it should block.” Lovable’s chief information security officer replied that acting on the scanner’s recommendations “is at the discretion of the user.” That’s an honest answer, and it describes the situation well: the tool warns you, and nothing makes you listen.

What breaks, in the order it bites

Access control

Most published incidents are not clever attacks. They are a database reachable from the internet with no access rules. Supabase’s documentation is blunt about it: “A table in an exposed schema without RLS is readable and writable by any role with a grant on it.” The key in your frontend is meant to be public, and RLS is what makes that safe. Without it the public key works as a master key. CVE-2025-48757, a public vulnerability record rated 9.3 out of 10 on the CVSS severity scale and disputed by Lovable, describes exactly this for Lovable-generated sites.

In October 2025 Escape analyzed more than 5,600 publicly available vibe-coded apps, with medical records and IBANs (bank account numbers) among the exposed data. The summary counts 2,038 highly critical vulnerabilities, more than 400 leaked secrets and 175 cases of exposed personal data across about 1,400 of them.

The models won’t fix this for you. Veracode tested more than 100 models on 80 coding tasks in 2025 and found they chose the insecure option 45% of the time. A year later the average security pass rate was 56%. Two caveats are fair. Those tests ran against raw models, not agents with guardrails or human review in the loop. And human code is no clean baseline: Veracode’s State of Software Security 2026 found that 82% of organizations carry security debt. Insecure code predates AI. What changes is the speed, and in a solo project nobody else reads it.

Secrets and the bill

GitGuardian found that public repositories using Copilot had a 6.4% secret leakage rate, higher than the average across all public repositories. The same research found that 70% of secrets leaked in 2022 were still valid at the time of the report. GitGuardian is a vendor and the Copilot link is a correlation, but the second number is the one to remember: a leaked key does not expire by itself.

When someone uses it, the bill moves faster than your alerts. In March The Register wrote about a company that usually spends $180 a month and was charged $82,314.44 in about 48 hours after its Gemini API key was stolen. Budget alerts would not have stopped it. AWS Budgets information is updated up to three times a day, and on Google Cloud an alerts-only budget doesn’t cap spending. Alerts tell you about the spend after it happens. Hard quotas and per-key limits are what actually stop it.

The agent holds production credentials

In July 2025 Jason Lemkin of SaaStr was running a 12-day experiment with Replit’s agent. On day nine it issued destructive commands that erased a production database with records on 1,206 executives and over 1,196 companies. At the time, Replit used the same database for preview, testing and production. Lemkin’s summary: “There is no way to enforce a code freeze in vibe coding apps like Replit.”

The details are more instructive than the headline. The agent told him a rollback was impossible, but a backup was available and could be imported. The agent got its own recoverability wrong. And Replit changed the default: a published app now gets its own production database, and the agent is not able to modify it. That’s real progress on one platform. Lovable’s documentation still says “Every draft uses the same database as your project.”

OWASP has a name for this class of problem, Excessive Agency: “the vulnerability that enables damaging actions to be performed.” The agent is also an input channel. Invariant Labs showed how a malicious GitHub issue could hijack an agent connected through the GitHub MCP server (MCP is the protocol that lets an agent call outside tools) and make it leak data from private repositories. Experienced teams get this wrong too. AWS traced a malicious commit in version 1.84.0 of its Amazon Q extension for VS Code to an inappropriately scoped GitHub token in the configuration of CodeBuild, its build service. The rule itself is old: the AWS guide to IAM, its permissions system, says to “grant only the permissions required to perform a task.” When an agent holds the token, ignoring it gets more expensive.

Dependencies that don’t exist

Models invent package names. A USENIX Security 2025 paper measured at least 5.2% hallucinated packages for commercial models and 21.7% for open-source ones, with 205,474 unique invented names. Attackers can register those names and wait for someone to install them, an attack called slopsquatting. The Cloud Security Alliance’s April 2026 note says plainly that “slopsquatting is no longer a theoretical risk.” Confirmed attacks are still few, and the defense is cheap: a committed lockfile, a dependency scanner in CI (the automated checks that run on every change), and a human look at every new package in a diff.

Backups nobody has restored

Data is the one thing you can’t regenerate with a prompt. In 2017 GitLab lost production data and found that its periodic backups with pg_dump, the standard Postgres export tool, had not been working, partly because “nobody was responsible for testing this procedure.” That was a company full of engineers. Supabase recommends that free-tier projects regularly export their data on their own, and point-in-time recovery, which restores the database to any chosen moment, is a paid add-on. Lovable Cloud lists daily backups, which helps. Still, until you have restored a backup, you don’t know that it works.

If the data is personal and belongs to people in the EU, a breach is also a legal problem. GDPR Article 83 allows fines of up to EUR 10 million or 2% of worldwide annual turnover for the tier that covers security obligations, and up to EUR 20 million or 4% for the top tier.

Logs nobody kept

Without logs you can’t say what your app did five minutes ago: who logged in, what failed, which data was read, what the agent ran, what it cost. Moltbook heard about its open database from Wiz. Logs are how you hear about a problem from your own system first, and afterwards they’re the only way to tell which data was taken.

OWASP lists this in its Top 10 as Security Logging and Alerting Failures, and the description could be about a typical vibe-coded app: logins and failed logins “are not logged or logged inconsistently,” and “logs are only stored locally.” The OWASP Logging Cheat Sheet gives the starting list: authentication successes and failures, access control failures, application errors. I’d add every admin or data-changing action and every call to a paid API, with its cost. Give each request an ID and put it in every log line and every error message.

Send the logs somewhere outside the app, so the incident that breaks the app doesn’t wipe its history. Supabase can send all logs to an external destination on paid plans. Keep them for months, not days. Mandiant’s M-Trends 2026 puts the global median dwell time, how long attackers stay inside before anyone notices, at 14 days, and some intrusions it describes ran for nearly 400.

Never log passwords, access tokens, connection strings or sensitive personal data. The cheat sheet says to remove, mask or hash them. A log full of secrets is one more leak.

Load

Most MVPs never get enough traffic for this to matter, and building for scale you don’t have is waste. Jeff Dean’s rule, quoted by Fowler, is a good default: “design for ~10X growth, but plan to rewrite before ~100X”. When growth does arrive, the failures are boring and well known. Serverless functions each hold their own database connections, while the database accepts only a limited pool of them. Supabase warns that “a few dozen instances is enough to exhaust the pool.” Code that loads a list and then queries once per item has the N+1 problem, where “the problem lies within the total number of queries executed.” State kept in one instance’s memory or on its local disk breaks the moment you run a second instance. Twelve-Factor, a well-known set of rules for building web services, put it simply: “Twelve-factor processes are stateless and share-nothing.”

None of this has to be fixed on day one. It needs a load test before the launch you’re advertising, not after it.

Debt with interest

The most useful study I’ve read on this comes from Carnegie Mellon. It followed 806 open-source repositories that adopted Cursor: output jumped in the first month and the gain faded after two, while static analysis warnings rose by 30% and code complexity by 41%. The authors found that those increases are major factors driving the long-term velocity slowdown. CodeRabbit’s comparison of 470 pull requests found 10.83 issues per AI-authored PR against 6.45 for human-only ones. The DORA 2025 report, from Google’s research program on software delivery, found that AI adoption still has a negative relationship with delivery stability, and summed it up in a line I agree with: “AI doesn’t fix a team; it amplifies what’s already there.”

When you pay the debt down, don’t start over. Joel Spolsky called the rewrite from scratch “the single worst strategic mistake that any software company can make”. Fowler’s strangler fig approach exists for exactly this case: replace one piece at a time while the system keeps running.

When to bring in an engineer

What follows is my judgment, not a statistic. While the product is a demo, you don’t need anyone. You need someone as soon as one of these is true:

• you store other people’s personal data, or you touch payments;
• people you don’t know can sign up;
• you’re about to send traffic to it on purpose: a launch, a campaign, a big customer;
• you’re about to sign a contract with the words “secure” or “available” in it.

An engineer doesn’t have to mean a team. A few days of review from someone who has been paged at 3 a.m. covers most of the list below.

Checklist before real users

1. Row Level Security (per-user access rules in the database), or your platform’s equivalent, is on for every table and tested with a second account that must not see the first account’s data.
2. No secrets in the frontend bundle or the repository, a secret scanner in CI, and any leaked key revoked and rotated, not just deleted from git.
3. Hard spending limits and per-key quotas, not only budget alerts.
4. Separate dev and prod databases. The agent has no write access to prod.
5. Agent, CI and MCP tokens scoped to the minimum. No broad personal tokens.
6. A committed lockfile, dependency scanning, and a human check of every new package.
7. Automated backups with point-in-time recovery, and at least one restore actually performed and timed.
8. A written list of the personal data you store, where it lives and why you keep it.
9. A load test at about 10x the traffic you expect at launch, with connection pooling in place.
10. Central logs outside the app: logins and failed logins, access denials, errors with request IDs, admin and data-changing actions, paid API calls and their cost. Kept for months, with no secrets or personal data in them.
11. Error tracking and uptime alerts that reach a phone, so you hear about a problem before your users post about it.

Moltbook’s fix took less than three hours, and most items on this list take an afternoon each. Vibe coding made building a product cheap, but running it costs what it always did. The fixes are rarely the expensive part; noticing that you need them is, and somebody has to own that job.