Vibecoding: writing software by conversation

The term is new; the practice less so. Vibecoding means writing software by describing the result you want in natural language and letting AI produce the code. You read it, say what is wrong, and repeat.

Why it works at all#

Code is easier for a machine than prose. It has strict syntax, an enormous body of public examples, and immediate feedback: it either runs or it does not. Models are trained on code more heavily than on almost anything else.

Where it genuinely works#

Prototypes. Testing an idea in two hours instead of two days. Here vibecoding is straightforwardly useful.

Boilerplate. Forms, tables, data transformation, scripts. The dull code nobody wants to write.

An unfamiliar language or framework. If you can program but not in this particular language, AI gets you moving far faster.

Tests. One of the most rewarding uses — writing tests is important and tedious.

Where it fails#

When you cannot read code. This is the heart of it. AI code always looks good. If you cannot judge whether it is correct, you do not know whether it is correct — the same problem as hallucination, except the consequences are executable.

Security. The model writes working code. Working does not mean secure. Authentication, permission checks, input validation — these are where the default answer is often incomplete.

Architecture. AI is good inside a file. It is much worse at how twenty files should talk to each other. The large structural decisions stay yours.

Technical debt. A fast result nobody reviewed becomes, three months later, code nobody dares touch.

What you still have to know#

Honestly: more, not less, than it first appears.

You need to be able to read code and understand what it does. You need to know what a good question looks like. You need to notice when an answer is plausible but wrong. And you need to be able to test.

Vibecoding does not turn a non-programmer into a programmer. It turns an average programmer into a faster one — and a beginner into somebody producing code they cannot evaluate.

Practical advice#

Use it freely for prototypes and boilerplate. Review all of it the way you would review a colleague's pull request. Write tests. And the closer the thing gets to real users and real data, the more human has to stay in the loop.