The name says it all: vibes
What is vibe coding? The shortest summary: you do it based on vibes. That’s of course the opposite of what a programmer does. They don’t do anything on vibes, always look at the logic and make sure everything makes sense based on systems and architecture.
The AI-assisted coder is still interested in the output. The vibe coder is not. They’re only interested in: does it work, does it look good.
Michael Hofman
In the most extreme form of vibe coding, you don’t look at the output at all. Why not? Because you’re not interested, or because you don’t even have the knowledge to evaluate that output.
The spectrum
It’s not a binary choice. There’s a spectrum between pure vibe coding and pure AI-assisted coding:
Vibe coding (extreme)
You don't look at the code. You only see if it works. If you're going to vibe code anyway, you might as well use something like Lovable where you don't even see the code.
Vibe coding (mild)
You sometimes look at the code, but only when something doesn't work. You copy the error message, paste it back and don't understand what went wrong.
AI-assisted coding
You're interested in what's being produced and want to know if it's actually good. You read the code—not every line, but the important parts.
AI-assisted coding (critical)
You check the code line by line, see when the AI goes wrong and steer directly. You have a clear opinion about the architecture.
Where do you stand on this spectrum? And more importantly: where should you be for what you’re building?
Do you have an opinion?
Another crucial difference: do you have an opinion about the code?
Someone who has experience building software, they have an opinion. They can say: “This is not the most convenient way to do it.” Or: “This doesn’t fit the architecture we have.”
Someone who has no experience, they don’t have an opinion. They can look at a piece of code, but they can’t make the decision: is this good or not? They only see that the application does what it should do. Click buttons, does it work?
You can look at the code and neatly check all output. But if you don’t have an opinion about it, you’re still doing it partly on vibes.
Why the distinction matters
The problem is not vibe coding itself. The problem is thinking you’re writing production code while you’re vibe coding.
Vibe coding = proof of concept
Actually, the vibe coder always makes a proof of concept. Whether they want to or not. If you don't look at the code, you're always making a concept.
AI-assisted coding = production code
Only when it's been checked by someone who has put work into the code, is it production code. That you can deploy.
That’s an important insight. Many people think they’re writing production code because their application works. But working is not the same as production-ready.
The trap for beginners
If you’re just starting with programming and you don’t want to be a vibe coder, you indirectly are anyway. Because you can look at the code, but you don’t actually have an opinion. You don’t have the experience to judge whether something is good.
The only difference is that you can learn from it. You see the code, you learn the patterns. And maybe over time you go from vibe coding to AI-assisted coding. The question is just: how often does that happen? Because it’s very human to stay lazy. And most people aren’t curious enough to want to know how it actually works.
When is vibe coding fine?
Vibe coding is not necessarily bad. It has its place:
Small, standalone projects
For small projects I have no problem vibe coding at all. It has no impact if it doesn't work. The risk is very low.
Prototypes and validation
If you want to quickly test whether an idea works, vibe coding is perfect. You're building something to learn, not to deploy.
One-time scripts
A signature generator, a data export script. It doesn't matter how ugly the code is if it works once.
Frontend styling
Quickly tweaking something with Tailwind? Fine. But for a design system of an enterprise dashboard, you definitely need to know what you're doing.
The difference in practice
A concrete example: you’re building an application with a state machine. With AI-assisted coding, at some point you see that the AI is going wrong. You see: “Okay, what you’re going to do now is wrong. That’s just incorrect.” You have the entire context of the app in your head. You know this doesn’t fit with the style of the rest, or not with the ideology you have.
With vibe coding, you don’t notice this. You only see that it works or doesn’t work. The underlying error remains hidden until it causes problems later.
Often the AI misses something. Then the solution is that you think: this works. But I have the entire context of the app in my head. This is not the ideology we have.
When should you switch to AI-assisted?
There are three clear signals that you should switch:
Too big for the context
As soon as the project becomes too big to fit in the context at once and the AI can no longer oversee it, it starts going wrong.
You're writing production code
If the code is actually going to run in production, you need to know what you're doing. Vibe coding by definition produces a proof of concept, not production-ready software.
You know it's going to be big
Starting something you already know will become a big project? Start with AI-assisted coding right away instead of having to refactor later.
There’s nothing wrong with vibe coding, but the tipping point is where your project becomes too big for the AI to take in all at once. Then it starts going wrong.
When the AI loses context, you see it doing things twice, doing things wrong, rebuilding features you already have, or building features for something that doesn’t exist or isn’t needed.
Conclusion
Vibe coding and AI-assisted coding are both valid approaches. The problem only arises when you don’t know where you stand. When you think you’re writing production code while you’re actually making a proof of concept.
Know yourself, know where you stand on the spectrum, and know when to switch.
Have a vibe-coded project that needs to be production-ready?
We help founders and teams go from proof of concept to production code. Honest advice about what works and what doesn’t.
