What is vibe coding, really?

The phrase "vibe coding" started showing up in tweets in 2025 to describe a particular way of building software, which is to say sketchily, by feel, leaning on an AI to fill in the parts you don't know. People mean it as a brag and as an insult in roughly equal measure. Both readings get something right.

The honest definition is this. Vibe coding is writing software with an AI doing most of the typing, where you specify what you want in plain language, accept the changes that look about right, and ship the result without fully understanding every line. It is the natural mode for the kind of work this site is about. It is also, in some hands, the way to ship a thing that quietly falls over the moment a real user touches it.

What it gets right

For a long time the rule was that you couldn't build something unless you understood every line of it. That rule was always more honored in the breach. Most developers building production software lean on libraries they didn't write, copy patterns from forum posts, and have spent years not knowing exactly how their own database is configured. The pretense that everyone reads every line is just that, a pretense.

Vibe coding takes that loose truth and pushes it further. If the goal is a personal site, a one-off script, a prototype to show your boss, you can get to a working version much faster by describing what you want, accepting most of what comes back, and steering. You'd be foolish not to.

What it gets wrong

Vibe coding has a failure mode, and it shows up the moment the stakes rise. A piece of software that's "fine, as far as I can tell" is exactly the kind of thing that's broken in a way you don't see. The AI is fast. The AI is also confident. Confidence is not correctness, especially when the project has any real users, holds any sensitive data, or processes any real money.

The people who do this well treat the AI like a fast junior. They watch every diff. They test the output against numbers they already know. They keep the project small enough that they can hold most of it in their head. They are not, in fact, vibe coding in the worst sense of the word. They are working in a new register, more delegated than before, but with the same care that made their work hold up before.

The version of it worth doing

There is a respectable version of vibe coding, and it goes like this. You pick a project small enough to fit in an afternoon. You describe it specifically. You let the AI do the typing. You read the diffs as they come back, not to verify every line, but to catch anything that surprises you. You test what the tool produced with values you already know the answer to. When something feels off, you say so, plainly, and let the AI fix it. When the work is good, you save a checkpoint and move on.

That is most of what shipping looks like now, even for serious developers, with the volume of typing turned down. It is fine to call that vibe coding. It is also fine to call it engineering. The label matters less than whether the result holds up the next time you open it.

Where the term will probably end up

Likely as shorthand for the casual end of a spectrum. On one end, a hobbyist throws a thing together in a Saturday and ships it for fun. On the other, a small team uses the same tools with deliberate care to build something a customer will pay for. The first one calls it vibes. The second one calls it work. The tools don't know the difference. You do.