Choosing a Coding Approach, Not Choosing Sides
The issue isn’t whether you use vibe coding or AI-assisted engineering, but whether you know which one you’re using.
There were periods when I vibed a lot. There were periods when I barely allowed myself to vibe. Not because one way is “more correct” than the other, but because different contexts require different ways of using AI. After observing myself and those around me for a while, I realized the problem isn’t about whether to vibe or not, but about knowing when to vibe and when not to.
Vibe coding, to be fair, is a very interesting experience. There are times when I just want to quickly test an idea, build a prototype, or see if a flow is feasible. In those moments, vibe coding is the perfect choice. I describe the idea, let AI quickly implement the backbone, then look at how the system works overall. No pressure, no perfectionism, no need for immediate optimization. The goal then is speed and the feeling of moving forward.
But I’m also very clear with myself: the code vibed out in this phase doesn’t represent my engineering capability. It’s just a draft. A sketch. And if that code starts getting close to production, I’ll switch modes.
That’s when I return to AI-assisted engineering.
In this mode, AI is no longer the “ghostwriter”, but a supporter. I already have a model in mind: how data flows, where module boundaries are, where risks lie, where to keep things simple. AI helps me save typing time, suggests syntax, reminds me of familiar patterns. But the decision is still mine. If the code has bugs, I don’t ask “where did AI go wrong”, but ask “what am I misunderstanding”.
The biggest difference between the two ways of using AI, for me, lies in responsibility.
When vibe coding, I accept the risk. I know I’m trading certainty for speed. And I accept that I might have to tear it down and redo it later. But when transitioning to AI-assisted engineering, I no longer allow myself to “guess and try”. I must understand the code deeply enough to take responsibility for it – both when the system runs well and when it encounters issues at midnight.
What concerns me is that many new engineers can’t distinguish between these two states. They vibe in every situation. Vibing during experimentation is fine, but vibing even when code enters core logic, data pipelines, or business-critical flows is when risks start appearing. Code runs, tests pass, but no one on the team truly owns the understanding of it. And when problems occur, the first reflex isn’t to analyze the system, but to… ask AI again.
AI isn’t at fault here. The fault lies in users not switching roles at the right time.
I personally believe that:
- Vibe coding is suitable when exploring, experimenting, or needing momentum.
- AI-assisted engineering is mandatory when building things that will exist long-term, need maintenance, need to scale, and need people to take responsibility.
The problem isn’t “don’t vibe”, but don’t confuse vibing with capability. AI can help you go very fast, but only engineering thinking helps you go the distance. If you use AI to accelerate things you already understand, you’re learning very quickly. But if you use AI to replace understanding, you’re just delaying the price to pay.
I still vibe. But I always know when I’m vibing, and I never let vibe decide things that I’ll have to carry later.
Perhaps, the most important skill in the AI era isn’t writing good prompts, but knowing when to trust AI, and when to trust yourself.