What Is Vibe Coding? From Prompt to App, and What Breaks

Vibe coding means describing the software you want in plain language, letting an AI model write the code, and judging the result by what it does rather than by reading the code. It is now the fastest way to go from an idea to a clickable app, and also one of the fastest ways to put an insecure app on the internet. This guide covers where the term came from, what the main prompt-to-app tools actually do today, the failures that keep repeating, and the point at which a prototype needs an engineer.

What is vibe coding? The origin of the term

The phrase comes from Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla. On 2 February 2025 he posted on X about "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." In the same post he described accepting every change ("I 'Accept All' always, I don't read the diffs anymore"), pasting error messages back into the chat without comment, and watching the code grow "beyond my usual comprehension." He also set the scope himself: "It's not too bad for throwaway weekend projects."

Karpathy later called it a "shower of thoughts tweet" that he wrote "totally oblivious to how far it would go," in his 2025 LLM year in review. In that review he also made the positive case: vibe coding lets people who are not trained programmers build software, and "empowers trained professionals to write a lot more (vibe coded) software that would otherwise never be written."

Two meanings now circulate, and it helps to keep them apart:

• The strict meaning. Building software with an LLM without reviewing the code it writes. That is how developer Simon Willison defined it in March 2025, adding that if you reviewed, tested and can explain the code an LLM wrote, "that's not vibe coding, it's software development."
• The loose meaning. Any "prompt-to-app" workflow in a browser-based builder, such as Lovable, v0, Bolt or Replit Agent, where a non-engineer describes an app and gets a running full-stack project back.

Both are legitimate. The trouble starts when a strict-sense prototype, which nobody reviewed, is treated as a loose-sense product and handed real users, real data and real money. The rest of this article is about that gap. It is also the spine of Vibe Coding: From Prompt to Application with Lovable, v0, Bolt and Replit Agent, which teaches the full workflow under one rule: you ship it, you own it.

How prompt-to-app works

Every prompt-to-app tool runs the same loop, whatever its interface looks like:

1. Describe. You write what the app should do, for whom, and with what data. The better tools now offer a planning step where the agent asks questions and proposes an approach before it writes code.
2. Generate. The agent scaffolds a frontend, a data model, authentication and the routes between them.
3. Preview. The app runs in a sandbox or preview URL, and you click through it.
4. Iterate. You describe what is wrong or missing, and the agent edits the project. Each round is a new set of changes, usually with a checkpoint you can roll back to.
5. Connect. You attach a database, sign-in, payments, email, or a Git repository.
6. Publish. The tool deploys the app to a live URL, often on its own hosting.

What you get from that loop, and what stays your job, splits cleanly:

The left column is impressive and getting better. The right column is where incidents come from.

The tool landscape: Lovable, v0, Bolt and Replit Agent

The four best-known builders overlap more every quarter, so the useful question is not "which is best" but "what is each one built around." The descriptions below come from each vendor's own documentation, checked on 31 October 2026. Features change often; treat the docs, not a review from last year, as the source of truth.

A few details from the docs matter more than the marketing:

• Lovable describes itself as "a full-stack AI development platform for building, iterating on, and deploying web applications using natural language." Its strength is getting a complete app, with data and sign-in, from a description. It also ships security scans, covered below.
• v0 calls itself "an AI agent that helps anyone create real code and full-stack apps and agents." Because it targets a mainstream stack and a Git-and-preview workflow, its output is the easiest of the four to hand to a professional team. For GitHub-backed projects, publishing creates or reuses a pull request and merges it, so a team's normal review rules can stay in place.
• Bolt puts planning first: its Plan Mode lets you "talk through an app with Bolt before it writes any code." Its built-in database is created automatically when a project needs one, and its security audit reviews code and database together.
• Replit Agent has a Plan mode that lets the agent "brainstorm, ask questions, and map out your project before Agent changes any code or data," and it "creates checkpoints as it works, so you can roll back to any previous state." Replit's own guidance for working with the agent comes down to five habits: be specific, plan the work, add context, review and test, use checkpoints.

None of these is an engineer's tool in the classic sense. When the app outgrows the builder and someone needs to work in the code directly, the next step is an AI-native editor or terminal agent; Cursor as a Pro covers that side, from agent mode and rules to reviewing multi-file changes.

What vibe coding is genuinely good at

Used inside its limits, vibe coding is one of the most useful things to happen to product work in years:

• Validation before investment. A clickable prototype in front of five potential customers answers questions that a slide deck never will.
• Internal tools with low stakes. A tracker, a calculator, a form that feeds a spreadsheet, used by a small team and holding nothing sensitive.
• Design exploration. Three versions of an onboarding flow in an afternoon, so the team argues about something real.
• "Software for one." Personal utilities that would never justify a developer's time.
• Specifications that run. A working prototype is a far better brief for an engineering team than a written requirements document.

The common thread: the cost of the app being wrong is small, and nobody else's data is at risk.

What breaks: security

Security is the failure that turns a fun prototype into a liability, and the evidence is consistent.

Models choose the insecure option often. In its 2025 GenAI Code Security Report, published on 30 July 2025, Veracode prompted more than 100 LLMs on 80 coding tasks where both a secure and an insecure implementation were possible. The models "chose the insecure option 45 percent of the time." Failure rates were 86% for cross-site scripting and 88% for log injection, Java was the riskiest language at over 70%, and "larger models do not perform significantly better than smaller models." A newer model is not a security control.

Access control is the classic hole. Broken Access Control is ranked first in the OWASP Top 10:2025, followed by Security Misconfiguration and Software Supply Chain Failures. In vibe-coded apps it usually looks like this: the browser talks directly to a hosted database, so the only thing standing between any visitor and every row is the database's own access policy. Supabase, which both Lovable and Bolt can connect to, is explicit that a publishable key is "safe to expose online" precisely because it "only reaches what Row Level Security allows," and that a secret key must never go "in a browser, a shipped application, or source control." Its Row Level Security guide tells you to "enable RLS on every table in an exposed schema."

The Lovable case shows the pattern at scale. CVE-2025-48757, published in May 2025, describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that allowed "remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." Security researcher Matt Palmer and his co-authors, who reported it, found 303 vulnerable endpoints across 170 of the 1,645 Lovable projects they analyzed, with exposed data including emails, payment details and API keys. They also noted that the security scan Lovable shipped in April 2025 at first "merely checks for the existence of any RLS policy, not its correctness." Lovable disputes the CVE, on the grounds that each customer is responsible for protecting their own application's data. That dispute is the lesson: whoever is formally at fault, the exposure lands on the person who published the app.

Dependencies are part of the attack surface. A model can suggest packages that do not exist. A study of package hallucinations by Spracklen and colleagues, accepted at USENIX Security 2025, generated 576,000 code samples and found hallucinated package names in at least 5.2% of cases for commercial models and 21.7% for open-source models. If an attacker registers one of those names, an unreviewed install pulls in their code.

Secrets leak through prompts and commits. Generated code often inlines an API key "to make it work." GitHub's push protection, which blocks pushes that contain secrets, is on by default for your own pushes to public repositories, but repository-level push protection is off by default and has to be enabled by an administrator.

Built-in scanners help, and they say what they cannot do

The builders have responded. Lovable's security documentation describes a Quick scan that "runs automatically every time you publish," checking database access rules, known vulnerabilities in npm dependencies and unauthenticated MCP servers, plus a Deep scan that adds secrets in source code. Bolt's security audit reviews "your whole project, including your code and database." Use them every time. Then read Lovable's own caveat: the tools "do not replace a thorough security review," and for apps handling sensitive data it recommends "an additional professional security review." A green check tells you a rule exists, not that it is right.

The minimum test that would have caught most RLS exposures takes ten minutes. Create two test accounts, sign in as one, and try to read the other's data with the same public key the browser uses:

-- The policy you want on every table with user data
alter table public.orders enable row level security;

create policy "Users read their own orders"
on public.orders for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Users create orders only for themselves"
on public.orders for insert
to authenticated
with check ( (select auth.uid()) = user_id );

// Run as user A, with the publishable key from the browser bundle
const { data } = await supabase
  .from('orders')
  .select('*')
  .neq('user_id', userAId);

// Expected: an empty array.
// Any row returned belongs to someone else: stop the launch.
// Repeat signed out, and repeat for update and delete.

If your app also puts an LLM in front of users, such as a chatbot or an assistant that reads documents, add a second layer of risks: prompt injection, sensitive data disclosure and excessive agency. Those are mapped in our guide to the OWASP Top 10 for LLM Applications.

What breaks: data

The second failure family is about data that outlives the prototype.

Test data and real data in the same place. In July 2025, SaaStr founder Jason Lemkin reported that Replit's agent deleted a production database, ignored instructions to freeze code, and invented data. Replit's CEO called it "unacceptable and should never be possible," and the company said its apps had used "a single database for both development and live customer data," then began rolling out separate development and production databases. The general lesson applies to every tool: an agent that can change the schema of the database your customers use will, sooner or later, do it at the wrong moment.

Practical rules:

• Keep a separate development database, and never point an agent at production data.
• Turn on backups and practice one restore before launch, not after the first incident.
• Seed the prototype with synthetic records. Real customer exports do not belong in a builder's chat.
• Decide where the data lives, who can export it, and how a user's account is deleted.

Personal data brings legal duties. If the app stores data about people in the EU, the GDPR applies. Under Article 4(7), the controller is whoever "determines the purposes and means of the processing," which for a vibe-coded app is normally you or your client, not the tool vendor. Article 32 then requires the controller to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk." A missing access policy is hard to square with that. This section is general information, not legal advice.

What breaks: maintainability

The third failure is slower and more expensive. Karpathy described it in the original post: the code "grows beyond my usual comprehension." That is fine for a weekend project and a problem for anything you plan to keep.

The symptoms are recognizable:

• Fix loops. Each prompt fixes one bug and quietly breaks another, because nobody holds a model of how the parts connect.
• Duplicated logic. The same rule (a price calculation, a permission check) exists in three places with three slightly different versions.
• No tests. Nothing tells you that the change you just accepted broke checkout.
• Invisible dependencies. Packages, environment variables and third-party services that nobody listed.
• Prompt history as documentation. The only record of why the app works the way it does is a long chat.

Three habits keep a prototype maintainable for much longer:

1. Connect Git from day one. All four builders keep checkpoints or a version history, and Lovable, v0 and Bolt also sync to Git or export the project. A repository you control is your exit route and your audit trail.
2. Keep scope small per prompt. One feature or one fix per request, checked in the preview before the next. Bolt's own building guide recommends adding one feature per prompt.
3. Write down decisions as you go. A short README with the data model, the roles, the environment variables and the known limitations is worth more than any amount of generated code.

A pre-launch checklist for vibe-coded apps

Before real users, real data or real money touch the app, check that you can answer yes to each line:

• Every table with user data has row-level access policies for read, insert, update and delete, tested with two accounts and signed out.
• No secret key, service key or third-party API key appears in browser code or in the repository.
• The built-in security scan has run and every finding is fixed or consciously accepted in writing.
• Dependencies were reviewed; every package name exists and is the one you meant.
• User input is validated on the server, and anything rendered back to the page is escaped.
• Development and production data are separate, backups are on, and a restore has been tested.
• The project is in a Git repository you control, with a README listing roles, data model and environment variables.
• Error monitoring and a way to take the app offline quickly are in place.
• You know who the controller of personal data is, and the privacy notice says so.

When to hand over to an engineer

Vibe coding moves the line of what a non-engineer can build. It does not remove the line. Bring in an engineer, or a security reviewer, as soon as any of these is true:

• The app takes payments or touches financial data.
• It holds personal data at scale or sensitive data (health, children, identity documents, credentials).
• It is multi-tenant: several customers or companies share one database and must never see each other's rows.
• A business depends on it: uptime, support and incident response become commitments.
• It integrates with production systems such as a CRM, an ERP or an internal API with write access.
• Fixes no longer converge: each prompt breaks something else, and nobody can explain why.

A good handover is not "here is the link." It is a repository, a one-page spec of what the app does and for whom, the data model and roles, the list of services and environment variables, the scan results, the known limitations, and the prompts or decisions that shaped the key features. The engineer will then usually do what the builder skipped: add tests around the core flows, move sensitive logic to the server, tighten access policies, set up separate environments and monitoring. Taking that work from MVP to a product with paying users, including authentication, multi-tenancy, billing, rate limiting and observability, is the subject of Build and Ship a Production AI SaaS. If you are wondering what that engineer's job looks like now that AI writes much of the code, see What Is an AI Engineer?.

The skill that makes vibe coding safe is not writing code. It is knowing which questions to ask about the code you did not write, and that judgment, across tools, integrations, security and handover, is what the vibe coding course is built to train.

Frequently Asked Questions (FAQ)

Who coined the term vibe coding? Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla, in a post on X on 2 February 2025. He described giving in to the vibes, accepting all changes without reading the diffs, and said the approach was not too bad for throwaway weekend projects.

Is vibe coding the same as AI-assisted programming? Not in the strict sense. Vibe coding means building with an LLM without reviewing the code it writes. If you review, test and can explain the code the model produced, you are doing ordinary software development with AI assistance. In everyday use, the term also covers prompt-to-app builders such as Lovable, v0, Bolt and Replit Agent.

Is vibe-coded software secure? Not by default. Veracode's 2025 tests found models chose the insecure implementation 45% of the time when a secure one was available, and the Lovable CVE-2025-48757 case showed how missing database access policies can expose user data. Built-in scanners help, but you still need to test access rules, keep secrets out of the browser and review dependencies before launch.

Which vibe coding tool should I use? Match the tool to the job. Lovable focuses on complete full-stack apps from a description, v0 on real Next.js code with a Git and preview workflow on Vercel, Bolt on building and running projects in the browser with a built-in database, and Replit Agent on an agent inside a full cloud workspace. Whatever you choose, connect Git early so you can leave.

Can a non-programmer launch a vibe-coded app to real customers? For a low-stakes app with no sensitive data, often yes, provided you run the security scan, test access rules with two accounts and separate test from production data. Once the app takes payments, stores sensitive or large volumes of personal data, or serves several customers from one database, have an engineer or security reviewer check it first.

Conclusion

Vibe coding started as Karpathy's description of accepting AI-written code without reading it, for throwaway weekend projects, and became the name for a whole category of prompt-to-app tools. Lovable, v0, Bolt and Replit Agent can now produce a working full-stack app in minutes, and they are excellent for validation, internal tools and prototypes that serve as specifications. What they do not do is take responsibility. Models still pick insecure implementations often, access policies still get published half-written, agents still touch the wrong database, and unreviewed code still becomes unmaintainable. Test access with two accounts, keep secrets out of the browser, separate development from production, keep the project in Git, and hand over to an engineer once money, sensitive data or a real business depends on the app.