I’ve been thinking about the phrase “vibe coding.”
Andrej Karpathy used it to describe a way of working where you mostly let the AI write the code and you stop worrying too much about the details.
That’s a real way of working.
But I think we’ve started using the same phrase for two very different habits.
Two Different Ways of “Vibe Coding”
| Type | What actually happens | Who’s doing the thinking? |
|---|---|---|
| Passive | AI writes it. You mostly just accept it. | Mostly the AI. |
| Active | You explore ideas with the AI, push back, change direction, and shape the final result. | You — with the AI as a partner. |
The first one is what most people complain about.
The second one is something good builders have been doing long before AI showed up.
When an experienced person says, “This doesn’t feel right,” nobody calls it magic. We call it judgment.
That judgment isn’t random.
It comes from years of building things, breaking them, fixing them, and coming back to them later. Your brain starts noticing patterns before you can even explain them in words.
That’s why some ideas suddenly feel obvious.
They weren’t sudden. They were quietly forming for a long time.
AI just changes what happens next.
Sometimes the first idea is yours.
Sometimes the AI asks a question that shows a weak spot in your thinking.
Sometimes it offers a direction you hadn’t seen.
Sometimes it’s confidently wrong.
And this is where I think we also need to appreciate something else: our strengths are diverse, and recognizing those differences matters.
When I interact with an AI assistant, my engagement is often more like having a research assistant or an improved “2010 Google search” 🙃. The difference is that today’s assistants can interact with us in ways that can create an illusion of literacy and understanding.
That doesn't mean we should treat every assistant as the same tool.
A junior developer quickly learns that the choice of tool matters. The same way a sledgehammer is better suited to breaking concrete than a nail hammer, different AI assistants may simply be better suited to different tasks.
Gemini may be better at one thing than ChatGPT. Alexa may be better at another than Grok. And none of that should be surprising. Different tools, different strengths, different purposes.
The more properly we learn how to use these tools, the healthier our development process can become — with or without AI.
And there is another part of this that I think we sometimes overlook: people are part of the toolchain too.
Seniors eventually move on, wear out, change roles, or retire. Juniors eventually have to take over. That means appreciating the process matters. What we learn today shouldn't only help us finish today's task; it should help someone else understand, maintain, and improve what comes next.
No matter how careful we are, humans are explorers by nature. We will always discover something new, question something old, and find another direction to try. Nothing stays perfect enough to satisfy that curiosity forever.
But one thing is worth carrying forward: the willingness to relearn.
We can adopt better tools without throwing away the values that shaped us. We can let AI change how we work without forgetting why we learned to build, debug, question, and understand things in the first place.
Who spoke first doesn’t matter much.
What matters is who made the final call.
Understanding something is a bit like walking without a map. You may not know every step ahead, but you know where you’re trying to go well enough to notice when you’ve started drifting off course.
Ideas don’t always belong to one mind anymore.
Sometimes the spark comes from you.
The next step comes from the AI.
The final result grows out of the conversation between both.
That isn’t passive vibe coding.
That’s still engineering.
The real danger isn’t AI.
The danger is reaching the point where you stop asking “why” and only ask “what’s next.”
There’s a big difference between using AI so you don’t have to think… and using AI so you can think better.
The first one takes over your judgment.
The second one strengthens it.
So maybe we’ve been arguing about the wrong phrase all along.
The real question isn’t whether something was “vibe coded.”
The question is:
Who owned the thinking?
And when the AI is gone, who still understands what was built?
Top comments (2)
Very beautifully said! ❤️ I think this idea applies far beyond software engineering. Take writing, for example. We can treat AI as a creative partner that challenges and improves our thinking, or we can blindly copy whatever it produces. The first approach makes us better at what we do. The second one... well... not so much. 😄
The 2nd probably amplifies the other side by dulling our own thinking and capabilities. 🤓