What is vibe coding and what are its risks?

What it means

The term describes generating code from natural-language description and accepting it largely on trust, judging by whether it appears to work rather than by reading it. Modern coding assistants make this fast enough that a working application can exist before anyone has read a line of it.

For a category of work this is straightforwardly good. Prototypes, internal tools, data scripts, spikes into an unfamiliar API — all are throwaway, and time spent deeply understanding throwaway code is wasted.

Where it breaks

Nobody can debug it. When a vibe-coded system fails in a way the model cannot fix from the error message, there is no fallback. The team's understanding of the system is the model's, and it does not persist between sessions.

The failure cases were never specified. Generated code satisfies the description it was given. Descriptions almost never enumerate malformed input, concurrent writes, partial failures, or the second code path that also needs the permission check. The result works on the happy path and is silently fragile everywhere else.

Security defaults are not defaults. Auth checks on one route and not another, secrets in the repository, input concatenated into queries, permissive CORS. Not because models are careless, but because the prompt asked for a working feature and got exactly that.

Change becomes frightening. The compounding cost. A codebase nobody understands is one nobody can confidently modify, so changes get made by asking the model again, and the system accumulates layers nobody has read.

The 2026 wave of vibe-coded launches made this shape familiar: fast to build, fine at launch, and progressively harder to operate as reality diverged from the demo.

The line most teams settle on

Understood code required: authentication and authorisation, payments, anything handling personal data, data migrations, anything a user's money or privacy depends on.

Speed wins: prototypes, internal tooling, analysis scripts, UI experiments, throwaway integrations.

The important part is writing the line down. Without one, prototypes ship — not through a decision, but because the prototype worked and the deadline arrived, which is how almost every one of these gets into production.

Using it well

Read the generated code for anything that will persist. Ask the model to explain its own choices, and treat an unconvincing explanation as a signal. Write tests you understand even when the implementation was generated — the tests are where your understanding lives. And keep the boundary visible in the repository, so that promoting something across it is a deliberate act rather than an accident of scheduling.