Vibecoding, minus the marketing

Vibecoding means describing what you want in plain language and letting an AI write the code. Not reviewing every line. Not understanding every function. Describe, look at the result, adjust the description, repeat. That is the actual break: the developer stops writing code and becomes the person who states an intent and judges an outcome.

The term fascinates as much as it irritates. To some it promises the end of programming; to others it evokes a generation of software nobody will be able to maintain. Both camps are partly right, which is exactly what makes the subject worth examining.

Where the term came from

Andrej Karpathy, former director of AI at Tesla and a founding member of OpenAI, posted a message in February 2025 that popularised the expression. He described a way of programming where you give in to the vibes, forget the code exists, and accept suggestions without even reading them. He was talking about throwaway projects, weekend work, things with nothing at stake.

That nuance vanished within weeks. The term was picked up to describe any AI-assisted development, including in production, including on systems handling money or personal data. This drift is the problem, far more than the practice itself.

It's not really coding — I just see stuff, say stuff, run stuff, and it mostly works.

What it genuinely changes

The most measurable effect is not writing speed. Writing code was never the bottleneck in a software project: understanding the need, deciding the architecture, correcting misunderstandings and maintaining the whole thing account for most of the time. Vibecoding speeds up the part that was already fastest.

What it really changes is the cost of an attempt. Testing an interface idea used to cost half a day, so you tested one. Now it costs twenty minutes, so you test five and keep the best. That is not the same as going faster: it is exploring more widely before committing.

The second effect is a shift in where skill matters. Value no longer lies in knowing how to write a loop, but in spotting that the generated code is subtly wrong. An experienced developer and a beginner get the same code from the AI; only the first notices the missing error handling.

The three levels of vibecoding

Treating vibecoding as a single practice is the source of most disagreements about it. There are at least three uses, and their risks are not remotely comparable.

1. Throwaway

A script that renames three hundred files, a mockup to illustrate an idea in a meeting, an internal tool used twice. Here pure vibecoding is entirely justified: the code is not meant to live, nobody will maintain it, and its quality does not matter as long as the output is right. This is exactly the original use case.

2. The prototype that outlives its purpose

The most common case, and the most dangerous. You quickly generate something that works to validate an idea, people like it, it goes to production "for now", and three years pass. The trap is not technical but organisational: nothing visually distinguishes a prototype from a finished product when both have a polished interface.

3. Deliberate production use

The AI generates, but everything goes through review, tests and a security pass. This is no longer vibecoding in the strict sense — you read the code — but it is where most serious teams have landed. The speed gain is real, smaller than advertised, and sustainable.

What vibecoding does not replace

A generative model produces what statistically resembles correct code. The resemblance is excellent on problems solved a thousand times before, and misleading on everything else. Three areas resist particularly.

• Architecture decisions. The AI always offers a plausible answer to "how should I structure this?", but it knows neither your load constraints, nor your team, nor what you plan to do in two years.
• Implicit domain rules. What nobody wrote down but everyone in your industry knows appears in no training corpus.
• Security. Generated code is functional before it is safe, because it is trained on public code, a good share of which is vulnerable.

That last point is serious enough to deserve its own guide, with the specific vulnerabilities to look for and how to detect them.

Where to start

If you are starting out, the progression that works best is to begin with low-stakes work and tighten requirements gradually, rather than aiming straight at production.

1. Pick a real internal tool you actually need — not a tutorial. The stakes must be low enough to afford failure, real enough that output quality is noticeable.
2. Use version control from the first line. Vibecoding produces a lot of code fast; without history, rolling back becomes impossible and you will accept regressions out of fatigue.
3. Have someone review it, or ask a second model to critique the first one's code. An AI reviews code it did not write remarkably well.
4. Add tests on what you cannot afford to break. Not everywhere: on the three or four behaviours the tool's usefulness depends on.
5. Only ship what you can explain. If you cannot say what a file does, you will not be able to fix it on a Sunday night.

Further reading

Six guides cover the points that cause the most trouble in practice: writing prompts that produce usable code, security of generated code, visual consistency when AI draws the interfaces, the technical debt that shows up six months later, how to spot code written by a machine, and whether to vibecode your own tools instead of buying them.