Vibe coding - describing what you want in plain language and letting a model write it - stopped being a novelty somewhere around the start of this year. I build client work this way daily. It is the single biggest change to how I work in a decade.
It also fails, consistently, in three places. Not randomly: the same three, over and over, across different projects and different tools. Knowing where they are is the difference between shipping in a third of the time and spending a week unpicking something that looked finished.
What vibe coding actually is
The term covers a spectrum. At one end it means autocomplete that happens to be very good. At the other it means describing a feature and accepting whatever comes back without reading it. The useful middle is specifying intent precisely, letting the model produce an implementation, and reviewing it the way you would review a capable junior developer.
That middle is where the productivity is. The far end is where the horror stories are, and the people telling both stories are often describing genuinely different practices under one name.
Break one: state you did not describe
Models are excellent at the code you asked for and blind to the code you did not mention. Ask for a form with validation and you will get a form with validation. What you often will not get is correct behaviour when the form is submitted twice, when the request fails halfway, or when the user navigates away mid-submit.
These are state transitions nobody wrote down. The model is not guessing wrong; it is not guessing at all, because nothing in the prompt implied those states exist. The fix is cheap once you know: enumerate the states before you ask. Loading, empty, error, partial, success, and whatever happens on a second submit.
I now write the state list first and the prompt second. It takes two minutes and removes most of the rework.
Break two: the second change to the same file
The first generated version of a file is usually coherent. The third is usually not. Each change is locally correct and globally inconsistent: two slightly different ways of handling the same error, a helper duplicated because the model did not notice the existing one, naming that drifts between revisions.
This is the failure that produces codebases nobody can maintain, and it is invisible if you only read diffs. The file passes review three times and is incoherent by the fourth.
The habit that fixes it is unglamorous: after every second or third change to a file, read the whole file, not the diff. If two things are now done two ways, consolidate before continuing. Models are very good at that consolidation when asked directly - they just will not do it unprompted.
Break three: anything that was never on screen
Generated code is strongest where the result is visible and weakest where it is not. A layout is right or obviously wrong. A caching strategy, an index on a database column, a race condition between two requests, a permission check - these look identical whether they are correct or not.
I caught one of these on this very site. A build that could not reach the CMS silently fell back to empty content and produced a complete, valid, entirely blank website. Every page built. Nothing errored. Deployed, it would have replaced a working site with nothing.
That is the shape of the third failure: plausible, silent, and only discoverable by asking what happens when something upstream is missing. Now the build throws instead.
What this means for how you work
None of this argues against vibe coding. I ship considerably faster than I did writing everything by hand, and the quality is higher in the places that are visible, because I spend the saved time on them.
It argues for moving your attention. The work is no longer typing the implementation. It is specifying state, keeping files coherent across revisions, and deliberately probing the parts that cannot be seen. That is still engineering. It is just engineering pointed somewhere new.
The developers getting hurt by this are the ones who moved their attention nowhere - who treated generation as a reason to review less rather than a reason to review differently.
Questions
Is vibe coding safe for production work?
Yes, with changed review habits. The risk is not that generated code is bad; it is that it fails silently in places nobody looked. Specify your state transitions up front, re-read whole files rather than diffs, and deliberately test what happens when an upstream dependency is missing.
Does AI-generated code have worse quality?
Not inherently. It is typically better than hand-written code in the visible layer and worse in the invisible one, because a model optimises for what the prompt described. Quality tracks how precisely the intent was specified and how the output was reviewed.
Which tools are best for vibe coding in 2026?
I use Claude, Cursor and Codex together: Claude for reasoning through structure and reviewing whole files, Cursor for in-editor changes with project context, Codex for well-specified isolated tasks. The specific tool matters far less than having a review habit that catches the three failure modes.