What Is Vibe Coding?
I hate the term “vibe coding” but it’s what it’s being called, so here we are. I’ve been writing code professionally for around twenty years, and I have watched a lot of methodologies come and go. This one showed up wearing a stupid name and somehow turned out to be the most fun I’ve had building software in a decade.
So let me give you the honest version. Not the breathless LinkedIn version where AI writes your whole company while you sip coffee, and not the doomer version where it’s all slop and the industry is ending. The actual version, from someone who has built a pile of real projects this way, shipped some of them, abandoned more of them, and burned out once badly enough to write about it.
This is the guide I wish someone had handed me before I had fifteen half-finished repos and a commit chart that needed explaining.
Contents
What Vibe Coding Actually Is (And What It Isn’t)
Vibe coding started as AI-assisted development with zero ceremony. You have an idea, you fire up an AI coding assistant (Claude Code, Cursor, Qoder, whatever is the new hotness this week), and you see what happens. No detailed specs up front. No project management theater. Just “hey, build me a thing that does X,” and then you iterate until it works or you get distracted building something else.
That’s the origin. The term comes from the vibe. You’re not architecting, you’re feeling your way forward, one prompt at a time, trusting the tool to handle the parts you’d normally grind through by hand.
Here’s what it is not: it is not the AI writing all your code while you watch. That’s the fantasy people sell and the strawman people attack, and neither group has done much of it. Real vibe coding is conversational programming. You treat the AI like a pair programmer who types fast and never gets tired, instead of treating it like a code-completion tool that finishes your lines. The skill isn’t typing. The skill is knowing what to ask for, knowing when the answer is wrong, and knowing when to stop.
People call this a lot of things. AI pair programming, prompt-driven development, LLM-assisted coding. The ecosystem stretches from plain GitHub Copilot autocomplete on one end to fully autonomous agents that build entire features while you make dinner on the other. “Vibe coding” is the messy, intuition-first middle of that spectrum, where you’re driving but you’ve handed the AI the heavy lifting.
The one distinction worth burning into your brain early: there is a difference between a throwaway prototype and a real project, and vibe coding is fantastic at the first and dangerous at the second if you’re not careful. More on that disaster later.
How I Got Here: From Chaos to Something That Ships
I did not arrive at any of this on purpose. I started wanting to test Claude Desktop with some MCP servers. One little experiment. You know how that goes.
Six months later I had fifteen projects in various states of “done” (Obsidian plugins, an Electron writing app, command-line tools, a couple of things I genuinely can’t justify), and I’d accidentally figured out a way of working. I wrote that whole sprawl up in The Great Vibe Coding Experiment, which is the closest thing I have to a field journal of the chaos phase. If you want to see what building fifteen things in your spare time actually looks like, including the dumb detours, start there.
The first project I abandoned for a good reason: I just bolted random features onto an idea I’d thought about for maybe ten minutes. Pure chaos. No rails. It collapsed under its own incoherence, exactly like you’d expect. The second project I knew I needed some structure, and that’s where the evolution started. From “throw prompts at the wall” toward “have an actual loop.”
The loop I was trying to escape looked like this:
- Tell the AI to build the feature
- Test it, paste the errors back, tell it to fix them
- Do that again. And again. Copying and pasting stack traces like an animal
- Eventually ask the AI how to stop this from happening next time
And the thing I was evolving toward looked like this:
- Actor: an agent writes the code
- Auditor: an agent reviews the code, runs the tests, and either passes it or kicks it back to the Actor
- Process Improver: an agent looks at what caused the failure and updates the project’s docs, commands, and agent definitions so the same mistake doesn’t happen twice
That third role is the whole game. The first two just build and check. The third one makes the system get smarter over time instead of repeating the same failures forever. It only works because you can, within limits, trust the AI to do roughly what you told it to do, then build guardrails around the cases where it doesn’t.
That’s the arc: pure vibe-coding chaos to structured iteration. It did not happen because I’m disciplined. It happened because the chaos hurt enough to force it.
People want a tool recommendation. I’m going to give you something more useful: tool personalities. I run several of these simultaneously, usually one tool on one project while another grinds away on a second project, because that’s the only way to keep both hands busy when the AI takes a few minutes on a task. Too long to sit there, not long enough to do real work yourself.
Claude Desktop is a brilliant planner and a terrible coder. It’s the project manager who has fantastic ideas in the meeting and writes exactly zero lines afterward. Where it shines is architecture and, paired with MCP servers, “vibe coding” without a dedicated IDE at all. I documented that whole setup in Claude + MCP, Part 1 and the follow-up where I switched the project over to Scrapy in Part 2. The context resets are what kill it for sustained work.
Claude Code is my daily driver. It lives in the terminal, it reads your whole project, and it’s the one I reach for when I actually want to ship something. I built an Electron app from scratch with it, which is exactly the kind of “real app, not a demo” test that tells you whether a tool is any good. It’s not perfect and there are days I swear it’s lost a few IQ points, but it’s the one I trust with the most rope.
Kiro is the reliable workhorse. It’s almost too granular. It’ll turn a simple plugin into a dozen meticulous tasks and quietly add best-practice TypeScript interfaces I didn’t ask for. Annoying, and also better than what I’d have written.
Jules is Google’s free-tier coding assistant, and it earns its keep on small fixes. I let it update one of my Obsidian plugins and the honest verdict was right there in the title: can’t follow directions, but gets shit done.
Verdent is the one that genuinely surprised me. I expected the usual slow grind and instead it finished entire Obsidian plugins before I could get coffee, minutes, not hours. It broke my whole “work on a second project while the first one builds” routine, because there was no waiting.
The meta-point here matters more than any single tool: don’t marry one. They each have a temperament, they’re all moving targets, and the right move is to test new ones on real projects and learn their quirks. The hype cycle on these things is brutal and the only reliable signal is your own project sitting there either working or not.
The Workflow That Doesn’t Burn Everything Down
This is the part people actually need, because “have an idea and prompt the AI” is not a methodology, it’s a coin flip. Here’s the workflow I landed on after enough pain to earn it.
Prototype first, then throw it away. Vibe code a quick version to explore the idea. Let it be ugly. The point of the prototype is to have the 2am breakthrough where you finally understand what you’re actually building. Then, and this is the part everyone skips, you throw the prototype out. It was a thinking tool, not a foundation.
Break the real thing into discrete projects and phases. Once you know what you’re building, you don’t hand the AI the whole mountain. You break it into pieces small enough that a single agent run can finish one to a real MVP. Each feature becomes its own phase.
Write the plan in markdown the AI can read. Each phase gets a simple markdown TODO file, and the project gets a CLAUDE.md (or the equivalent for whatever tool you’re using) that explains the conventions, the architecture, and the things the AI keeps getting wrong. Commands and reusable skills live in plain markdown too. The whole coordination layer is just files an agent can read. No special framework required.
This is where it stops being vibes and starts being a system. I went deep on the project-management side of this when I tried to run my blog rebuild through Backlog.md. That experiment went sideways in entertaining ways but proved the underlying point: giving the AI a structured backlog to work against beats freestyle prompting every time. And after enough rounds of fighting both pure vibe coding and rigid spec-driven approaches, I landed on a middle path I wrote up in The Third Attempt, a living plan that you update as you go, instead of either winging it or freezing a spec in concrete on day one.
Trust the agent’s intelligence, within the rails. The mindset shift that makes all of this work is to stop micromanaging the AI’s every line and instead give it enough context to make good calls, then check its work hard. You’re not writing the code. You’re designing the system that writes the code, and reviewing the output like the senior engineer you are. The rails (the markdown plan, the tests, the auditor pass) are what let you extend trust without getting burned.
That’s the honest tutorial. It’s not glamorous. It’s a prototype you delete, some markdown files, and a loop. But it’s the difference between fifteen abandoned repos and something you can actually put in front of people.
Where It Falls Apart
Now the part the cheerleaders leave out.
“Done” does not mean “finished.” Vibe coding gets you to “it works on my machine and the happy path is green” terrifyingly fast. The last 20% (edge cases, error handling, the stuff that makes software actually shippable) is still slow, and the AI is much less helpful there because it requires understanding the real world your code lives in. The speed at the start lies to you about the total distance.
The context window is a hard ceiling. Every one of these tools forgets. Long sessions drift, the model loses the thread of your architecture, and you start getting confident, wrong answers. Managing context (keeping the CLAUDE.md tight, resetting deliberately, feeding the AI only what it needs) becomes a real skill, and it’s one nobody warns you about until you’ve shipped a bug because the model forgot a decision you made forty messages ago.
There is no universal QA for AI-generated code. You are the QA. The auditor agent helps, the tests help, but the buck stops with a human who actually understands the domain. If you don’t read the code, you don’t know what you shipped.
And it’ll wear you down if you let it. I burned out on vibe coding hard enough to walk away, come back, and rewrite everything. The infinite-possibility, build-anything-in-an-evening feeling is intoxicating right up until it’s exhausting, and the constant context-switching between projects and tools has a cost. There’s a particular kind of fatigue that comes from spending your evening being, as I put it once, a senior software engineer by title and an AI therapist by reality, coaxing, correcting, and managing a tool that’s brilliant and dumb in unpredictable proportions. That’s a real job, and it’s tiring.
None of this means don’t do it. It means go in with your eyes open about where the cliff is.
Vibe Coding vs Agentic Development
People use “vibe coding” and “agentic development” interchangeably and they shouldn’t, because the difference is the whole maturity curve.
Vibe coding is intuition-first. You start from a feeling and a prompt and you let structure emerge as the pain demands it. It’s exploratory by nature, and it’s great for that: prototypes, side projects, learning a new tool, building the thing you thought of in the shower.
Agentic development is workflow-first. It’s what vibe coding grows up into when you apply professional engineering discipline on purpose from the start: structured agent roles, deliberate context management, real review gates, the Actor-Auditor-Process-Improver loop running as designed instead of as something you reinvented at 2am. It’s the difference between discovering a process by accident and engineering one because you know where the failure modes are.
I split these into two separate buckets on this site for exactly that reason. If you want the disciplined, workflow-first side, managing AI like a serious part of an engineering practice rather than a toy, that lives over in agentic development. Same tools, different mindset, and honestly the place most of my own work has migrated to. Vibe coding is how you start. Agentic development is how you keep your sanity once it’s your actual job.
So Is Vibe Coding Worth It?
Yes, with conditions.
Reach for it when you’re exploring, prototyping, learning a tool, or building something where the cost of it being wrong is low and the value of building it fast is high. It is the best way I know to turn a vague idea into a working thing in an evening, and that’s not nothing. That’s a genuinely new capability that didn’t exist a few years ago.
Be careful with it when the thing has to be correct, maintainable, and alive in six months. Not “don’t.” Just bring the rails. Break it into phases, write the plan down, keep the auditor honest, and read the code. The same approach that makes a fun prototype will quietly hand you a maintenance nightmare if you skip the structure.
The articles in this category are the long version of all of this. The specific tools, the specific failures, the specific projects that taught me each lesson. Read the ones that match whatever you’re about to attempt. And fair warning: it’s addictive. Don’t blame me when you look up and you’ve got fifteen projects and a commit chart that looks like madness. That’s the price of admission.
And yeah, while I was finishing this guide, I started another project.
