Let's first understand how vibe coding (as it's currently trending) works:
- Don’t touch the code.
- Don’t touch the keyboard—just speak.
- Blindly accept everything.
You can use any of the following tools:
- Bolt[dot]dev
- Lovable
- Cursor AI
- Windsurf AI
Oftentimes, you don’t even write prompts. You use ChatGPT or Claude, meaning you have no real control or understanding of your code—or even the product you're trying to build. You just focus on one thing: the VIBE, and let the chaos unfold… until you run out of money.
My Opinion: It's one of the worst approaches to building software.
So how do I approach vibe coding?
- Always make sure I understand exactly what should be done and how it should be done.
- Boilerplates and workflows are my own.
- Keep prompts specific and to the point, and provide them with maximum context needed to implement a specific feature.
- One thing at a time.
- Set proper rules and instructions for an LLM to follow while writing code.
- Review everything before accepting anything.
- When I feel that AI is getting stuck or going off-track, I take charge.
IDEs, Extensions, and CLI tools I use:
- Cursor AI (Primary IDE)
- Cline/Roo Code (Agentic coding extension)
- Claude Code (Agentic, CLI-based tool)
- ChatGPT 4o with search enabled (for research)
AI models I use:
- Claude Sonnet 3.5 and 3.7 (Primary)
- Claude Sonnet 3.7 with Extended Thinking (for diagrams, architecture, and system design)
- Gemini 2.0 Pro (for long-context tasks)
- OpenAI o3 Mini and GPT-4o (for brainstorming)
- DeepSeek V3 and R1 (when using Cline/Roo Code)
Benefits of this "True Vibe Coding" workflow:
- Saves me tons of time—work that might take days can be done in hours.
- Lets me focus on the bigger picture and deeper aspects like infrastructure and system architecture.
- I learn through it—sometimes the AI suggests solutions I’ve never seen, so I discuss the "why" with it and dig deeper.
- No more wading through messy documentation—AI handles it well.
- Over time, it adapts to my style—my design patterns, my coding approach—and even helps refine them.
Cons? Yeah, a few:
- It can feel expensive, but the value-to-cost ratio is more than justifiable.
- Sometimes it hallucinates—caused by bad prompts, model downgrades, glitches, or poorly sized contexts.
Now let’s address a common misconception:
That vibe coding is dangerous for beginners because it might take away the habit of writing code—which is crucial for software engineering.
Why do I say that’s a misconception?
Let me give my example.
When I started coding, the hardest fear to overcome was writing code—the syntax part. Why? Because I wasn’t confident.
Though I eventually overcame that fear, I still didn’t write much code myself. I would copy-paste solutions from Stack Overflow, GitHub, and tech blogs—not blindly, but with the goal of understanding them: the hows and whys.
Fast forward to today: things haven’t changed—they’ve evolved.
Now, instead of searching Stack Overflow or GitHub, I ask AI. It gives me everything—from the solution itself to a comprehensive breakdown of why it works, how to optimize it, and what alternatives exist.
Writing code by hand is not the ultimate goal of software engineering.
It’s just a tool for solving problems.
As long as we understand exactly what we’re doing, I don’t find it problematic to let AI write the code for us.
Top comments (2)
Excellent write up. I appreciate the workflow and the insights.
But I will say, I adamantly disagree with this:
It unequivocally is.
It's the antithesis of active learning. Writing the code and adapting past the cognitive dissonance stage is the actual learning part. Having sources to work from is incredibly important too, but it's a half measure compared to putting these things together for yourself.
And it basically relegates you to being a technical PM of your own code.
I think you'd find this workflow can count against you if you're ever up against a tricky enough use case. But I'll concede that's definitely an outlier for most engineers.
And I won't be so backwards as to argue that there's not an obvious tradeoff here for time and output. And being able to engage with the output does allow for you to still learn something here. You do still have to conduct and wrangle the output, especially to build a larger scale system.
Anyway, no direct disrespect intended. Thank you for sharing!
This is laid out in a generic fashion, but sets the tone to know how to vibe code properly. The Crux is in "So how do I approach vibe coding?". It takes hours to play with the tools you mentioned to generate boilerplate code and more to make it reliable.
Let me introduce something more interesting, something that is born on the premise of how developers actually code to create a highly reliable code: Convert Figma to functional code, use personalized coding standards, APIs to make the 1st workshop prototype - all within 15 to 20 mins. Here's how it looks:
youtu.be/ijHEK_wPsAA?feature=shared
GitHub: github.com/Niiti/HuTouch-AI-Demo/b...
Happy vibe prototyping 😎😀