A marketing lead ships a landing page with an AI builder on a Friday afternoon and it works, so nobody asks how. The “how” catches up eventually: a security researcher’s email, a stalled feature the tool cannot express, or a database that turns out to have no real permissions on it.
Vibe Coding Ships Fast. It Also Ships Debt.
Vibe coding means describing what you want to an AI tool like Lovable, v0, or Bolt and getting a working site back. There is little or no line-by-line review of the code underneath. It is genuinely fast. It is also, on current evidence, unreviewed by default, and the debt that creates is different from the debt of a normal rebuild backlog.
In 2025, Veracode tested more than 100 large language models across Java, Python, C#, and JavaScript coding tasks and found an average 45% failure rate against the OWASP Top 10 security benchmarks[1]. Java fared worst at 72%. Models solving cross-site-scripting tasks passed only 15% of the time. The unsettling part is the trend line. Syntax correctness has climbed from roughly 50% to 95% since 2023, while security pass rates have stayed flat in the 45-55% band regardless of model or release date. The tools got better at writing code that runs. They did not get better at writing code that is safe.
That gap is now visible in real CVE data, not just lab benchmarks. Georgia Tech’s Vibe Security Radar traces each vulnerability’s fixing commit back through its Git history to check whether an AI tool introduced the flawed code in the first place. In 2026, confirmed AI-attributed CVEs climbed from 6 in January to 15 in February to 35 in March, roughly a sixfold jump in one quarter[2]. Researchers estimate the real total across the open-source ecosystem runs 5 to 10 times higher, because most AI coding tools leave no commit metadata identifying them as the source.
This is a mise en place problem before it is a coding problem. The tools ship a kitchen with the burners already lit, and nobody has checked whether the gas line is capped. The WebOps lifecycle’s Foundation stage exists precisely to catch this kind of gap before Stabilization work compounds on top of it. A vibe-coded marketing site skips Foundation by construction. The tool’s entire pitch is skipping the parts that used to require an engineer in the room.
Why Does the Debt Stay Invisible Until It’s a Security Incident?
The debt hides because vibe-coding platforms default to public and default to permissive, and nothing in the workflow forces a check. A marketing team publishing a landing page has no reason to ask whether the database behind the lead form has row-level security enabled. Most never do, and on current evidence, most do not need to look far to find a problem.
In 2025, security firm Escape scanned 5,600 publicly reachable applications built on vibe-coding platforms including Lovable, Base44, and Bolt.new. It found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets such as API keys and access tokens, and 175 instances of exposed personal data, including medical records and bank account numbers[3]. Every one of those findings sat in a live production system, discoverable within hours. The platforms’ default visibility settings leave a project public unless someone manually switches it to private.
One specific failure mode illustrates the pattern well. In May 2025, an independent researcher scanned 1,645 applications published in Lovable’s own public showcase and found that 170 of them, 10.3%, shipped with Supabase row-level security missing entirely[4]. The vulnerability, CVE-2025-48757, meant any authenticated session could query the full underlying database directly. The Supabase URL is visible in the app’s own frontend bundle, and nothing was configured to stop a query once someone had it.
A Series A B2B SaaS team learned this the indirect way. Its comparison and pricing pages went up in a single sprint on an AI builder, and the team moved straight to the next launch. A routine security review nine months later, unrelated to the marketing site itself, found the builder’s default database was still publicly queryable. Every lead-capture submission, name, email, company domain, sat behind no real permission check the entire time.
The Real Migration Trigger: A Constraint, Not a Feeling
Not every vibe-coded site needs to migrate, and the same diagnosed-vs-felt test that applies to any other rebuild decision applies here too. If the case against the current site is “it looks unpolished” or “we should really own this properly,” that is a feeling, and a feeling is not a structural finding. Migration earns its cost only when the audit names a constraint the platform genuinely cannot fix, using the same diagnosed-vs-felt test that applies to any other rebuild decision.
A Series B team’s actual trigger came from procurement, not design. An enterprise prospect’s security questionnaire asked for the marketing site’s authentication model and data-handling policy. Nobody on the team could answer, because nobody had reviewed the underlying architecture since the AI tool generated it. That unanswerable question, not a wish for a redesign, was the real trigger. Compliance blockers, unpatchable data-model ceilings, and security findings the team cannot remediate in place are the honest short list of reasons to migrate. A site that “just needs a refresh” almost never belongs on it.
What a Real Migration Actually Requires
Once the trigger is real, the work is less dramatic than a full rebuild and more specific than a redesign. Front-end templates and page structure usually carry over close to as-is. What has to be rebuilt deliberately is the data layer. That means permissions on every table, secrets rotated and moved out of client-visible bundles, and version control replacing whatever the AI tool’s own deploy pipeline was doing.
A real migration is not a rewrite, and treating it like one wastes the one advantage the original build had: speed. Most of the front-end markup and content structure the AI tool generated is usable as reference, and often as a literal starting template. That holds once someone with real access has reviewed what it actually does under the hood. The work that cannot be shortcut is exactly the work vibe coding shortcut in the first place. That means naming who owns which table and rotating every credential the tool ever generated. It also means turning implicit assumptions about user roles into an explicit permission model somebody actually wrote down.
None of this is unique to marketing-led builds. In 2026, CloudBees surveyed 213 enterprise technology leaders and found that 81% had seen a rise in production failures tied to AI-generated code[5]. That is inside engineering organizations that already run code review, staging environments, and release processes. A marketing team shipping straight to production with no review at all is operating with less structure than the group already reporting the problem. This is the same dynamic AI-agent code generation was already intensifying the ownership gap before vibe coding had a name of its own.
A Series C team’s migration ran long for a reason that had nothing to do with the code itself. Nobody had documented what the AI tool actually built. There was no data model, no list of integrations, no notes on what the generated backend assumed about user roles. The team spent more time reverse-engineering the old site than building the new one, and that documentation gap, not the migration effort proper, was the real cost.
The lesson generalizes past this one category of tool. When a rebuild is the wrong answer, it is usually because the platform was never the actual problem. Vibe coding inverts that failure mode. The platform genuinely can be the problem, quietly, from day one. The only way to know is to look before a security questionnaire, an incident, or an auditor looks for you.
Sources
- Veracode, 2025 GenAI Code Security Report – 100+ LLMs tested across Java, Python, C#, JavaScript; average 45% OWASP Top 10 failure rate; Java 72%; XSS tasks pass only 15%; syntax pass rates rose 50% to 95% since 2023 while security pass rates stayed flat 45-55% ↩
- Georgia Tech SCP / Infosecurity Magazine, on the Vibe Security Radar tracker – Confirmed AI-attributed CVEs: 6 (Jan 2026), 15 (Feb), 35 (Mar), roughly 6x in one quarter; researchers estimate the real total runs 5-10x higher ↩
- Escape, The State of Security of Vibe-Coded Apps – October 2025; 5,600 public apps scanned; 2,000+ high-impact vulnerabilities, 400+ exposed secrets, 175 instances of exposed personal data, all live in production ↩
- Vibe Coder Blog, Post-Mortem of the Lovable CVE That Exposed 170+ Apps – May 2025; 1,645 apps scanned from Lovable’s public showcase; 170 (10.3%) missing Supabase RLS entirely, CVE-2025-48757, CVSS 8.26 ↩
- CloudBees, 2026 State of Code Abundance Report – TrendCandy fieldwork, n=213 enterprise technology leaders, published May 19 2026; 81% report a rise in production failures tied to AI-generated code ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
Vibe coding is building a working application, including a marketing site, by describing what you want in plain English to an AI tool like Lovable, v0, or Bolt, which generates the underlying code and infrastructure with little or no line-by-line review. It ships fast. It does not ship reviewed.
Only if someone has actually checked it. In 2025, a scan of 5,600 public vibe-coded apps found over 400 exposed secrets and 175 cases of exposed personal data, all in live production. The risk is not theoretical. It is the default state until someone audits it.
When an audit finds a named constraint the platform cannot fix, not when the site feels dated. A security questionnaire nobody can answer, a data model that cannot extend, or a compliance requirement the platform structurally cannot meet are real triggers. Wanting a refresh is not.
Usually not entirely. Front-end templates and page structure often carry over close to as-is. What has to be rebuilt deliberately is the data layer: permissions, secrets management, and an architecture someone on the team actually understands and can maintain.
Not on security specifically. Veracode's testing across model generations found syntax-correctness climbing from about 50% to 95% since 2023, while security pass rates stayed flat between 45% and 55% regardless of model or release date.
