Vibe coding: the upside and the risks

What exactly is vibe coding, and how is it different from AI-assisted coding?

The term spread in 2025 and, like any new term, everybody has their own meaning for it. The definition we use is the one the Stack Overflow developer survey put in its questionnaire, citing Wikipedia: generating software from LLM prompts.

But the sentence that separates this from ordinary use is not in the definition; it is in the behaviour. The real line is this: do you read and understand the generated code or not. Someone who reads the code, critiques it and writes its tests is coding with AI, and their lesson is coding with AI. Someone who only looks at what the run produced and writes the next prompt from that is vibe coding.

So this is a spectrum, not two camps. One person can vibe code a prototype in the morning and rewrite that same code line by line in the afternoon, and both can be right. What is wrong is not knowing which mode you are in.

And one thing that gets lost in the arguments: vibe coding is not a new invention in how people work. Copying code off a forum without reading it was exactly this, and it has twenty years of history. What changed is scale. Then you copied twenty lines; now you receive two thousand, and nobody reads those two thousand either.

How many developers actually do this?

The Persian and English internet are both full of the claim that vibe coding is the industry new way of working. The number says otherwise.

The 2025 Stack Overflow developer survey asked outright whether vibe coding is part of your professional development work, using the definition above. Of the 26,564 people who answered, 72.2 percent said no, and another 5.4 percent said emphatically no. On the positive side, 11.9 percent said yes, 2.8 percent said somewhat, and 0.4 percent said emphatically yes. A further 2.1 percent said they had tried it and 1.2 percent were not sure.

Two conclusions come out of that number, and both matter. First, within the same population where 84 percent use AI tools, about fifteen percent call what they do in professional work vibe coding. Which means widespread AI use and vibe coding are not the same thing, and people who treat them as one, whether in defining it or attacking it, are talking about two different things.

Second, do not read the number for more than it is. This is what people say about themselves, not a measurement of their behaviour, and the sample is self-selected. More importantly, the question was about professional work. Somebody who builds a small app from prompts at the weekend probably ticked "no" in this same survey, and that population is in fact growing.

Where does it genuinely pay off?

Criticising this way of working is easy and most writing does exactly that. But there are three places where vibe coding is not merely acceptable, it is the right choice.

A prototype that is going to be thrown away. When you want to find out whether an idea is worth anything at all, the only thing that matters is how fast you reach an answer you can touch. The quality of code that gets deleted tomorrow is a cost with no reason to pay it. The real condition here is a decision, not a technique: decide from the start that this code will be thrown away, and hold to that decision. A prototype that goes to production is the worst code in the project, and we have all seen every bit of that.

An internal tool for yourself. A script that runs once a month and only you run. A script that renames ten thousand files. A small page that shows one number. These have no users, no attacker, and if they break only your own time is lost. Worrying about code quality here is worrying about the wrong thing.

Learning, with one condition. Seeing how an idea works before you know how to write it builds motivation, and motivation is not a small thing in learning. The condition is that you go back afterwards and write the same thing yourself. Without that second step, vibe coding does for learning what watching a swimming video does for swimming.

And an advantage specific to Iran that is rarely stated: access. Somebody sitting in a small town with no route to a technical team can now take an idea far enough to show it to people. That is not a small thing, and no criticism of this method should ignore it.

Where does the cost show up?

None of this method costs are visible on day one, and that is what makes it dangerous. We talk here about mechanisms only, not about scary stories with no source.

Security, and one example most people get backwards. The common assumption is that danger means a key in client-side code. Now read Google own guidance page about Firebase API keys: it says Firebase keys, unlike typical API keys, are not used to control access to backend resources and are fine to include in code or checked-in config files; what actually protects the data is Security Rules. Which means a vibe-coded app can have a perfectly harmless key and a database open to everybody, because the rules were never written and no key scanner reports a thing. And two lines higher, the same page says the exact opposite about the Gemini API key: that one must never be in your code. Two keys in one app, two opposite rules, and the only way to know which is which is to read the documentation. A model writes code that works, and that is not the same as safe.

Maintenance. Code you have not read puts you, when it breaks, in a position no tool can rescue: you do not know where to look, because you do not know what is where. The usual route is to call the same model and say fix it, and that works while the problem is small. Once the program grows past what fits in one conversation, that route closes too.

Licence ambiguity. These models were trained on public code and can produce a fragment resembling existing code under a restrictive licence. Someone who does not read the code has, in practice, no way to notice. That GitHub added a setting to block suggestions matching public code shows the vendor itself treats the concern as real.

And a cost you pay yourself. In the same survey, 20 percent of respondents said they have become less confident in their own problem solving. We unpack the mechanism in coding with AI: learning comes from being stuck, and a tool that removes being stuck has removed the thing that was teaching you.

Our position: vibe code the draft, engineer the product

Arguing whether vibe coding is good or bad is a fruitless argument, because the answer depends on something neither side states: what is this code going to be holding.

Our practical rule is a question rather than a principle: if this program did entirely the wrong thing tomorrow, what would be lost? If the answer is "nothing, I would run it again", vibe code it and do not waste your time. If the answer includes somebody money, somebody data or somebody reputation, that code has to be read; whether by you or by whoever you are paying.

The practical line we hold is three things. Wherever there is user data, the code gets read, no exceptions. Wherever there is money, the same. Wherever something is meant to live longer than a season, the same, because after three months nobody remembers what they said in the prompt.

On the other side, for getting an answer about an idea, for a tool only you run, and for seeing what something would look like, this method is the fastest thing available to you, and refusing to use it is no virtue.

One last point for anybody handing work to a freelancer or an agency: asking "who read this code" is not a rude question, and it is not hard to answer. If you get no answer, that is the answer. How we do our own work here is written up in app and software development.