Vibe Coding, Honestly: Where It Works and Where It Bites

Vibe coding, in the sense the phrase has settled into, means describing the outcome you want and accepting the generated implementation without reading it line by line. It is easy to be snobbish about and easy to oversell, and both reactions miss that the approach has a fairly clear domain of competence.

Where it genuinely works: throwaway and exploratory code. A script to reshape a CSV, a quick visualisation, a prototype to find out whether an idea feels right, a one-off migration you will run once and delete. In these cases the feedback is immediate, the blast radius is a file on your machine, and the cost of a subtle flaw is that you notice something looks wrong and try again. It also works well in unfamiliar territory, where generated code is a faster way to learn a library's shape than reading its documentation front to back, provided you treat it as a sketch.

Where it bites is anything that persists. Code you did not read is code nobody understands, and the bill arrives later: when it breaks at an inconvenient time, when it needs to change, or when a security property you never checked turns out not to hold. The characteristic failure is not gibberish, since modern models produce plausible, idiomatic-looking code. It is plausible code with a wrong assumption inside it, which is much harder to spot than obvious nonsense and which tests written by the same process tend to confirm rather than catch.

The specific hazards worth naming. Authentication, access control and anything touching money or personal data, where a confident-looking implementation can be subtly permissive. Concurrency and caching, where the error only appears under load. Input handling, where validation is often present but incomplete. Dependencies, where a model may reach for an abandoned package, or occasionally a name that does not exist and that an opportunist has since registered. And schema or migration code, where a mistake is not a bug but a data loss event.

A workable discipline looks like this. Decide up front whether the code is disposable or load-bearing, and be honest, because the common failure is disposable code quietly becoming load-bearing. For anything load-bearing, read the diff properly, as you would a colleague's pull request, and keep the changes small enough that reading is feasible. Write or at least verify the tests yourself for the behaviour you actually care about. Run the dependency list past your own judgement. And keep the generated work inside the same review, CI and rollback machinery as everything else, rather than letting it bypass the process because it arrived differently.

The productivity gain is real and worth having. It comes from not typing boilerplate and from exploring faster, not from skipping comprehension. The moment code leaves your machine and other people depend on it, somebody has to understand it, and the only candidate is you.