Vibe Coding: What It Fixes, Where It Stops

I wrote a line in September that I meant as a celebration:

We’re living in a time where everything is possible just in few minutes.

It is true, and vibe coding is the sharpest example of it. You can describe an interface in a sentence and have it running before the coffee cools. That is not a demo any more — it is Tuesday.

But I have been building interfaces long enough to notice what the minutes buy you, and what they do not. They buy you the first eighty per cent, which was never the expensive part. The last twenty is still there, waiting, exactly where it always was.

So this is not an argument against vibe coding. The speed is real and worth having. It is an argument about where the speed stops, and what you have to own after it does.

What is vibe coding?

Vibe coding is describing what you want in plain language and letting an AI model write the implementation, then steering it by reaction rather than by specification. You say what it should do, look at what comes back, say what is wrong, and repeat. The loop is intent, generate, review, adjust, ship — and the review step is the one everyone skips when they are showing you how fast it is.

The term comes from Andrej Karpathy, who described it on 2 February 2025:

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

It stuck because it named something people were already doing quietly. Merriam-Webster listed it as slang and trending five weeks later; Collins made it Word of the Year for 2025. And by 2026 it had stopped being a novelty and become two separate practices that share one name:

• Prototyping. Low stakes, fast, disposable. The output is a decision, not a product. Vibe coding is excellent here and the risk is near zero.
• Shipping. Real users, real data, real consequences. Same tools, entirely different discipline, because now the thing has to survive contact with people.

Most of the argument about vibe coding is two people describing those two different activities and assuming they are talking about the same one.

What is vibe coding genuinely good at?

It collapses the distance between having an idea and seeing whether the idea is any good — which, for a designer, is the whole job. A mockup shows one state of one screen at one size. A running prototype shows you the thing.

Concretely, the places it earns its keep:

• Questions only motion can answer. Whether a transition feels fast or sloppy is not decidable in a static file. Three generated variants in ten minutes beats a week of arguing.
• The states you would not have drawn. Ask for a form and you get the empty, loading, error and success states for free. They are often wrong — but now they exist and can be corrected, instead of being discovered in QA.
• Throwaway scaffolding. The boring shell around the interesting part: routing, layout, a fake API. Work that was never where your judgement lived.
• Reading unfamiliar territory. A working example of a library you have never used teaches faster than its documentation.

And there is a real structural advantage for designers here, which the industry is slow to say out loud. Describing an interface precisely — spacing, hierarchy, states, behaviour under stress — is a design skill. It is the design skill. A model responds to that description far better than it responds to a vague engineering ticket. The people best equipped to direct these tools were trained to specify interfaces, not to write loops.

Vibe coding vs no-code vs AI-assisted coding

The three get used interchangeably and they are not the same thing — they differ in what you end up owning.

What is no-code?

No-code builds inside someone else's runtime: you assemble from provided blocks, and the platform owns the output. You get speed and a ceiling. When you need behaviour the platform did not anticipate, there is no lower level to drop into, and migrating off means rebuilding from zero.

What is AI-assisted coding?

AI-assisted coding is autocomplete with a longer memory: you are writing the software and the model accelerates the typing. You hold the architecture in your head and the model fills in the lines. The mental model is yours throughout.

What is vibe coding, then?

Vibe coding is the middle case, and the uncomfortable one: you own real code that you did not write and may not fully understand. The output is yours — a real repository, deployable anywhere, with no platform ceiling. But so is every defect in it, including the ones you never read.

That is the trade worth naming explicitly. No-code limits what you can build. AI-assisted coding limits how fast you can go. Vibe coding removes both limits and hands you the review problem instead — which is the one people discover last.

Where does vibe coding break?

It breaks at “almost right” — and that is not a hunch, it is the most common complaint developers report. Stack Overflow's 2025 developer survey asked tens of thousands of developers what frustrates them most about AI tools. The top answer, at 66%, was

AI solutions that are almost right, but not quite.

Sit with how specific that is. Not “wrong”. Wrong is cheap — wrong announces itself, fails loudly, gets fixed. Almost right is expensive, because it passes a glance. It compiles. It renders. It looks finished in a screenshot, and the defect is somewhere in the twenty per cent nobody inspected.

The same survey found 45.2% say debugging AI-generated code takes them longer than writing it would have, which is the bill for the earlier speed arriving later, under a different name.

And the trust numbers are bleaker than the adoption numbers suggest. 84% of respondents use or plan to use AI tools. Only 3.1% say they highly trust the accuracy of what comes out. Add every shade of distrust together and it outweighs every shade of trust — 45.7% against 32.7%.

That is a profession using something daily and believing it roughly half the time. Not because developers are precious, but because they are the ones who eventually read the twenty per cent.

What is actually in the last twenty per cent?

The last twenty per cent is everything that is invisible in a screenshot and unavoidable in use. It is not polish. Calling it polish is how it gets cut.

• Accessibility. Focus order, roles, contrast, keyboard traps, screen-reader labels. Generated markup is confidently wrong here more often than anywhere else, because plausible HTML and correct HTML look identical until someone tabs through it.
• The failure states. What happens when the request times out, the input is pasted with emoji, the list is empty, the name is four hundred characters long.
• Performance under real conditions. What a model writes is idiomatic, not fast. Nobody generated a bundle budget for you.
• Coherence across screens. Ten generated components are ten opinions about spacing. A system is one opinion, applied ten times.
• Whether it should exist. The cheapest thing to build is now the easiest thing to build badly. Speed makes the question of what deserves building more important, not less.

I have written about that last point from the other direction — in why most SaaS products don’t fit the market, the argument was that products rarely lose on features. They lose on the thousand frictions between a feature and a person. Generation makes features cheap. It does not touch the frictions.

Who does the judging when the code is free?

Someone has to know that the generated thing is wrong, and that recognition is now the scarce part of the work. A model will produce a modal that traps no focus, a colour pair that fails contrast, a form that loses what you typed on error — and it will produce all three in seconds, looking finished.

This is the same shift I described in what a product designer actually does in the age of agentic AI: UI execution is being commoditised and UX judgement is not. Vibe coding is that argument arriving as a workflow. The generation is free; the taste to reject the output is not.

It is also why the role I wrote about in What Is a Design Engineer? keeps growing. The person who can both direct the model and evaluate what it returns — in the medium the model is producing, which is code — is the person the loop needs. Not a designer who reviews screenshots. Not an engineer who was handed a picture. One person holding both ends.

The pattern generalises past software, which is why I keep coming back to it. In 68% of Searches Now End Without a Click the same thing happens to writing: anything that is only ever output gets commoditised, and what survives is what output cannot contain. Here, that is the judgement about which generated version is right.

What does this change if you are building alone?

It changes what a one-person team can credibly finish, which is the most underrated thing about this shift. A solo builder used to choose: design it well, or build it at all. The second now costs a fraction of what it did, so the choice mostly disappears.

I argued in The Only Way to Build a Business Without Owning Assets that leverage comes from positioning, skill and service rather than from owning the machine. Generation pushes that further in the same direction: the machine got cheaper again. What did not get cheaper is knowing which thing to point it at.

But there is a specific trap for solo builders here, and it is not technical. When shipping is fast, starting is fun, and the number of half-finished things goes up. I wrote a note about this in September:

The real test isn’t the launch. The real test is the daily sprint when the novelty fades, and you have to prove you can keep building.

That is the middle battle — and cheap generation makes it harder, not easier, because it lowers the cost of starting without lowering the cost of continuing. Ten projects at eighty per cent is not ten projects. It is zero.

How do you vibe code without shipping mediocrity?

You separate the two practices, and you review the generated twenty per cent as if a stranger wrote it — because one did. What that looks like in practice:

• Decide which mode you are in before you start. Prototype or product. If it is a prototype, do not let it graduate by accident; the code that was never meant to ship is exactly the code that ships.
• Describe behaviour, not appearance. “A search field that keeps the query on failure and announces the result count to a screen reader” gets you further than “a nice search bar”, because you are specifying the part it gets wrong.
• Ask for the states explicitly. Empty, loading, error, too-long, offline. If you do not name them you get the happy path and a quiet gap where the rest belongs.
• Read every line you keep. Not every line generated — every line kept. If you would not defend it in review, it is not yours yet.
• Test the keyboard before you test the mouse. It is the fastest way to find generated markup that only looks correct.
• Put the repeated decisions in a system. A token beats a remembered hex code, especially when the thing typing is not you.

That last one is not theoretical. rakibulism-ui is a code-first React design system I maintain: 43 components, design tokens defined in TypeScript, and 119 behaviour tests that gate every change. The tests are the part that matters in this context — a suite is how intent gets checked by something other than attention, and attention is finite and worst at eleven at night.

Should designers learn to code now that AI writes it?

Yes — and the bar moved from “can you produce it” to “can you tell whether it is right”, which is a lower bar to start and a higher one to finish. You no longer need to memorise syntax to begin. You do need to be able to read.

The trap is preparing instead of starting. I shared a line from Dan Koe in September that says it better than I would:

You don’t need a PhD in a topic before you can start doing it. You don’t need to watch 10 YouTube videos, 20 podcasts, and read 5 books before you start.

Koe's point is that most people should start learning only after they have started doing the thing. With these tools that stopped being encouragement and became literally true: the fastest way to learn what generated code gets wrong is to ship something small and watch which part breaks.

Start with one interface you already designed. Have the model build it. Then find every state you did not draw, and fix those yourself. The gap between the two is your curriculum, and it is specific to you.

The key insight

Here is what I think is actually happening, under the demos.

Vibe coding did not remove the work. It moved the work to the end, where it is less visible and easier to skip. The eighty per cent that used to take a week now takes an afternoon, and the twenty per cent that decides whether the thing is good takes exactly as long as it always did — except now it arrives after everyone has already seen a version that looked finished.

That is a harder discipline than the old one. When the first draft took a week, nobody mistook it for done. When it takes four minutes, everybody does.

Which is why the people who will do well with these tools are not the fastest. They are the ones who can look at something plausible and say: this is almost right. I have written before about building where nobody is watching — the four months on a desk joint nobody asked about. The last twenty per cent is that, compressed into an afternoon, and just as unwitnessed.

Everything is possible in a few minutes now. That was always the easy part.

What takes longer is caring whether it is any good.