What Is Vibe Coding? The Definition, the Record, and What It Cost Us

What is vibe coding?

Vibe coding is building software by telling an AI model what you want in plain language and taking the code it produces on trust. The three definitions in circulation agree on the first half and differ on the second, and the difference is the whole subject. Andrej Karpathy, who named it, described a mode where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists”, accept every change without reading the diff, and let “the code grow beyond your usual comprehension”. Collins, which made it Word of the Year on 6 November 2025, defines it as “the use of artificial intelligence prompted by natural language to write computer code”, which drops the not-reading part. Simon Willison put it back: “building software with an LLM without reviewing the code it writes”.

This page uses Willison's line, because it is the one that changes what you do. Under Collins' definition every run on this site is vibe coding. Under Willison's, none of them is, because each result was checked in the preview, in the database or by a script before it was written up. The practical question is not whether AI wrote the code. It is whether anything stood between the model's output and the person using it.

Where did the term come from, and how fast did it spread?

From one post to a dictionary in nine months. Wikipedia, read on 27 September 2026, dates Karpathy's post to February 2025, Merriam-Webster's slang-and-trending listing to March 2025, and Collins' Word of the Year to 6 November 2025. Collins' own announcement says the term “has resonated far beyond Silicon Valley, speaking to a broader cultural shift towards AI-assisted everything in everyday life”. In between, Willison's post of 19 March 2025 tried to keep the word narrow, and Andrew Ng argued in June 2025 that it “misleads people into assuming that software engineers just go with the vibes”. Both lost the naming argument and won the practical one: the word now means any AI-written code to most people, and the people who ship it still review it.

The builders followed the word. Lovable's own explainer, published 3 March 2025, opens with “Vibe coding is about building software without worrying about syntax.”, and its marketing page now calls it development driven by intent rather than syntax. Replit, GitHub and Google Cloud each have a page with the same title as this one. What none of them prints is a run: a prompt, what came back, and what it cost.

What does a vibe coding session look like, measured?

Like this: a prompt pasted in, a few questions back, a build of five to fifteen minutes, and a balance that moves. The run below is the SaaS foundation prompt from this library, pasted into a new Lovable project on 26 September 2026 in Marco's own workspace. Lovable asked four questions before building, enabled its Cloud backend, built sign-up, workspaces and invites, tested the invite flow itself, and the run cost 10.4 credits read from the billing page. Every claim in that sentence has a screenshot on the SaaS prompts page.

The questions are the part that matters. They exist because every prompt in this library now ends with a line asking the model for its questions before it builds, which Lovable's own guide recommends. Across the six runs measured so far the model asked 11 questions in the 3 runs whose prompt carried that line, and zero in the others. A vibe does not get asked anything. A brief does.

What does vibe coding cost?

On Lovable, between one and eleven credits per prompt in our runs, and 30.4 credits for all six together. The spread is the useful number. A review that changes no code cost 1.1. A landing page with an opt-in cost 1.8. Adding an installable shell to an existing app cost 3.1, a six-section landing page with five questions first cost 4.5, a gallery of empty and loading states cost 9.5, and the SaaS foundation with auth and roles cost 10.4. Scope drives the bill, not word count: the states prompt was shorter than the landing page prompt and cost five times more, because it touched every screen.

What a credit costs in money depends on the plan, and the plan table is rendered in the browser, so it cannot be quoted from a fetch and goes stale in a week. This page states no prices. The pricing guide reads the plans on the day and prints the check date, and the credits guide explains what a build credit and a run credit each buy.

What goes wrong with vibe-coded software?

More issues per change, and the security ones grow fastest. CodeRabbit analysed 470 open-source pull requests, 320 AI co-authored and 150 human-only, and reported 10.83 issues per AI-authored PR against 6.45 for human-only ones, published 17 December 2025. Security issues were up to 2.74 times higher, logic and correctness issues 75% more common, readability issues more than three times as frequent. Veracode's 2025 report, testing more than 100 language models across Java, JavaScript, Python and C#, is blunter: “AI-generated code introduced risky security flaws in 45% of tests.”

The builder platforms are in the record too. Insufficient row-level security in Lovable-generated projects carries CVE-2025-48757, which Lovable disputes and which the security guide covers with the scan we ran ourselves. And this site is in it: the vibe coding tips page lists twelve things that shipped wrong here, from git, including a paywall that sent the paid data to every visitor for months because the lock was a picture of a lock. Five of the twelve looked finished. None was caught by looking.

None of these numbers says AI-written code is unusable. They say the review step the vibe skips is where the defects would have been caught, and that the security ones are the ones it skips most expensively.

Where is the line between vibe coding and AI-assisted development?

At the check. Willison's test is whether you reviewed the code, tested it and could explain it to someone else. That is a high bar for a person who came to Lovable because they cannot read the code, so the version this site uses is one step lower and still holds: something other than the model verifies the result before a user touches it. A preview you click through. A query run as the wrong user. A script that fails when the paywall opens. The table is the spectrum as we work it.

The middle row is what the prompt library on this site is built for, and the prompting guide explains each section. The bottom row is the tips page, which is what running this site with AI tools taught us the hard way.

When should you vibe code, and when not?

Vibe when being wrong is cheap; brief when it is not. The cost of a mistake, not the size of the app, is the deciding variable. A prototype to show a co-founder can be built in one sentence and thrown away. A landing page that collects emails already holds other people's data, and the run that built ours in 1.8 credits had a Safe-Guard section that said so. A SaaS foundation with roles is where a missing policy becomes a breach, which is why the SaaS prompt carries data rules before features and why the kits on this site ship verification queries to run as the wrong user.

The idea-to-app guide walks the middle column end to end, and the MVP ledger shows what a day of it cost on one project.

How do you start without the vibes taking over?

Write the five things the model would otherwise guess, then ask it what it still needs. Lovable's prompting guide puts the working rule as saying what to change and what to leave alone; its idea-to-app guide adds one change per prompt and a 15-minute plan before the first one. The skeleton below is the prompt that built our landing page for 1.8 credits, and every prompt in the library follows it.

Then three habits, each from a mistake on this site. Verify what the crawler or the user gets, not what the chat says it built: two of our pages served 724 characters to Google for months while the browser showed a full article. Never type a number the code enforces: a quota claim survived three rewrites here because it was prose. And run the builder's security scan from its own tab, because asking the chat to run it does not run it, as the security guide found.

The ten short prompts on the vibe coding prompts page are the smallest version of this skeleton, and the coding prompts page carries the same idea for an editor rather than a builder.

Sources

All read on 27 September 2026.

• Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", 19 March 2025, which reproduces Karpathy's post.
• Collins, Word of the Year 2025 announcement, 6 November 2025.
• Wikipedia, Vibe coding, for the Merriam-Webster listing and the Andrew Ng quote.
• CodeRabbit, State of AI vs Human Code Generation, 17 December 2025.
• Veracode, 2025 GenAI Code Security Report, October 2025 update.
• CVE-2025-48757, the CVE record.
• Lovable, What Is Vibe Coding?, 3 March 2025; Lovable docs, prompting; Lovable docs, from idea to app.
• GitHub, What Is Vibe Coding?: about 5,800 words, 15 sections, no images, no measured build, no cost.
• Tanium, What is vibe coding? The pros, cons, and controversies: about 6,500 words, one header image, eleven cited reports, no build of its own.
• Replit, What is Vibe Coding?: about 2,800 words, three images, a vendor speed claim, no credits or cost.

What we did not publish

• Karpathy's post verbatim in full: the platform it lives on cannot be fetched from here, so the quotes are the fragments Willison reproduced.
• A speed multiplier. Replit's page cites a third-party 5.8x figure we could not verify, so it is not repeated.
• Runs on any builder other than Lovable. The comparison pages say why: no accounts are created for the purpose.
• A count of people who vibe code, or apps built that way. No source we fetched publishes one.
• Google Cloud's page on the same query was in the top three but could not be read in full, so its structure is not audited above.