Learn · 5 of 7
Vibe coding, honestly
Building by describing and steering, and the part of it that genuinely goes wrong.
The term was coined in early 2025 for something that had already become common: describing the software you want, running what comes back, and steering by result rather than by reading every line.
It works. It is also the thing most likely to get someone into trouble, and both halves deserve saying.
Why it works so well at the start
The first eighty per cent of a project is mostly things that have been built ten thousand times before: a form, a table, an auth flow, a layout. A model has seen all of it and will produce something that runs in minutes.
For someone who could not otherwise have built it at all, that is transformative, and no amount of caution should obscure it.
Where it goes wrong
Not where people expect. Code that does not run is the good failure — it is obvious in seconds and you fix it or ask again.
The dangerous output is code that runs, looks right, and is wrong in a way nobody reads carefully enough to catch: a form that does not validate what it claims to, a permission check that passes when it should not, a calculation that is correct on the three cases you tried. The model is confident either way, because confidence is not connected to correctness.
The craft is knowing what you still have to understand
You do not have to read every line. You do have to decide, deliberately and in advance, which parts you are still obliged to understand — and for most projects that list is short and predictable: anything touching money, anything touching other people’s data, anything that decides who is allowed to do what, and anything that is hard to reverse.
For everything else, steering by result is fine.
Two habits that cost nothing
Ask the model to explain what it wrote before you accept it; the explanation surfaces the assumptions. And review the diff with a second pass — it costs about a cent and catches the boring half of what a human reviewer would.