Vibe coding

What is vibe coding?

Vibe coding is building software by describing what you want in plain language, accepting whatever the model writes without reading it, and iterating on the running result instead of the source. You stay at the level of the thing that works or does not work. The code itself is something you never really open.

Andrej Karpathy named the practice in a post in early February 2025: "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." In the same post he described accepting every suggested change without reading the diffs, pasting error messages back into the tool with no explanation, and letting the code grow past the point where he could still say what it did. He was describing his own weekend projects.

The term travelled well beyond that. Collins Dictionary made vibe coding its Word of the Year on 6 November 2025 and defined it as "the use of artificial intelligence prompted by natural language to write computer code".

Collins' wording is wider than Karpathy's, and the gap is worth holding on to. Under the Collins definition, every developer who asks an assistant for a function is vibe coding. Under Karpathy's, the move that defines it is skipping the review.

Where vibe coding earns its keep

The situations where it works well share one property: nobody has to live with the code afterwards.

• Throwaway prototypes. You want to see a version of the idea on screen before deciding whether it deserves a real budget. A working mock answers questions that a specification document argues about for two weeks.

• One-off scripts. Renaming four thousand files, reshaping one awkward CSV export, pulling a number out of a folder of PDFs. The script runs once and gets deleted.

• Exploring something you cannot yet describe. Sometimes the fastest route to a clear requirement is three bad versions of it.

• Personal tools with exactly one user. If it breaks, the only person affected is the one who asked for it, and they know how it was made.

A worked example. A sales manager wonders whether margin per customer per month would change how the team prioritises accounts. Instead of opening a request, she describes the calculation to a model, gets a small script that reads last year's export and draws the chart, and looks at it. The chart is enough to tell her the answer is yes. The script has served its purpose and nothing about it needs to survive the conversation that follows.

Vibe coding versus reviewed AI-assisted development

Simon Willison, who did more than anyone to pin the term down after it spread, states the boundary directly: vibe coding is "building software with an LLM without reviewing the code it writes". And on the other side of the line: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development."

This is the distinction most conversations lose. A professional who reads every diff, runs the test suite, and can defend the design in a review is using the same tools at ten times the speed, and none of that is vibe coding by the original meaning. Willison calls that version vibe engineering and argues it demands more discipline than working without the tools, because you now need tests good enough for an agent to iterate against and specifications clear enough to hand over.

Vibe coding versus low-code and citizen development

A low-code platform hands a business user a fixed set of building blocks inside an environment that somebody administers: named connectors, permission models, an inventory of what exists. A citizen developer builds within those walls, and the walls are the point.

Vibe coding has no walls. What comes back is a general-purpose code file that can reach anything the machine running it can reach. That is exactly why it is more flexible, and exactly why nobody has an inventory of it.

What to watch out for with vibe coding

Maintenance arrives first. The moment something needs to change, the person changing it has to understand code that nobody has ever read. Feeding the whole thing back to a model and asking for the change is a real option, and it works until it does not, at which point there is no fallback because there was never any comprehension to fall back on.

Security arrives second and quietly. Veracode tested more than 100 large language models across 80 coding tasks and reported in 2025 that 45 percent of the generated code contained a security flaw. A model writes what the prompt asked for. If nothing in the prompt mentioned input validation or access control, nothing in the output will either, and nobody reading the result would notice, because nobody read the result.

Then there is everything that assumes a person can explain the software: an audit, a handover when the author changes jobs, a customer asking how a figure was calculated, a data protection question about where personal data ended up. Each of these needs an answer that vibe coding structurally cannot produce.

When a vibe-coded tool ends up in daily use

The pattern is familiar in a small company. Someone in operations builds a small thing that solves a real annoyance. Two colleagues start using it. Then it feeds a weekly report, then a customer sees a number that came out of it, and at no point did anyone decide that it was now a system.

Nothing went wrong in that story. The tool was useful, and building it was faster than any alternative. What is missing is a moment where someone asks the ownership question out loud.

A short set of questions is usually enough to catch it in time. Who fixes this when it breaks on a Friday? What happens to it when its author leaves? Does it touch personal or financial data? Is a number from it going anywhere a customer or an accountant will see?

If the answers are comfortable, keep going. If they are not, the tool has stopped being a prototype and needs someone to read it, test it, and take responsibility for it. That is a normal and inexpensive step at that moment, and an expensive one two years later.