In short
Vibe coding is writing software by describing intent in natural language and letting an AI assistant produce the code, with the developer steering and reviewing rather than typing. It works well for prototypes, exploration, unfamiliar APIs, and throwaway tooling. It works badly for systems other people depend on, because code arrives without the understanding that normally comes from writing it — which is a problem at review time, not at build time.
What it actually is
Vibe coding is building software by describing what you want in natural language and letting an AI assistant write the code, with you steering, reviewing, and correcting rather than typing most of it yourself.
The name is glib, and it has attracted both more enthusiasm and more contempt than it deserves. The practice is real and, used in the right places, genuinely productive.
Where it genuinely works
Prototypes and exploration. When the goal is to find out whether an idea is worth pursuing, the code is a means to an answer. Getting to a runnable version in an hour instead of a day is a real gain, and the code being disposable is a feature.
Unfamiliar territory. A library you have never used, an API with sprawling documentation, a language you touch twice a year. The assistant is faster than reading the docs and usually right about the shape of the thing — and you are still reviewing against a runtime that will tell you if it is wrong.
Throwaway tooling. Scripts, one-off migrations, data munging, internal utilities used by three people. The cost of a bug is low, the cost of the time is not.
Boilerplate. The fourth endpoint that resembles the first three. There was never any craft in typing it.
In all four, the common factor is that you can tell quickly whether it worked, and being wrong is cheap.
Where it goes wrong
The failure is rarely that the code does not run. Generated code usually runs. The failure is subtler and shows up later.
You get code without the understanding. Writing something forces you to hold its structure in your head. Reading approved output does not. Six weeks on, when it breaks at 2am, the person on call has never really understood this code — and neither has anyone else.
The bugs are plausible. Human bugs tend to be obviously wrong. Generated bugs tend to be reasonable but incorrect: the right shape, subtly wrong on an edge case, handling the happy path and quietly mishandling the empty one. They survive casual review precisely because they look sensible.
Security and correctness get skipped. Models produce code that satisfies the request. They do not reliably ask what happens when the input is hostile, the row is missing, or the same request arrives twice. Authentication, permissions, payments, and migrations are exactly where this matters and exactly where it is least visible.
Complexity accumulates invisibly. Each prompt produces a locally reasonable change. Nobody is holding the whole design. After a few weeks you have a system with no coherent architecture, which is the technical debt problem arriving faster than usual.
The discipline that makes it safe
We use these tools daily. The difference between useful and dangerous is entirely process.
Read the diff, never the summary. The assistant's description of its change is generated text about the change, not evidence of it. The diff is the fact. This is the single most important habit.
Write a test that would fail if the change were wrong — and confirm it passes for the right reason. A green suite proves the tests pass, not that the change is correct.
Keep changes small enough to actually review. A 40-line diff gets read. An 800-line diff gets skimmed and approved. The tool makes large diffs cheap to produce and no cheaper to review, which is the trap.
Hard-line the sensitive paths. Authentication, permissions, payments, migrations, deletion. Generated or not, these get read line by line by someone who understands the consequences. No exceptions.
Own the architecture yourself. Use the assistant for implementation inside a structure you decided. If you outsource the structure too, nobody is holding the design.
The honest position
Vibe coding is a legitimate technique with a specific range. Inside that range — prototypes, exploration, tooling, boilerplate — it is straightforwardly good and we would not give it up.
Outside it, on systems that people depend on and that someone has to maintain, the productivity is partly borrowed against future understanding. That debt is real and it comes due during an incident, when the cost of not understanding your own system is at its highest.
The teams doing this well are not the ones prompting best. They are the ones who kept their review standards exactly where they were before.
If you are introducing these tools to a team and want the guardrails right first, book a call.
Common questions
What is vibe coding?
Writing software by describing intent in natural language and letting an AI assistant produce the code, with the developer steering and reviewing rather than typing most of it. The developer's role shifts from authoring to specifying and verifying.
Is vibe coding safe for production code?
It depends entirely on review discipline, not on the tool. It is safe when diffs are read rather than summaries, when changes stay small enough to review properly, and when anything touching authentication, permissions, payments, or migrations is read line by line. It is unsafe when generated code is approved because it looks reasonable.
What are the risks of vibe coding?
Four main ones: you end up with code nobody understands, because reading approved output does not build the mental model that writing it does; generated bugs are plausible rather than obviously wrong, so they survive casual review; security and edge-case handling get skipped because models satisfy the request rather than interrogating it; and architectural complexity accumulates with nobody holding the overall design.
When should you not use AI to write code?
When a mistake is expensive and hard to detect — authentication, permissions, payments, data migrations, and deletion paths. Also when the resulting code will be maintained long-term by people who were not involved, since the understanding gap becomes an operational problem during incidents.
