Just Build Dope Shit: How I Started Vibe Coding Without Reading the Manual

I want to share with y'all how I got into vibe coding.

It's honestly basic AF, so my bad if you were expecting something more elaborate.

My mentor set me up to meet another PM. We chatted and really hit it off. I mentioned some ideas I'd been kicking around, and he was like "dude, you're a PM. Go build that shit."

I was like "I can't code, but I've been fuckin' with Lovable a bit."

He goes, "nah man, you gotta dig into Claude Code. I'm telling you, it's easy. Just do it."

So I did.

I legit watched 3 minutes of a 40-minute video on how to use Claude Code, then just started building. Downloaded VS Code, installed Claude Code, described a problem I had, and started poking at it. That's it. That's the origin story.

Everything I've shipped since (my site, Selector, TyperFocus, a whole personal AI OS running out of my Obsidian vault) came from that same move. Just start. Figure it out live.

And I want more of you to do this. Even if it's just for fun. Actually, especially if it's just for fun.

The paralysis is the real bug

I'm sure there's a lot of folks out there who learn great from an hour-long YouTube called "The Ultimate Beginner's Guide to Claude Code!" I'm just not that guy. I'll be on Monkeytype four minutes in, not paying attention.

I have ADHD and dyslexia. So the standard advice (read these 12 posts, set up your environment this way, learn these fundamentals first, follow this 9-step process) was never going to work for me. My brain checks out three bullets into someone else's rigid process. I'd have quit before I built anything.

So of course I didn't do that shit.

I still picked stuff up, just not up front. I'd breeze through a blog when I got stuck. Grab a template or two. Scan Claude's docs on prompting when I couldn't get a feature just right. Anything that actually helped, I kept. The rest, I didn't sweat it. Over time I turned what actually worked into reusable Claude skills, but that came later, from doing, not from studying.

That's the whole secret. You learn way more from building than from prepping to build. You don't need to absorb the whole internet first, you just need enough to start.

The three things I actually leaned on

I didn't follow a framework. But looking back, three fundamentals carried me the whole way.

1. I started with a problem, like a PM.

This is just my day job pointed at my own life. I don't open terminal and think "what should I code today." I think "this thing sucks, can I make it not suck or suck a little less? Or maybe I can make it dope AF?!?!"

Selector started off as an easy way to build setlists from my record collection (got offered to play a set at a farmer's market but could never make it out, kids won). TyperFocus exists because I needed a way to stay engaged when studying new and dense topics. The problem comes first, always. The code is just how you answer it.

If you have a problem you actually care about, you're already 80% of the way to knowing what to build. The tech is the easy part now.

2. I treated Claude like a room full of thought partners.

This one changed everything for me.

I don't talk to Claude like a search engine or treat it like a calculator. I talk to it like a team. I'll literally say "be my UX manager for a sec, poke holes in this flow." Then "okay now be a skeptical senior engineer, tell me why this approach is going to bite me later." Then "cool, now draft a prompt for Claude Code and let's build something dope."

And because I spent 10+ years actually working with UX leads and engineers, I know what good pushback from those roles sounds like. So I can tell when the answer is real versus when I need to press harder. Not gonna lie though ... I did fall into the trap more than a few times of Claude just stroking my ego...

You're not just getting code. You're getting a stakeholder review, a design critique, and a build partner, on demand. Use all of it.

3. Most important: I tried things without being scared of mistakes.

This is the whole game. If you take one thing from this post, take this.

I broke stuff constantly. Still do. I shipped things that didn't work, built dumb shit that wasn't thought through, went down dead ends, ripped out entire approaches. None of it mattered. Every mistake was just information about what to try next.

And here's the freeing part: a bad first draft costs you basically nothing. You try something, it doesn't work, you toss it and go again. No standup where you explain yourself. No PR review with your name on the mistake. Just you and the loop, moving fast because nothing you try is expensive. That's the whole trick.

Try the thing. Break the thing. Fix the thing. That loop is the entire skill.

You don't have to be technical. You have to be curious.

Let me be really clear, because I think this stops a lot of people:

You do not need to be an engineer to do this.

You need to be ready to learn. You need to stay curious. You need to ask questions when you're stuck (and ask your friends too, seriously, text someone who builds and say "how would you approach this"). That's the actual prerequisite. Not a CS degree.

I came to this as a PM. My superpower wasn't syntax, it was knowing how to define a problem, interrogate an idea from a bunch of angles, and keep moving when it got messy. You probably have your own version of that from whatever you do.

So go build dope shit!!!

Learning to vibe code has been genuinely liberating for me. The gap between "I have an idea" and "the thing exists and I'm using it" collapsed. That's a wild feeling and I want you to have it.

You don't need permission. You don't need the perfect setup. You don't need to read this post again.

Pick something that annoys you. Open Claude. Describe it. Start poking.

Build dope shit. That's it. That's the whole method.

• The Homie Jay