Vibe coding: what it is genuinely good for, and where it breaks

Somebody describes an app in a paragraph, an agent writes it, and twenty minutes later there is a working thing on screen. That is vibe coding, and anyone who tells you it is not remarkable has not tried it recently.

The honest question is not whether it works. It is what happens next — because the code does not disappear when the demo ends. Somebody maintains it, somebody gets paged about it at 2am, and somebody has to change it eighteen months later when the requirements move.

What vibe coding actually is

The term describes a specific posture: you stay at the level of intent — "add a filter for archived items", "make this look like a settings page" — and you accept the generated code without reading every line. You steer by looking at the result, not the diff.

That posture is what makes it fast, and it is also the entire source of the risk. You are not reviewing; you are reacting.

Where it genuinely wins

We use it every week, deliberately, in four places:

• Prototypes and spikes. When the goal is to learn whether an idea feels right, code quality is irrelevant — the artefact is disposable by design. Vibe coding is close to unbeatable here.
• Throwaway internal tooling. A one-off script to reconcile two exports, a quick admin view nobody outside the team will ever touch.
• Unfamiliar territory. Working in a language or framework you touch twice a year, where the model knows the idioms better than you remember them.
• The blank page. Getting a rough first draft on screen so you have something to react to, then rewriting it properly.

Notice the pattern: in all four, either the code is genuinely disposable, or a human rewrites it before it ships.

The value of vibe coding is measured in how quickly you learn something — not in how much code you keep.

Where it breaks

Generated code is confident, plausible and syntactically perfect. That is precisely the problem: the failure modes are invisible at the surface.

The last 30% is the expensive part. The model gets you to something that mostly works with startling speed, then progress falls off a cliff. Auth edge cases, race conditions, error states, the one browser that does it differently — the boring, specific, contextual work is exactly where the confident-sounding suggestions stop being right.

Nobody understands the code. When you did not write it and did not read it, debugging it is archaeology. The cost you saved on Tuesday is repaid with interest the first time it breaks in production.

Security is not implicit. Models write what looks like working code, and working code is not the same as safe code. Unvalidated input, over-permissive queries, secrets in the wrong place, dependencies nobody vetted — none of it announces itself.

It has no memory of your architecture. It cannot know that your team decided against that pattern last quarter, or that the module it just duplicated already exists two folders over. Left unchecked, it produces a codebase that is locally sensible and globally incoherent.

Review becomes the bottleneck. This is the real economic shift. Writing code stopped being the constraint; understanding it is. A team that generates faster than it can review has not become more productive — it has just moved its queue.

The rule we work by

Vibe the prototype. Engineer the product. And be ruthless about which one you are doing, because the failure we see most often in the wild is not bad AI code — it is a prototype that quietly became the product because it worked well enough on the day.

When code is going to live, we put it through the same gates as anything else:

1. Specify before generating. A short, precise description of the behaviour and constraints beats a vague prompt and three rounds of correction.
2. Small diffs. A change you can hold in your head is a change you can review. Sprawling multi-file rewrites are where unreviewed code hides.
3. Types and tests are non-negotiable. They are the machine-checkable part of "does this actually do what we think". They also give the model a signal to correct against.
4. Somebody reads it. Every line that ships has been understood by a human who can explain it. This is the rule that makes all the others work.
5. Architecture stays human. Boundaries, data models and integration points are decided by people who know the whole system.

What this means for teams

Used well, AI has genuinely compressed our delivery timelines — most visibly on the first 70% of any build, and on the unglamorous work of migrations, tests and refactors. Used carelessly, it produces a large, plausible, unmaintainable codebase very quickly, which is a worse position than having written nothing.

The differentiator was never who could generate code fastest. It is who can tell the difference between code that works in a demo and code that will still be working, and still be changeable, in three years. That judgement is the job now.