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. If you've already shipped something with one of these tools, audit your AI-built app.

Key takeaways

• Vibe coding is software development by describing what you want in plain English to an AI tool; the term was coined by Andrej Karpathy in 2025.
• The community is split. Speed and accessibility on one side; hidden technical debt and security holes on the other.
• Best fit: prototypes, internal tools, and personal projects. Risky for production systems without a senior-engineer audit.
• Tools that matter in 2026: Cursor, Lovable, Bolt.new, Replit Agent, v0.

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.

Vibe coding vs traditional development

In traditional development, an engineer translates a specification into code by hand, choosing the architecture, writing each function, and owning every line. In vibe coding the order flips: you describe the outcome, the AI drafts the implementation, and you review the result at the level of behavior rather than syntax. This is the shift Andrej Karpathy pointed to in his original 2025 post, where the developer gives up line-by-line control and steers by outcome instead.

Updated July 2026: added a side-by-side comparison of vibe coding versus traditional development, three concrete build examples (an admin dashboard, a booking prototype, and a waitlist page), and four new questions covering whether vibe coding counts as real programming, coding without experience, production safety, and its effect on developer jobs.

Traditional development front-loads effort. You plan the data model, set up the project, and often write tests before the feature feels real. Vibe coding front-loads output: a working screen appears in minutes, and the hard parts (validation, edge cases, security) move to the end, where they are easy to skip. That trade is fine for a prototype and risky for a payment flow. Traditional teams pay that cost up front; vibe coders defer it, which is why the same app can feel effortless on day one and fragile by month three.

A quick contrast of the two approaches:

• Speed to first working version: traditional is slower, vibe coding is near-instant.
• Understanding of the code: traditional is high, vibe coding is often low.
• Cost of the first change: traditional is higher, vibe coding is lower.
• Cost of the tenth change: traditional stays flat, vibe coding tends to climb as hidden complexity surfaces.
• Best owner: traditional suits teams shipping to production, vibe coding suits builders validating an idea.

Neither approach is strictly better; the right choice depends on the stakes. Picking a platform that matches your risk level is half the work, which is why it helps to compare the vibe coding tools before committing to one.

Real examples of vibe coding

To make the workflow concrete, here are three representative projects and what the AI produced in each.

A solo founder builds an internal admin dashboard. They describe the tables they need, the filters, and a login screen. The tool scaffolds a React front end, a small database, and basic auth, then wires up create, read, update, and delete pages. Within an afternoon the founder has a usable tool for their support team, though the login was generated without session expiry until they thought to ask for it.

A designer prototypes a booking app to test a product idea. They prompt for a calendar view, a form that collects a name and email, and a confirmation screen. The AI generates a functional flow the designer can click through in a user test, with no engineering sprint required. The data is stored, but validation on the email field stays thin until someone flags it.

A marketer builds a landing page with a waitlist. They ask for a hero section, a signup form, and a thank-you state, then keep refining the copy and colors by conversation. The result ships the same day. If you want to try the same loop yourself, our guide on how to vibe code walks through the prompts step by step.

The pattern is consistent: the AI gets you to a working version fast, and the parts that decide whether the app survives real users (auth, validation, rate limits) are exactly the parts that need a second look. That is where a professional review of a vibe-coded app earns its keep, especially before you take payments or raise money. Treating the AI output as a strong first draft rather than a finished product is the difference between a demo that impresses and a product that holds up under real traffic.

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.

Source: the origin and public record of the term vibe coding.

Related reading: how to vibe code

Rick Rubin and the vibe coding culture shift

The clearest sign that vibe coding crossed from engineering slang into mainstream culture came from music producer Rick Rubin. In 2025 he published The Way of Code, a meditation on creativity and AI-assisted programming created in collaboration with Anthropic, reframing vibe coding as a creative practice rather than a shortcut.

Rubin's framing matters for founders: it captures why non-engineers now ship software, and why the discipline gap (testing, security, code review) is the part of the craft that AI does not supply. The tooling made building easy; the engineering judgment still has to come from somewhere.

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.

Frequently asked questions

What is vibe coding?

Vibe coding is a programming style where the developer prompts an AI tool to generate code instead of writing it manually. The term traces back to Andrej Karpathy's February 2025 post describing the workflow as 'giving in to the vibes' and steering the model toward the desired result.

Who coined the term 'vibe coding'?

Andrej Karpathy popularized the phrase in February 2025. The practice predates the term, but his post crystallized it as a recognizable style of building software.

Which tools are used for vibe coding?

The most common are Cursor, Lovable, Bolt.new, v0, Replit AI and Cline. Each tool offers a slightly different mix of inline completion, repo-wide generation and full-app scaffolding.

Is vibe coding the same as no-code?

No. No-code platforms hide the code entirely. Vibe coding produces real source code that the developer can read, edit and deploy. The difference matters when an app needs custom logic, audits or compliance review.

Should startups vibe code their MVP?

Vibe coding is fast for a first prototype, but production launch requires a senior-engineer review. AI-generated code routinely ships with insecure defaults that look fine until traffic or auditors arrive.

Is vibe coding real programming?

Yes, in the sense that it produces real, runnable source code in a normal stack. What changes is the author's relationship to that code: they direct the AI and review behavior rather than writing each line. The code is real; the open question is whether anyone on the team understands it well enough to maintain it.

Can you vibe code without knowing how to code?

Largely yes for a first version. Non-engineers routinely ship prototypes and internal tools this way. The limits appear when something breaks in a way the tool cannot fix on its own, or when the app needs secure defaults. At that point some code literacy, or a reviewer who has it, becomes essential.

Is vibe coding safe for production?

Not by default. Vibe coding tools optimize for shipping speed, so generated apps often arrive with weak auth, thin input validation, and no rate limiting. It can be made production-safe, but that takes a senior-engineer review to harden the code before real users or payments are involved.

Will vibe coding replace developers?

Unlikely in the near term. It lowers the barrier to a working prototype, but the judgment work (architecture, security, debugging failures no one anticipated) still needs experienced engineers. The more probable outcome is a shift in what developers spend time on, with review and hardening of AI-built code becoming a larger part of the job.