What is vibe coding?
Engineering culture and software practice
Vibe coding means building software by describing what you want to an AI system and accepting what it produces on feel, without reading or understanding every line. The computer scientist Andrej Karpathy coined the phrase in a social media post on 2 February 2025 to describe a playful, throwaway way of working. It was quickly stretched to cover almost any prompt-driven building, and the gap between those two senses is where most of the trouble sits.
What this means
Vibe coding is what happens when a person builds software mostly by talking to an AI model. You describe the thing you want in plain language, the model writes the code, you run it, and if it looks right you keep going. You do not necessarily read the code or understand how it works. You steer by feel.
The pattern got a name because it is genuinely new. For decades, writing software meant knowing a programming language and being responsible for every line. Vibe coding breaks that link: the person directing the work may never look at the code at all. That is powerful and, in the wrong setting, dangerous, which is exactly why it needed a label.
This article uses the term in both of its live senses and keeps them apart. The original sense is the loose, exploratory play Karpathy described. The broadened sense, common since, treats vibe coding as shorthand for any AI-assisted building. Knowing which one someone means is the whole game.
Why it matters
Vibe coding lowers the cost of turning an idea into something that runs. A person with no engineering training can now produce a working prototype in an afternoon. For a small organisation, that changes who can build internal tools and how quickly an idea can be tested before money is spent.
It also changes what leaders are told. A board may hear that a supplier vibe-coded the product, or that a colleague built the new reporting tool over a weekend. The right response is neither alarm nor applause but a question: was this a throwaway experiment or something that now holds other people's data or money?
The stakes differ enormously by setting. For a prototype, a personal tool or a one-off analysis, accepting code you do not fully understand is a reasonable trade. For anything that stores customer records, moves money, or must be maintained for years, code that nobody understands is a liability waiting to surface. The citizen-developer movement, where non-specialists build their own tools, has wrestled with this for years; vibe coding pours accelerant on both the benefits and the risks.
There is also an honesty point. As of September 2026 the evidence on whether AI assistance makes software work faster is genuinely mixed, and the loudest claims in both directions outrun the data. A sensible leader treats productivity gains as plausible but unproven, and asks to see the review and testing that turns a demo into something dependable.
How it works
Where the term came from
Andrej Karpathy, a computer scientist and a founding member of OpenAI who was previously senior director of AI at Tesla, posted the phrase on the social media platform X on 2 February 2025. He described a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists". He framed it as a playful, low-stakes way to build, iterating by voice and feel rather than reading each change.
The term stuck hard, which is the test of whether a coinage is a fad. Merriam-Webster listed it as a slang and trending term on 8 March 2025. Collins Dictionary named vibe coding its Word of the Year for 2025, announced on 6 November 2025. Academic work followed through 2025 and 2026, with preprints on the arXiv repository analysing vibe coding as a practice. National and international press covered it steadily rather than in a single burst. Karpathy himself has since called the original post a throwaway thought, while accepting that it named something many people were feeling at once.
Why it works at all
Three things make vibe coding possible. Modern language models are good enough at generating plausible, often working code that a beginner can get a running result on the first or second try. The feedback loop is tight: you run the code, see what breaks, paste the error back, and the model tries again. And the cost of trying again is close to zero, so trial and error becomes a viable way to build rather than a sign of failure. Together these turn programming into a conversation rather than an act of authorship.
How the two senses drift apart
The original sense was about disposable work: a weekend app, a personal script, a quick experiment where nobody is harmed if it is wrong. The broadened sense quietly dropped the "disposable" part and now gets applied to production systems that real people depend on. The word did not change; the setting did. Most of the reputational damage attached to vibe coding comes from using a throwaway technique to build something that was never throwaway.
The failure modes
The recognisable failures are consistent. Code nobody understands cannot be safely changed later, so a small fix becomes a rebuild. Security holes slip in because the model optimises for something that runs, not something that is safe. Dependency and licensing surprises appear when generated code pulls in libraries nobody vetted. And the demo that dazzled in the meeting turns out to be unmaintainable when it meets real data and real users. None of these are exotic; they are the ordinary consequences of accepting work you have not inspected.
How experienced teams handle it
Disciplined teams keep vibe coding but wrap it. They decide in advance what may be vibe-coded and what may not. They treat generated code as a draft to be read, tested and understood before anything important depends on it. This is the honest version of AI-assisted engineering: the model does the typing, but a human still reviews the diffs, writes or checks the tests, and remains accountable for what ships. The distinction is not AI versus no AI; it is reviewed versus unreviewed.
Examples
Consider a marketing lead at a professional services firm who wants a dashboard that pulls campaign figures into one view. She describes it to an AI tool and has something usable within a day. Because it reads from a copy of the data and only she uses it, this is vibe coding at its best: fast, cheap and low-risk. The sensible boundary is that if the firm ever wants to roll it out to clients, it goes through proper review first.
Now consider a charity whose volunteer builds a small system to track beneficiaries, vibe-coded in a few evenings. It works in the demo. But it holds sensitive personal data, and nobody can explain how it stores or protects that data. Here the same technique has crossed a line. The trustees should treat it as an unreviewed prototype, not a live system, until someone competent has read the code, checked the security and confirmed it meets the charity's data obligations.
Finally, a software team of eight uses AI to generate a first draft of a new feature. The difference from the charity case is process: every generated change is reviewed by a person, covered by tests and understood before it merges. They gain speed without giving up accountability. This is the model most organisations should aim for.
Common misunderstandings
The first misunderstanding is that vibe coding means the same thing to everyone. It does not. Some people mean Karpathy's playful, throwaway practice; others mean any use of AI to help write code. Before reacting to the word, find out which sense is meant.
The second is that vibe coding is just cowboy coding with a new coat of paint. It is not. Cowboy coding is undisciplined human hacking, where a person writes code without process or review. Vibe coding is AI-mediated: the central issue is not a rushed human but trust placed in machine-generated output that no human has read. The failure looks similar but the cause is different.
The third is that vibe coding replaces engineers. Rather, it moves the work. Someone still has to decide what to build, judge whether the result is right, and take responsibility when it is not. On anything that matters, that someone needs to understand code, even if they did not type it.
The fourth is that if it runs, it is fine. Running is not the same as correct, secure or maintainable. A program can install cleanly, pass a demo and still be riddled with problems that only surface under real use.
The fifth is that vibe coding is inherently reckless. In the right setting, for prototypes, personal tools and throwaway analysis, it is a perfectly reasonable way to work. The recklessness comes only from using it where the consequences are serious.
Risks and boundaries
This is a recent term, coined in February 2025, and its meaning is still moving as of September 2026. Anyone using it precisely should say whether they mean the original throwaway practice or the broad prompt-driven sense, because the word alone no longer settles the question.
The main risk is category error: applying a technique designed for disposable work to systems that hold data, money or reputations. Vibe coding does not cover the discipline that production software needs, and it is not a substitute for review, testing and clear ownership. The folklore that anyone can now build anything safely outruns the evidence. So does the opposite folklore that all AI-assisted code is junk; plenty of teams ship reviewed, tested, AI-drafted code responsibly. The live debate is about where the line falls, and that debate is not settled.
What to do next
Start by asking, of anything vibe-coded that someone wants to put into use, one question: does this hold other people's data or money, or will it need to be maintained? If yes, it must be reviewed and understood before it goes live, however impressive the demo.
Write a short, plain policy that says what may be vibe-coded freely (prototypes, personal tools, throwaway analysis), what must be reviewed before use, and what must be built properly from the start (anything customer-facing or handling sensitive data). Keep it to a page.
When a supplier says they vibe-coded your product, ask who has read the code, what testing exists, who owns it, and what happens when the person who built it leaves. Treat vague answers as a warning.
Invest in the reviewed version of AI-assisted building rather than banning the tools. The gain is real when a human still checks the work; the danger is only in skipping that step.
FAQs
Who coined the term vibe coding?
Andrej Karpathy, a computer scientist and founding member of OpenAI, coined it in a post on the platform X on 2 February 2025, describing a playful way of building software by feel.
Is vibe coding the same as AI-assisted engineering?
Not quite. AI-assisted engineering keeps human review, testing and understanding. Vibe coding in its original sense deliberately drops those, which is fine for throwaway work but not for anything that matters.
Is vibe coding safe for a business application?
Only after review. For prototypes and personal tools it is fine. For anything holding customer data or money, code that nobody understands should not go live until a competent person has read and tested it.
Does vibe coding mean we no longer need engineers?
No. It shifts their role toward directing, judging and taking responsibility. On systems that matter, someone still needs to understand the code, even if AI wrote it.
Why is vibe coding suddenly everywhere?
A tight feedback loop, capable models and near-zero cost of retrying made it accessible. Dictionary recognition in 2025 then pushed the phrase into mainstream use.
What should I ask before something vibe-coded goes into use?
Ask what it touches, who has reviewed it, what tests exist, and who will maintain it. The answers tell you whether it is a safe tool or an unreviewed prototype.