There's a difference between AI assisted "vibe coding" and what I’ll call (for now) "craft coding."
This isn’t a movement or a manifesto. I’m not trying to coin a term or draw a line in the sand. I just want to articulate something I care about, now that AI-assisted coding is becoming so common.
The phrase “vibe coding” already is a "thing", if not well defined. It’s been tossed around to describe a casual, improvisational approach to programming with AI tools. Sometimes it’s playful and exploratory - which is fine in personal, low-stakes settings. But when vibe coding crosses into production software or educational tools without critical thought and human review, it can become actively harmful.
I’ve seen definitions of vibe coding that outright celebrate not reading the generated code. Or that dismiss the need to understand what the code does — as long as it runs. That’s where I draw a hard line. If you’re unwilling to engage with what you’re building, you’re not just missing the point — you’re potentially creating brittle, inscrutable systems that no one can maintain, not even you.
It’s the kind of anti-intellectual aversion to thinking for yourself that leads you to Vibe Code a CyberTruck of an app: an aggressive, self-satisfied, inexplicably pointy prison piss pan.
It plows along mindlessly — overconfidently smashed, shot at, and shattered on stage, problems waved off with “a little room for improvement” and “we’ll fix it in post”; then it’s pushed straight into production, barreling under “Full Self-Delusion” mode through crowds of innocent bystanders, slamming at full Boring speed into a tunnel painted on the face of a cliff, bursting into flames, and finally demanding a monthly subscription to extinguish itself.
Vibe Coded CyberApps are insecure thin-skinned auto-crashing cold-rolled steel magnets for hackers, bots, vandals, and graffiti artists.
It’s the kind of city planning where you paint a tunnel directly onto the side of a cliff, floor it like Wile E. Musk, and trust that the laws of physics — or software engineering — will graciously suspend themselves for you.
It's where you slap a “FREE TOLL” sign on a washed-out bridge and call it a feature, not a bug.
By contrast, what I’m calling “craft coding” is about intentionality, comprehension, and coherence. It’s about treating code as something more than a means to an end — something worth shaping with care. That doesn’t mean it’s always elegant or beautiful. Sometimes it’s messy. But even when it’s messy, it’s explainable. You can reason about it. You can teach with it. You can read it six months later and still understand why it’s there.
Craft coding doesn’t require you to be an expert. It requires you to care. It’s a mindset that values:
Understanding what your code does.
Naming things clearly.
Keeping code, comments, and documentation in sync.
Being able to explain a design decision — even if that decision is "this is temporary and kind of gross, but here’s why".
Leaving the campsite cleaner than you found it.
Craft coding has been around a long time before AI-assisted coding. I've been fortunate to read the code of and work with some great Craft Coders. But in order to learn from great Craft Coders, you've got to be willing and eager to read other people's code and documentation, not repelled and appalled by the notion.
But vibe coding has also been around since before the time of LLMs. Tools like Snap! (and before that, Logo) encouraged exploratory, playful, improvisational approaches to programming.
Kids learn a lot by poking around and building things with little upfront planning. That’s not a bad thing — in fact, it’s a great on-ramp to coding. Snap! supports a kind of vibe coding that’s deeply aligned with constructionist education: learning by making, reflecting, iterating.
The same vibe exists in educational simulations like Factorio, SimCity/Micropolis, and The Sims — call it vibe space industry, vibe city planning, vibe architecture, or vibe parenting. You drop some zones, throw up some walls, dig out a swimming pool, tweak a slider, pop out some babies, see what happens. It’s empowering and often inspiring.
But you don’t want to live in a city you vibe-mayored in SimCity, with a vibe-tunneled Boring Company loop, or ride a vibe-planned HyperLoop, or board a vibe-engineered rocket operating under “Full Self-Delusion” mode, held together with PowerPoint and optimism, headed for a Rapid Unscheduled Disassembly.
The road from vibe coding to craft coding is a natural one. You start by exploring. Then you get curious. You want to understand more. You want your code to be shareable, readable, fixable. You want to build things you’re proud of, and that others can build on.
This is especially relevant now because AI-assisted coding is amplifying both the good and the bad. Tools like Cursor and Copilot can accelerate comprehension, or they can accelerate incoherence. They can help you learn faster, or help you skip learning entirely. It depends on how you use them.
But used with intention, LLMs can support craft coding, as a "coherence engine" rather than a "chaos reactor". They can serve as a kind of coherence engine — helping you align code with documentation, keep multi-dialect implementations in sync, and build multi-resolution natural language explanations of your design. They’re not just code generators. They’re context managers, language translators, spaghetti groomers, diff explainers, OCD style critics, grammar police, relentless lint pickers, code and documentation searchers and summarizers, and conversation partners. And if you treat them that way — as tools to reinforce clarity and coherence — they can be an extraordinary asset.
So this isn’t about gatekeeping. I’m not saying vibe coders aren’t welcome. I’m saying: if you’re interested in the practice of craft coding — in learning, building, and maintaining systems that make sense — then you’ll probably want something more than vibes.
And if you’ve got a better name than “craft coding,” I’m all ears. But what matters isn’t the name. It’s the practice.