5 min read

On Getting Started

For anyone in a similar situation as me, the most important lesson from my experience is: just start. There's better and worse ways to start, but starting is the key.
On Getting Started

As I wrote last week, I decided that it was time to see what I could actually produce leveraging GenAI tools, and I was blown away by the result. In this post I'm going to lay out what my first couple days of "vibe coding" were like and some insights around the experience.

At the end of March I had some time off work and intentionally carved a couple days of that vacation to "vibe code" something. For a first project I wanted a use case that would get me into the swing of things, so I thought about using something I'm very familiar with as a starting point. I decided to start with a career development app to help manage my career progression by tracking tangible outcomes and activities in one place. It's the kind of thing that I had always wished I had access to as I was coming up in consulting (I've built a lot of Excels, OneNotes and PowerPoints to do this before; not fun).

What I really liked about picking something like this for my first use case was that because I'm so familiar with my own career in consulting, I should have an easier time both communicating requirements and validating whether the outcomes were good enough to spend further time on.

A really important caveat to all of this is that I was still thinking about this as a practice project. I would try this out, see if it was legit, and if it was I would move on to something else.

My first message to Claude

I signed up for Claude, and as you can see from my very first message, I didn't really know where to start. But I figured what better way to see what these tools can do than by just asking questions.

Claude asking targeted questions about what to track

Very quickly Claude turned that around and was asking me targeted questions about my use case. We did a back and forth for a while, mostly just me on my phone answering questions and asking for clarifications when I didn't understand the context. At some point, Claude suggested we had enough for a first build and recommended a path forward. Then came some questions about what I was ready to do to actually build the app.

Claude checking my machine readiness

As you can see, I was a bit over my skis here. But oh well, that's what this whole project was about! And honestly I think getting to this part quickly is pretty important. There's huge value in just starting stuff when you're playing around with new tech.

In any case, Claude walked me through the steps of getting things set up on my computer. I got VS Code sorted with the right extensions to use Claude Code and the rest of that first day was just me asking "Claude, what should I be doing?".

Claude Code showing the phase plan for the app

By the second day, we were cooking. I had it working fully on my localhost, and Claude had built out this long plan with different phases anchored in things I thought might be worth including. By the evening of the second day, I had set up various hosting services for the back-end, front-end and database, an email notification service, and even a github.

I didn't stop after day 2. I have a ton more things that I am going to talk about with this project and more generally about how I'm now approaching these tools a lot differently, but I thought this was a good spot to talk about what I think helped me in those first couple days.

The first thing I did was approach this whole process with a lot of curiosity. I've seen enough at work and in the news to believe that these tools are capable of doing more than what I could get from ChatGPT last summer, and that made me want to explore.

Curiosity and being open to finding value is important. I still see a lot of folks who have a resistant mindset around these tools. It's not necessarily negative, but they don't seem to believe that the juice is going to be worth the squeeze, and as a result aren't really willing to commit to the experience. I believe that impacts their ability to achieve real value.

The second thing is that I was more informed about the tools themselves and how to use them. I had heard about leveraging plan.md files and about skills (though it took me a week to start using them), I had seen some of Boris Cherny's tips posted on twitter, and I had seen a project my brother created. I think that this was particularly helpful from a speed perspective because it meant I avoided some of the traps and the rework that I would have had if I didn't have that additional context going in.

The third thing I did was just ask Claude a ton of questions, not just about the thing I was building but more holistically about my process and workflow. I was pretty explicit early on asking if I was communicating correctly. Things like "Am I asking this the right way?" or "How do you recommend I approach this problem differently?".

Because I'm not a software developer I'm coming at this like a blank slate. That has lots of cons but it also has some pros in terms of work speed, where I'm super open to saying: hey, what's the best way to get there? You tell me, and I'll just take direction.

For anyone in a similar situation as me, the most important lesson from my experience is: just start. There's better and worse ways to start, but starting is the key.

As you can see from the approach I took, it's a lot easier than you might think and you'll be surprised what you can do.