What is vibe coding? A working definition, and where it breaks

Andrej Karpathy coined "vibe coding" in February 2025, half as a joke about his own weekend projects. You describe what you want, the model writes it, you don't really read the code, and when something breaks you paste the error back in. His phrase: give in to the vibes.

A year and a half later, a big share of the new apps we see were built exactly this way. Some of them have paying users. The joke became an industry, so it's worth being clear about what the word actually means.

A definition that holds up

Vibe coding is building software where you talk instead of type, and where the only review that happens is you looking at the running app. No second engineer. No design doc. If the app does the thing, you move on.

Skill level has nothing to do with it, by the way. Plenty of senior engineers work like this most of the day now. What separates them from a first-timer isn't better prompting, it's what they check afterwards.

The skeptics were wrong about most of it

Let's be fair to the vibes first, because a lot of the sneering from 2025 aged badly.

The feedback loop really is minutes instead of days. You see a working screen before you'd have finished writing the ticket for it. Boilerplate is just gone: auth flows, CRUD, form validation, the assistant has written each of them ten thousand times and it shows. And one person can hold a whole product in their head, because there's no handoff where "what I meant" quietly turns into "what got built."

For prototypes, internal tools, and the first version of nearly everything, this is simply how you build now. We build this way too.

The part that actually breaks

Every horror story we've heard about a vibe-coded app in production has the same shape, and it's never "the code was bad." Line by line, assistant-written code is usually fine. Often it's cleaner than what a rushed human writes.

What breaks is the layer nobody looked at: how the pieces fit together. A system isn't its files, it's the connections between them. Which service calls which. Where data crosses a trust boundary. What everything quietly depends on. When an assistant builds an app in an afternoon, that shape gets decided across a hundred small autocompletions, and nobody ever sees it whole.

So you get a very specific family of problems, the kind that never show up in a demo: the endpoint that was never behind the auth check, the cache the whole app secretly depends on, the loop that's fine with a hundred rows and fatal with a hundred thousand. There's more on those failure modes if you want the gory details.

"Stop vibe coding" is not the answer

Nobody is going back to writing CRUD by hand. That would be silly.

The actual fix is smaller: put back the one review the loop skips, and look at the shape of the system before production does. Architecture diagrams used to be the tool for that, and they died because keeping them current by hand was miserable. But the assistant that built your app can draw it now. That's the whole idea behind Arketo: connect your assistant over MCP, it maps what it built onto a canvas, and the invisible layer stops being invisible. There's a live demo if you want to poke at one, no signup.

Vibe coding is a real shift, not a fad. It just shipped with a blind spot, and the blind spot is fixable.