Vibe Coding Explained: Meaning, Origins, and Risks

Vibe coding is a software development style where a person describes what they want in plain English and an AI tool — Cursor, Lovable, Bolt.new, Replit, v0 — writes most of the code. The developer steers the model with prompts instead of writing functions line by line. The term was coined by Andrej Karpathy on X in February 2025, and it now describes how a fast-growing slice of consumer and B2B apps actually get built.

Who coined the term "vibe coding"

Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla, posted the original definition on February 2, 2025. He described it as "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." The phrase went from a single tweet to a category descriptor in under a week — by the end of February 2025 it was being used in YC pitches, on Replit's landing page, and in Cursor's product copy.

What made the term stick is that it named something developers were already doing but had no word for. Working with Cursor or Lovable is qualitatively different from autocomplete: you stay in the conversation, you barely read the diff, and you measure progress by whether the app feels right rather than whether you understand the code.

How vibe coding actually works

The mechanics are straightforward. You open a tool that pairs an AI model (usually Claude, GPT-4o, or Gemini) with a code editor or runtime. You type what the app should do. The tool writes the files, installs dependencies, wires up auth, and deploys. You run the result, find what's broken or missing, and ask for the next change.

The loop is conversational, not editorial. A vibe coder rarely opens individual files. They read error messages, paste them back, and let the model resolve them. The output is a working app — sometimes a polished one — that the person who built it could not have written manually.

What separates vibe coding from autocomplete

GitHub Copilot suggests the next few lines while you type. Vibe coding tools build the whole feature while you describe it. The difference is who holds the spec:

• Copilot — the developer holds the spec, the model fills in tokens.
• Vibe coding — the model holds the implementation, the developer holds only the intent.

Who actually vibe codes

The pattern shows up in three groups:

• Non-engineer founders shipping MVPs in 48 hours instead of waiting on a contractor.
• Designers and PMs building functional prototypes to test product hypotheses before engineering invests sprint time.
• Senior engineers who use the tools to skip boilerplate — auth flows, dashboards, CRUD — and stay focused on the parts that need their judgment.

Lovable reportedly hit $1M ARR within the first month after launch, almost entirely from non-engineers building B2B apps. Replit's 2025 fundraise pitched the same audience. The category is real and the revenue is real — and that is exactly why what gets shipped matters.

Why engineers are divided on it

Some senior engineers — including Linus Torvalds in a widely shared interview clip — pushed back hard on the framing. The objection is not that AI-assisted coding is wrong; it's that "forget the code exists" is a recipe for shipping software no one understands. When the person who built the app cannot read it, they also cannot reason about its failure modes — and most production failures live in code paths that the original author never thought about.

The counter-argument: web development was never universally understood by its authors. Most jQuery sites in 2010 worked in spite of, not because of, their authors' deep grasp of the DOM. Vibe coding just shifts the literacy bar one layer higher.

The argument that matters for founders

The technical debate is interesting; the commercial one is concrete. If you raise a seed round and the diligence partner runs your repo through a code review, what do they find? If your app handles user data and stores credentials, what is your blast radius when something breaks? The answers depend not on whether you vibe coded but on whether the result was audited.

Real risks every founder should understand

Vibe coding tools optimize for shipping speed, not for production-grade defaults. The patterns that show up most often in shipped vibe-coded apps:

• Hardcoded credentials and exposed API keys — committed to repos, pasted into client code, or left in environment files that ship to the browser.
• Broken authentication — session cookies without expiry, missing CSRF protection, JWT secrets left as the literal string "secret."
• Missing input validation — direct user input piped into database queries, file paths, or shell commands.
• No rate limiting — endpoints that accept unbounded requests, including expensive AI-generated ones.
• Outdated or vulnerable dependencies — the model picked whatever version was popular in its training data, which is often two years stale.

None of these are unique to AI-built code. What is unique is the rate: a senior engineer writing the same app would catch most of them during the first review pass, because they would actually be reading what was written.

For a tool-by-tool view of which platforms leave the worst defaults, see our breakdown of vibe coding tools and which one is right for you. For the security view specifically, the next post in this series covers vibe coding security risks in detail.

When vibe coding is a fit — and when it's not

The honest decision rule:

• Fit: internal tools, prototypes, demos, content sites, marketing pages, single-user utilities, anything that touches no PII and accepts no payments.
• Borderline: B2B apps with paying customers, anything storing credentials, any product that will be reviewed by an acquirer or investor.
• Not a fit (without a review): healthcare, finance, anything regulated, anything where a security incident has reportable consequences.

The borderline cases are where most founders get stuck. The vibe-coded app works for 100 users. The question is what happens at 10,000 — or what happens during due diligence on a Series A. That's the moment a topic-pillar understanding of vibe coding stops being theoretical, and the answer becomes a concrete decision: ship as-is, refactor, or get a professional review.

What the next 12 months look like

Three things are likely to play out:

• Tools converge on safer defaults. Replit and Lovable will close the most-cited security gaps because doing so unlocks enterprise contracts.
• A new role emerges. "Vibe code auditor" or "AI-assisted code reviewer" — a senior engineer whose job is to harden vibe-coded apps before they go to production. This is what Valletta's Vibe Coding Audit is.
• Investors require a code review as part of standard diligence on AI-built startups, similar to how they require a financial audit. Several pre-seed funds already do this informally.

Vibe coding is not going away. The question is not whether it's good or bad — it's how to capture the speed without inheriting the failure modes. The cost of getting that wrong is measured in technical debt that compounds before your first engineering hire arrives.

Frequently asked questions

What is a vibe coder?

A vibe coder is anyone who builds software primarily by describing intent to an AI tool rather than writing code line by line. Most are founders, designers, or PMs without a traditional engineering background, though a growing number of senior engineers use the same workflow for parts of their stack.

Is vibe coding bad?

It is neither inherently bad nor inherently good. The output is only as safe as the spec and the review. A vibe-coded internal dashboard is fine. A vibe-coded payment flow with no audit is a liability — not because the AI wrote it, but because no one reviewed it.

How is vibe coding different from no-code?

No-code platforms (Bubble, Webflow, Airtable) constrain you to a fixed component model. Vibe coding produces actual source code in a normal stack — React, Next.js, Postgres — that you can read, fork, and self-host. The flexibility is higher; so is the surface area for things to go wrong.

Can a vibe-coded app pass investor due diligence?

Yes, if the code is reviewed. Investors do not care how the code got there; they care about whether it works, whether it's secure, and whether a future team can maintain it. A senior-engineer audit before the term sheet is the cheapest way to answer all three.

What does Karpathy think now?

Karpathy has clarified publicly that vibe coding works for "throwaway weekend projects" and not for production systems with users and data. The original tweet was descriptive, not prescriptive. The category outgrew the original framing within weeks.