What is vibe coding? Meaning, origin and how it actually works
Vibe coding is building software by telling an AI what you want in plain language, running what it makes, and judging the result by whether it works rather than by reading the code. You describe a screen, the AI writes it, you click around, and if something's wrong you say so and it tries again. The person doing it may never open a single source file.
That's the short definition. The longer answer covers where the term came from, why it caught on so fast, what the work looks like day to day, and why the same method that produces a working app in an afternoon can also leak a customer database.
Where the term came from
Andrej Karpathy coined it. He was a founding member of OpenAI and later Tesla's director of AI, where he led the Autopilot vision team, so when he posts about programming, a lot of programmers read it. On February 2, 2025 he wrote on X:
"There's 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 rest of the post is more candid than the first line suggests. He said he talks to his editor by voice, accepts every change the AI proposes without reading the diff, and pastes error messages back in with no comment because that usually fixes them. When the AI can't fix a bug, he works around it "or ask[s] for random changes until it goes away." He finished with: "It's not too bad for throwaway weekend projects, but still quite amusing."
So that's why it's called vibe coding. You go on feel. You don't verify the code line by line, you check whether the thing in front of you behaves the way you wanted.
The name spread faster than almost any tech term in recent memory. Merriam-Webster listed it as "slang & trending" on March 8, five weeks after the post, and Collins Dictionary named "vibe coding" its Word of the Year for 2025. Somewhere along the way the meaning drifted. Karpathy described a casual, slightly reckless way for an experienced engineer to play. Within months, people were using "vibe coding" for any software built mostly by prompting an AI, including software meant to run a business.
How vibe coding actually works
Strip away the hype and it's a loop. You describe something, the AI builds it, you look at it, and you describe what's wrong.
Say you run a small equipment rental company and you track bookings in a shared spreadsheet that keeps getting overwritten. A vibe coding session might start with: "Build me a booking calendar for 40 pieces of equipment. Staff log in, pick an item and dates, and the calendar won't let two people book the same item for overlapping days." A few minutes later you have a working page. You try to double-book a forklift and it lets you, so you tell it. It fixes the check. You ask for an email to the customer when a booking is confirmed, then a weekly report of which items sat idle. Each request is a sentence or two. Each result is something you can click.
What you're doing in that loop is product work: deciding what the software should do, noticing when it doesn't, and explaining the gap clearly. What you're not doing is choosing a database, writing the query that checks for overlapping dates, or configuring the email sender. The AI handles those, and in pure vibe coding you don't look at how.
The tools fall into two rough groups. AI coding assistants like Cursor, Claude Code and GitHub Copilot live inside a developer's editor and are mostly used by people who can read the code even when they choose not to. AI app builders like Lovable, Replit, Bolt, Base44 and OpenKBS start from a chat box, show you the running app next to the conversation, and are built for people who will never open the editor at all. Both get called vibe coding tools.
Vibe coding vs. AI-assisted programming
Not everyone who writes code with AI is vibe coding, and the difference matters once real money or real data is involved.
Simon Willison, the co-creator of the Django web framework, drew the line a few weeks after Karpathy's post. If you have the AI write code but then review it, test it and understand it well enough to explain it to someone else, that's just programming with a fast typist. Vibe coding is when you skip that step and accept the code because the app seems to work.
Most professional developers now sit somewhere in between. They'll vibe code a quick internal script and review every line of the payment flow. The trouble starts when someone with no way to review the code builds the payment flow, because they can't tell which parts need a second look.
Who is vibe coding, and what are they building
Startups picked it up first. In March 2025, Y Combinator's managing partner Jared Friedman said that for about a quarter of the companies in that winter's batch, 95% of the code had been written by AI. These were technical founders who could have written the code themselves and decided it wasn't the best use of their time.
The more interesting shift is the people who couldn't have written it. One of the largest platforms running on OpenKBS this year was built by Martin, a licensed aircraft maintenance engineer who had never written a line of code. Over several months he described JobAvion into existence, one requirement at a time: a professional network for pilots, cabin crew and mechanics, an AI career agent that matches people to roles, a marketplace for leasing grounded aircraft, and a module that coordinates parts and certified staff when a plane goes unserviceable away from base. It now runs to about 115,000 lines of code across 20 backend services, with 215 deployed versions so far.
Nobody in a software company would have thought to build the grounded-aircraft module. Martin did because he's spent his career watching airlines lose money on exactly that problem. That's the real promise of vibe coding for business. Software gets cheaper too, but the bigger change is that the person who understands the problem can now be the person who builds the fix, without a three-month spec-and-wait cycle in between.
On the civic side, Martin Atanasov built Diagnoza Bulgaria alone, with no team and no funding. It compares spending across 180 Bulgarian hospitals using over 3 million rows of official data, and national media covered it the day it launched.
Where vibe coding goes wrong
Karpathy's caveat about "throwaway weekend projects" turned out to be the most important part of his post, and the part most people dropped.
In March 2025, an engineer named Matt Palmer was testing a LinkedIn profile tool built with Lovable and found he could read its entire user database by tweaking a request. He and a colleague then scanned 1,645 apps from Lovable's public showcase. 170 of them had the same problem: their databases were open to anyone who knew where to look, exposing emails, phone numbers, payment records and API keys. The flaw is now logged as CVE-2025-48757. The apps worked fine in the browser. Nobody building them had any reason to check the database permissions, because nothing on screen looked wrong.
In July 2025, SaaStr founder Jason Lemkin was nine days into a public experiment building an app on Replit when the AI agent deleted his production database, records for 1,206 executives and 1,196 companies, during what he'd explicitly declared a code freeze. The agent then told him the deletion couldn't be rolled back. That was wrong, and Replit's restore brought the data back. Replit's CEO, Amjad Masad, called the deletion "unacceptable" and the company separated development and production databases so an agent can't touch live data while building. But the episode became shorthand for what happens when an AI has more access than the person directing it understands.
Both stories have the same shape. The visible part of the software worked. The failure was in the part a vibe coder never sees: who can read the data, what the AI is allowed to change, whether there's a backup. A prototype can skip all of that. Software your business runs on can't.
How to vibe code something your business will actually use
None of this means business owners should stay away. It means the questions change once the app is doing real work.
Start with one narrow, annoying problem rather than "our whole operations system." The equipment calendar is a good first project. A full ERP isn't, at least not on day one. You'll learn how to describe what you want, and you'll find out fast whether the result holds up with your actual staff.
Describe outcomes and rules, and be specific about the rules. "Only managers can approve refunds over 500 euros" gives the AI something it can enforce and you something you can test. "Make it secure" gives it nothing.
Test with real data and real people before you trust it. Have someone who wasn't involved try to break it. Log in as a regular employee and try to see what a manager sees.
Then look hard at where the app lives. Many vibe coding tools are excellent at producing a working front end and leave the rest to you: hosting, the database, backups, email sending, a custom domain, who has access to what. Those are the parts that failed in both stories above. This is the gap we built OpenKBS to close. When you describe an app in OpenKBS, it gets a production database with point-in-time recovery, hosting, email, a domain and AI agents in the same project, on the same infrastructure our enterprise customers run on, so moving from "it works on my screen" to "forty people use it every morning" doesn't mean migrating to something else. And when a project is beyond what you want to build yourself, our team builds it with you.
A useful test for any tool, including ours: ask what happens if you accidentally delete every record at 4pm on a Friday. If the answer is a support ticket and a shrug, you're still in weekend-project territory.
Start building free · Talk to us about a custom build