Not All Vibes Are Equal

In the first article in this series, I wrote about building the aboycalledhero block with AI and the lack of confidence that came with it. I landed on something simple: what matters is that you care about what you build. This article starts there and opens a wider door.

If caring is the foundation, the next question is practical: how do you actually do this? And the answer is that there's no single right way.

The word on everyone's lips

"Vibe coding" took off as a term in early 2025. The idea: instead of writing code yourself, you describe what you want to an AI and it generates the code. You run it, see what happens, iterate.

Simple enough. But the term has become a blanket for very different things, and not all vibes are equal.

The landscape

There are broadly three kinds of tools out there.

App generators like Bolt, Lovable, and v0 let you describe what you want and get a running application back. Frontend, backend, database, sometimes deployment. You never touch code.

AI-augmented editors like Cursor and Windsurf sit inside a development environment. They autocomplete, generate, and refactor code while you work. Tools for people already in code who want to move faster.

Conversational AI like Claude or ChatGPT is different again. For me, working with Claude feels like thrashing out a solution with a colleague. I ask questions, push back, challenge the output, and find a route together. I listen the way I'd listen to someone who's done this before, but I know I'm ultimately the driving force behind where it's heading.

Each has a place. None is the "right" one. What changes the outcome isn't the tool. It's what you bring to it.

Skills that help (but aren't code)

You don't need to be a developer to build things with AI. But a few skills make the process better, regardless of which tool you use.

Knowing how to describe what you want. The clearer you are about what you're building and why, the better the output. This isn't prompt engineering. It's thinking before you start.

Being willing to test. Not just "does it run," but does it work the way someone would expect?

Understanding who it's for. Thinking about the person on the other end shapes better decisions.

Thinking about what makes software good. Is it secure? Is it accessible? Will it still make sense in six months? You don't need to know how to implement encryption, but knowing that a donation form needs it is the kind of thinking that separates something that works from something that's trustworthy.

Iterating without settling. The first output is rarely the best. Being willing to go back and push for better is where the real work happens.

These aren't all developer skills. They're thinking skills. They apply whether you've been building for twenty years or twenty minutes.

An invitation, not a gate

There's a version of this conversation that turns into gatekeeping. That says you need a certain level of experience before you're "allowed" to build with AI. I don't believe that.

Curiosity is the best starting point. Can this be done? Can I do this? Is this even possible? Good questions lead to good answers.

These tools have made it possible for more people to build things than ever before. That's not a threat to experienced developers. That's a good thing for everyone.

What I'd encourage, for newcomers and veterans alike, is to care about what you produce. Not because someone is watching, but because the thing you're building will be used by someone.

No one right way

The platforms are different. The tools are different. The people using them are different. And that's fine.

How you produce the code matters less than whether you care about the fact that it does what it does, well. There are many ways into this. Find the one that works for you, stay curious, and hold yourself to a standard that makes you proud of the result.

This is the second in a series of articles about my vibe coding experience, AI-assisted development, and what it means to care about the things you build.