People have started using “vibe coding” the way people use “indie hacker” when they mean unserious, or “creator” when they mean unemployed. It is supposed to sound dismissive: you are not engineering, you are just vibing; you are not programming, you are just prompting; you are not building, you are just messing around with a chatbot until something barely works.

That criticism lands on something real.

Karpathy’s original description of vibe coding was reckless on purpose: give in to the vibes, stop caring about the code, keep pasting errors back in, and let the code outrun your comprehension. Simon Willison has been right to push back on people who stretch that definition until it means every form of AI-assisted programming. If you review, test, and understand the code, that is not vibe coding in the strict sense. That is just using better tools.

For a while, I hated the term too. I preferred “AI-assisted coding” because it sounded more honest, more serious, and less associated with people shipping things they clearly did not understand. I still think that distinction matters.

But I have softened a lot.

Heck, vibe coding is cool.

And I think it is okay to be associated with it, as long as what you mean is not “I have outsourced all responsibility,” but “I am using a more fluid, conversational, intuitive way to build.”

But that is exactly why the insult has become more interesting than the literal definition. People are not only reacting to Karpathy’s joke. They are reacting to a deeper shift they do not like: software is becoming more conversational, more intuitive, more playful, more accessible, and less guarded by syntax priests.

That is what really bothers them.

The Word “Vibe” Is Doing Real Work

The etymology is more revealing than people think.

Merriam-Webster defines “vibe” as a distinctive feeling or quality capable of being sensed. Etymonline traces it through 1960s slang as an abbreviated form of “vibration” in the sense of an “instinctive feeling.” That matters. “Vibe” does not have to mean randomness. It can mean felt direction, atmosphere, taste, intuition before formal explanation.

Programming has always had that element.

Long before AI, good developers were constantly moving between rigor and feel. They read a system and sense where the design is wrong. They build a tiny prototype because the idea feels alive. They follow curiosity before they can justify it to a committee. They refactor not because a ticket demanded it, but because the code’s texture feels wrong.

We just did not call that vibe coding. We called it hacking, tinkering, scratching an itch, following taste, building a toy, or shipping a prototype.

Same instinct. New interface.

Before The Phrase, Developers Were Already Doing A Version Of This

If we use Karpathy’s literal February 2, 2025 definition, Linus Torvalds was obviously not vibe coding Linux in 1991. There were no LLMs, no “Accept All,” and no one should be silly about that.

But if we widen the lens and ask what people are really dismissing when they sneer at vibe coding, then Linus is absolutely in the family tree.

In the famous 1991 note that announced Linux, he called it “just a hobby” and asked for feedback from people bothered by the same limitations in Minix. Kernel.org still describes Linux as Unix written from scratch by Linus Torvalds with help from a loosely knit team of hackers across the Net. And Greg Kroah-Hartman’s Linux Symposium keynote notes describe Linus’s design philosophy in plainer terms: the kernel evolves over time based on “the need at the moment for it.”

That is an older, more serious version of the same spirit. Not sloppiness. Not unseriousness. Just movement guided by need, taste, curiosity, and iteration instead of ceremony.

It also rhymes almost perfectly with something I wrote years ago in Write The Code You Need Today. Great builders rarely begin with a giant master plan. They begin with a problem close enough to annoy them, solve the part that matters now, and let the work evolve under real pressure.

Git tells the same story. The official Git history says Linus built Git in 2005 after the BitKeeper situation collapsed, and that the goals were plain: speed, simple design, strong support for non-linear development, fully distributed collaboration, and the ability to handle a project as large as Linux efficiently.

That list is revealing. It does not read like a white paper. It reads like a good engineer saying, “I need this thing to feel fast, stay simple, and fit the way I actually work.” That is not anti-engineering. That is engineering with taste.

My reading here, and this is an inference from those sources, is that the older lineage people are accidentally mocking with “vibe coding” is often the lineage that creates the best tools: tools born from lived irritation and obsessive personal standards, not theoretical completeness.

Rails belongs in this conversation too. Rails says plainly that 37signals built it for Basecamp. Jason Fried said it even more clearly in 2005: Rails was extracted from Basecamp, and when they built Basecamp they did not know they were building Rails at the same time.

That is another clue. Some of the best software is not imagined in the abstract. It is extracted from use. It begins as, “I want this to exist,” and only later becomes, “other people probably want this too.”

That is why I find it hard to despise vibe coding as a category.

The history of software is full of people building from a felt need first and a polished theory second.

What AI Actually Changed

AI did not invent building by feel. AI changed who gets to do it and how fast they can do it.

Merriam-Webster’s definition of vibe coding is narrow enough: using AI to generate code. Fine. But the broader shift is what matters.

AP’s reporting on the coding-assistant market captures it well through Anthropic’s Cat Wu: the work moves away from the “nitty-gritty syntax” and toward communicating a higher-level goal. Replit is obviously selling here, so take this with the appropriate grain of salt, but they are still naming something real when they say vibe coding is democratizing app creation and opening it to people regardless of technical background. They say it even more bluntly here: software creation is becoming accessible to everyone through natural language.

I think that is mostly good. Very good, actually. Not because every person with an app idea is suddenly a great engineer. Not because syntax does not matter anymore. Not because quality, security, or taste stopped mattering. It is good because more people can now close the distance between “I wish this existed” and “I made a first version.”

That is a profound shift.

And it is one I do not want reversed just because some programmers feel their mystique slipping away.

A lot of the resistance here is not really about software quality. It is about social status. When code was harder to produce, developers could use syntax scarcity as a moat. AI-assisted coding weakens that moat. Now a founder, designer, teacher, operations person, or curious teenager can build a weird useful thing over a weekend.

That should excite us more than it scares us.

If you believe, as I do, that Agency Is What You Need Now, then this should be obvious. Lowering the cost of action is good. Shortening the path from thought to prototype is good. Making more people capable of testing their ideas in software is good.

The world does not get worse because more people can build. It gets noisier, yes. It also gets richer.

Why Joy Matters More Than People Admit

This is the deeper point. A lot of great work begins in excitement long before it becomes discipline.

Paul Graham writes in How to Do Great Work that great work usually starts from deep interest, excited curiosity, and what he calls preserving “excitingness.” A review in PMC on intrinsic motivation and creativity points in the same direction: intrinsic motivation is a strong predictor of creative and innovative performance, in part because people persist longer and process more information when the work is inherently interesting to them.

That maps almost embarrassingly well to how many good side projects start. You do not begin because the TAM is enormous. You do not begin because McKinsey would approve. You begin because the idea keeps tapping you on the shoulder, because the tool should exist, because the current tool annoys you, because it would be fun to make, because the problem is yours.

That is not unserious. That is often the beginning of serious work.

A lot of people forget that craft is not only discipline. It is attraction. You are drawn toward something, and then discipline helps you stay with it long enough to make it good.

This is why I am not threatened by AI-assisted coding making software more playful. Play is not the enemy of craft. Play is often the doorway into craft.

The kid messing around with mods, bots, scripts, cloned apps, or half-baked tools might still become the engineer with real taste later. Accessibility does not kill excellence. It expands the funnel.

But Yes, Vibe Coding Can Absolutely Be Sloppy

This is where the critics are right, and I do not want to dodge it.

But we should be honest about something else too: bad code did not arrive with AI. People have been writing spaghetti, cargo-cult abstractions, unreadable helpers, broken UI state, and rushed production nonsense for decades. Slop is older than vibe coding. AI did not create the possibility of horrible software. It changed the speed and ease with which people can produce it.

That is true of almost every efficiency tool. A faster compiler, a better framework, a code generator, a scaffolding CLI, a low-code builder, even a good copy-paste habit can all help you do the right thing faster or the wrong thing faster. The tool does not remove responsibility. It multiplies the quality of the judgment behind it.

If by vibe coding you mean what Karpathy described at the strictest end, blindly accepting code you do not understand, shipping without review, and letting the codebase outrun your comprehension, then yes, that is dangerous. Simon Willison has been excellent on this too: for experiments and low-stakes prototypes, go wild; for production systems you have to maintain, accountability does not disappear.

And this is where Good Enough Is the Enemy of Great matters. AI makes it easier than ever to get something that kind of works. That is a gift and a trap. If you stop at “it runs” and never develop taste, you will create junk faster than ever.

This is also why I have become increasingly obsessed with teaching the parts AI still does not hand you by default. If your UI works but falls apart on refresh, navigation, or real user behavior, that is exactly the gap Durable UI is meant to close.

If it functions but still looks like a school project, that is the gap Beautiful UI is meant to close. Durable UI is about where state lives and whether the product survives real use. Beautiful UI is about taste, hierarchy, spacing, color, and whether the thing looks like it belongs in a serious product. That is the helpful framing I keep coming back to now: AI gets you to “it runs” faster, but craft is still what takes it from demo-grade to product-grade.

So the right position is not blind celebration. It is not blind contempt either. It is this: use AI to get to the interesting parts faster, use vibe to begin, use judgment to continue, and use testing, taste, and responsibility to finish.

If you reviewed it, tested it, and understood it, great. If AI helped you get there, even better. That is not cheating. That is leverage.

The Builders Will Benefit Most

The people who win from this shift will not be the ones arguing online about whether vibe coding is respectable. They will be the ones using the new affordances to build more, learn faster, and chase their curiosities harder.

I have been doing exactly that myself, and if someone wants to be uncharitable they can say I vibe coded half the things I am proudest of lately. Fine. The tools are still real.

Slipway is a good example. I had been wanting a deployment platform that actually understood Sails and The Boring JavaScript Stack for a long time, but the scope used to feel annoyingly big: deployment orchestration, health checks, database provisioning, blue-green releases, observability, a web dashboard, a CLI, the whole thing. AI-assisted coding helped me move fast enough to actually build it. Call that vibe coding if you want. The result is still a real self-hosted deployment platform, purpose-built for my stack, born from personal frustration and sharpened by use.

Pellicule is another. It is a Vue-native engine for rendering videos programmatically, and I do not think it would exist if I were only optimizing for market spreadsheets. It exists because the idea was too interesting to leave alone: what if video creation for Vue developers felt as natural as writing components, and what if the tool simply respected the build config you already have? That is playful obsession again. Not less serious because it started from curiosity. More serious because curiosity kept it alive.

Git Vibe belongs here too. I did not build it because the world needed one more Git wrapper. I built it because I was irritated by the cost of long-lived branch ceremony in an agent-heavy workflow and wanted a calmer way to work: one long-lived main, short-lived feat/* branches, task-isolated worktrees, less branch tax, more movement. That is vibe in the best sense of the word: a felt problem, a strong opinion, and a tool extracted from how I actually want to work.

And now there is Sounding, which is my attempt to give Sails and The Boring JavaScript Stack a proper testing home. The whole thesis came from the same place. I was tired of a fragmented testing story. I wanted helpers, endpoints, Inertia responses, auth, email, and browser flows to feel like one coherent testing world instead of a stitched-together pile of unrelated tools. That is not anti-engineering. That is what engineering often looks like when it begins in irritation and moves toward elegance.

That is why this conversation connects so naturally to Shut Up and Act. The old pattern was to announce the app idea and never ship it. The new opportunity is to actually build the ugly first version tonight.

It also connects to My Open Source Journey, because most meaningful software careers are not born from theory. They are born from curiosity, repeated reps, and a willingness to make useful things before anyone is watching.

People say vibe coding like it is an insult because they hear looseness in the word vibe. I hear something else too: permission, lower ceremony, faster feedback, and more people getting a turn.

And yes, some of what gets built will be sloppy. Some of it will be disposable. Some of it should never touch production.

But some of it will become the next weirdly beloved tool, the next framework extracted from a real app, the next open source project that began as a hobby, the next thing its maker could not stop building because it was too interesting to leave alone.

That is not an insult. That is how a lot of software history already worked.

AI did not invent that spirit. It just made the doorway wider.