The best thing I built last year started as a note I made at 11pm: “what if you could do X but without Y.” No spec. No user research. No market sizing. Just a nagging feeling that something was wrong with how a thing worked, and a rough idea of a better way.
Three weeks later I had something I was proud of. Six weeks later other people were using it. This is not how software is supposed to be built. And yet.
What Vibe Coding Actually Is
I want to be careful here not to romanticize sloppiness. Vibe coding isn’t “moving fast and breaking things” — that phrase was always an excuse for not thinking carefully.
What I mean by vibe coding is something specific: building from intuition that’s been trained by a lot of deliberate practice.
The jazz musician who improvises isn’t being random. They’ve internalized enough structure that their spontaneous choices are constrained by pattern and taste. The “vibe” is the expression of that internalized structure, not the absence of structure.
Similarly, when I build something by feel, I’m not avoiding thought — I’m operating on cached thought. Years of noticing what makes tools good or bad, what makes code maintainable or brittle, what makes products feel right or wrong.
The Conditions That Make It Work
Vibe coding doesn’t work for everything. It works when:
The cost of being wrong is low. Side projects, experiments, personal tools — these can absorb pivots and rewrites. Production systems serving thousands of users cannot.
You have genuine taste in the domain. If you’ve used bad tools for years, you know exactly where they fail. That frustration is a design brief. If you’re building in a domain you don’t inhabit, you’re just guessing.
You’re not blocked by others. The moment vibe coding requires coordination — standups, PRDs, stakeholder approval — it stops being vibe coding. It’s a solo or very small team mode.
The goal is to discover, not to execute. If you know exactly what you’re building, maybe spec it out. If you’re trying to figure out what you’re building, vibe coding is often faster than trying to think it all out upfront.
The Actual Workflow
Here’s what vibe coding looks like for me in practice:
Start with the use case, not the architecture. Open a file. Write the code I wish existed. Don’t design the system first — see what emerges from trying to use it.
Keep sessions short and committing. Two-hour focused sessions where I’m actually building, then a long break. Distance from the work lets me see it fresh and notice what’s ugly.
Ship embarrassingly early. The first public version should feel too early. If it doesn’t, I waited too long. Real users reveal things that imaginary users never do.
Follow the interesting threads. Sometimes mid-build, I notice an unexpected possibility — a feature I didn’t plan that would be genuinely cool. In a spec-driven project, this gets logged for v2 and forgotten. In vibe mode, I follow it. Some of my best features came from this.
The Defense of It
There’s a version of software culture that treats intuition as unscientific, non-rigorous, and unprofessional. I understand why — software has real consequences and gut feeling is often wrong.
But I think this view confuses intuition with inexperience. Inexperienced intuition is unreliable. Trained intuition, developed through years of building and breaking things, is actually a fast and powerful form of reasoning.
The engineers and designers I most admire have both: the rigor to think carefully when careful thinking is needed, and the cultivated instinct to move decisively when the situation calls for speed and feel.
Knowing which mode to use — that’s the real skill.
Ship the thing. You can fix it later. The worst outcome is never knowing if it was any good.