Ilan (00:00)
Leave us, sorry, I'm trying to remember what we usually say here.

Hey everyone, welcome to Prompt and Circumstance I'm Ilan

David Vuong (00:08)
I'm David.

Ilan (00:09)
And today we're giving you our top five tips for vibe coding.

All right, on today's episode, I asked David to bring his top five tips. I brought mine and we haven't seen each other's list. We're going to go through these. We're going to go back and forth. We're going to see where we overlapped and where we didn't, where we had different tips. So.

David Vuong (00:42)
That's right.

And hopefully we don't disagree to the point of getting into fisticuffs.

Ilan (00:48)
That's right. I

mean, this might be the last episode we ever record. So with that, let's not dilly dally. Let's not waste any time here. David, I want to hear what's your first tip.

David Vuong (00:51)
That's right. ⁓

Let's get into it.

Ilan (01:06)
But first let's hear from one of our sponsors

Do you have a side hustle? Why not? If you're worried about validating your market or finding time to build your product, then Co.Lab's Validate and Build will help you out.

They'll go out and ensure that users really want your product and then they'll build an MVP so that you can have your first paying customers. They'll hand off the product to you and you can take it from there so you can run your side hustle.

link below to find out more and let them know David and Ilan sent you for $250 off.

David Vuong (01:38)
My very first tip is that ⁓ although on the surface, seems like there's meaningful differences between the various different tools. ⁓ for somebody who's doing it for the first time, it doesn't really matter. They are both ⁓ sufficiently capable for you to first learn about vibe coding and to be able to create, say your first prototype.

Ilan (02:04)
That's really interesting. have, like we have ⁓ the polar opposite on the same axis. So my first tip is to try a different tool. So if you don't get what you want out of one tool that you're trying out, just try the same thing in a different tool and see what it gets you.

But it's born same

logic. It kind of doesn't matter which tool you're using. ⁓

David Vuong (02:32)
Yeah.

Exactly. was going

to say exactly that, which is that, ⁓ you know, our feelings about how well differentiated these are or how meaningfully differentiated they are, are the same. Our recommendation might be slightly different, but I think overall we mean the same thing.

Ilan (02:54)
Yeah, absolutely. So that'll be the number one tip. It doesn't matter which one. Actually...

David Vuong (03:00)
It that's right. It doesn't matter. So, Hey, look, give it a go

on v0

And if that doesn't work for you, take that same prompt and go over to Lovable Try that out or Bolt or Replit

Ilan (03:14)
That's right. This is not one that's on my list, but you know what? You're gonna get a bonus tip from me here. Look at who has the biggest free tier.

David Vuong (03:19)
Bonus tip, whoa.

Yeah, that's true. As you're trying out these tools, you want to make sure that you're able to achieve the outcome that you're looking for within a free tier.

Ilan (03:37)
That's right. And on that, in my experience, David, I'd be curious to hear if you have the same feeling. V0 is the tool that has the largest free tier, the most generous free tier. It's the one that I, it's the one that I tend to recommend for a first try for folks because of that.

David Vuong (03:50)
I would tend to agree.

Yep, that makes sense. I think I would gravitate toward V0 as well. The winner of our track meet.

Ilan (04:06)
That's right. If you haven't heard that, go back into your history. Check it out.

David Vuong (04:12)
Yeah.

Ilan (04:13)
Alright, David, we sort of agreed on our first tip, so I'm curious to hear what's your second one.

David Vuong (04:21)
All right. So my second tip is you ought to get a GitHub account, create a GitHub account, connect it to your vibe coding tool of choice. And that way you can put the code into get, you can commit it. And if the tool manages to mess up your prototype, which it totally might do, right?

then at least you have that Git backup. Now, not only that, but backing it up into Git can allow you to very easily switch tools. So let's say that the experiment that you did on Lovable, it was halfway to what you wanted to accomplish. You commit that to Git, and then you go over to say Bolt, and then you just import that Git repo, and you can continue from there.

Ilan (05:15)
That's a really good tip David.

That wasn't on my list at all. Is this how your workflow, this is how you set up your workflow in these tools?

David Vuong (05:25)
It certainly was the case for a few prototypes that I had gone through. And after five or six attempts at vibe debugging, where it screwed itself up even harder, ⁓ out of a fit of rage, I evacuated my code and brought it over to another tool. How about you?

Ilan (05:48)
it's an interesting question. I struggle because my GitHub account is public. And so sometimes I'm very happy to commit my projects to Git and sometimes I want to keep them to myself. So I feel like there may be a paid Git account coming into my future.

David Vuong (06:06)
Way to product led growth.

Ilan (06:09)
That's right. sort of wonder, just a random thought, I sort of wonder if there's the next big vibe coding tool is a meta vibe coding tool. It's like the perplexity of vibe coding tools where you put in your, you could put in your prompt and then you could send it to one or other of the tools or have it decide based on your prompt which tool to use. And then you just have one.

David Vuong (06:36)
It would be a ⁓ vibe broker.

Yeah.

Ilan (06:38)
Yeah, that's right.

David Vuong (06:43)
How about you?

What's your second item then?

Ilan (06:46)
My second one is to feel free to rage quit and start over. It's even within the same tool. If you don't get what you want from the first attempt or even the second attempt, just try it again.

We know that LLMs are probabilistic. We know that they don't give the same response each time. And again, going back to our track meet, I was actually stunned at how well tools could perform from one attempt to another in the pole vault, or even mentioned that in the AI snake game, that with Bolt, I was having a ton of trouble.

and then gave it the prompt again, and it basically one-shotted the prompt the second time.

David Vuong (07:32)
Yeah, that's a really good tip. I didn't have that one. ⁓ I do want to add onto it to say that in the free tier of Replit, you have a limited number of apps. Currently, I believe it's three. And so when you rage quit, you can just delete that broken app and make a new one. So you can stay within your free tier limits.

Ilan (07:56)
⁓ a good tip for those of us with short pockets. Alright David, what's your next tip?

David Vuong (08:01)
That's right.

All right. My next tip is a really important one. And I think, ⁓ any product person who wants to try out vibe coding needs to do this first. So your prompts are probably not so good. If this is your first go at vibe coding, you can bet probably that your prompts are going to be subpar.

And so what do mean by that? What can you do to make it better? All right. First of all, you're going to want to give it probably a full PRD with the entire specification of what functionality is needed. Sure. Some business context would be nice, but the critical part is the functionality and be clear as to what it needs to do and what it should expect. So the sub bullet point on that is if there are any data structures that it needs to work with.

be explicit as to what those are. Give examples of what the payload from the API ought to be. ⁓ I had come across this example where in the pole vault, I failed to provide exactly the specification for the API payload. And lo and behold, the tools had problems figuring out where to extract the data that they needed to.

because I didn't tell them to. mean, you know, just like what the super intelligence of the future might come, might conclude the problem is with the human. So if you are going to start the vibe coding first, think hard about what all functionality you want to have in your prototype or your, your full on product.

Ilan (09:37)
Ha ha ha!

David Vuong (09:50)
think really hard about that, spend a lot of your time to make sure that that is just top tier because that will make a difference between a mediocre prototype and a stellar prototype. And in fact, what you can do is actually use well, AI tools to help you with this. You can talk to your LLM of choice, tell it, Hey, I'm thinking about this and that.

have a conversation maybe and then at the end have it spit out a draft PRD, which I might have done with the pole vault. And then you can then hand manipulate the small details of that.

Ilan (10:29)
So that was also one of my top tips. I phrased it as get help promptly from other tools. ⁓ And I was thinking exactly the same. mean, in my first tests of Replit and v0, I was just giving, you know, my three sentence prompt, maybe using their AI tool to...

David Vuong (10:38)
I like that. Yeah.

Ilan (10:56)
make that into a PRD. But I quickly realized that that was just not going to yield good results. And this actually dovetails with another one of my tips. So which is to go big. These tools are capable of doing a lot. If you are precise, if you give them a really good PRD, they can accomplish a lot in very little time.

So David, I had the exact same advice as you did, which is go into your LLM of choice. Personally, I found Claude works really well for developing PRDs. And as you said, give it the prompt, give it a, a role, right? Make sure that you're telling it what it needs to, what its role is in this product team.

have a chat with it just like you would with maybe the architect or tech lead of your team about what information does it need to know, and then have it spit something out. And you can fine tune that, or you can even just drop it into a tool and see what happens, see what mistakes it makes, and then refine your prompt from there and start over fresh.

David Vuong (12:12)
Yeah, that's a great piece of advice. I would add that as you're talking with the LLM of choice, to help it with the level of clarity in the PRD, tell it that it's writing the PRD for a junior developer. This way it'll spell out a lot more context and be a lot more explicit with what the junior developer needs to be able to do.

Ilan (12:38)
That's a great tip, David. I'm going to start using that right away.

David Vuong (12:43)
Let's do it.

All right. So the next tip that I've got is that, ⁓ I think when using vibe coding tools, we ought to be clear to ourselves, whether we want a prototype or a product, very different things. And when we look at some example, videos of people making cool stuff on YouTube,

What they're doing is they're actually making closer to a prototype. And when I say that, ⁓ I'm thinking from the perspective of a product person who's working on existing software. Existing software has existing constraints that must be met.

So if the API that you want to tap into has, you know, a certain way of getting the bearer token and it has a particular payload and it needs to have dependencies with another API in order to get the necessary data, ⁓ to populate the IDs. All of that must factor in to, your prompt, your specification so that you can be crystal clear. ⁓ but

what we often see, or at least what I often see on YouTube is that, okay, cool, let's just make something from scratch. And this way it has a lot more degrees of freedom, right? The Vibe Coding tool can just, oh yeah, sure, this data structure works well for what it wants to accomplish. So therefore it is. And that is not necessarily the case if you are building something that is an extension to an existing product.

Ilan (14:21)
I'll even say that sometimes when you give precise instructions, it will still hallucinate. I had this experience recently where I gave the tool an instruction of how to populate a field, the options to populate a field, and I gave it a CSV with exactly the options that I wanted to populate, and it hallucinated extra rows in the CSV, and it did it three times in a row.

David Vuong (14:46)
Yeah

⁓ boy.

Ilan (14:50)
It's a great tip, David. The most users first interaction with these tools is probably going to be for a prototype, right? They're going to try something out and it's important to understand that they are capable of building full products. And to your point, you need to be precise with them about which role, which type of use case you're going for.

to be able to get the best results.

David Vuong (15:19)
What's your next tip?

Ilan (15:22)
My last tip is to use visual cues.

These tools share the same foundation models. They'll use similar styling. They'll use similar overall structure, right? They are inspired by the same applications that exist out there and they'll all use the same purple gradient if you don't tell them anything different. But it's really easy to attach some images and tell it to use the colors from this image.

Or attach a Figma design if you have one and tell it to follow that design. Or even if you're debugging something, take a screenshot of the area that you're debugging and draw a circle around what you want it to fix and tell it, this is the thing that is broken. Please fix this. And I found since I started doing this, my products look more unique. They...

fit the user experience and user interface design that I am hoping for. And I also have an easier time debugging UI issues and UX issues.

David Vuong (16:41)
That's a great piece of advice. yeah, you know, I think about how easy it was just to add our logo, for example, to one of the, events at our track meet. And that made a world of a difference in terms of the styling. ⁓ so that's a, that's a good point. My last tip is a bit more meta.

It has to do with really the actual responsibility of a product manager overall. These vibe coding tools can make it really easy to be feature focused, be ⁓ output focused, right? They can drive some serious feature factories. I think it's really critical to first to think about is this the right problem to solve?

Ilan (17:30)
Mm-hmm.

David Vuong (17:31)
Right. And, I think we ought to really stay focused on that as product people, because that is our, ⁓ value proposition really. Right. We understand the context, ⁓ and we understand the business that we operate in. And so we ought to make the right choices for what it is that we want to prototype or perhaps build, ⁓ in these vibe coding tools.

Ilan (17:56)
That's so true, David. I will hijack a point that I saw from our friend Rami at Querio.

We love to look at cursor and Lovable and say, wow, look, they got to 30 million ARR, 50 million ARR, 100 million ARR in just this many months. And so you too should be building AI tools, but AI is just that it's a tool. It's a means to an end. And really what Lovable did, what cursor did, what a lot of these AI unicorns

are doing, they're solving deep problems for users. And in fact, many of them did not start with AI. They were just traditionally coded products and started to add on the AI functionality to sort of boost them up ⁓ over time.

If you're sitting here going, I want to build the next solopreneur, $10 million company, $20 million company, right? Or as the CEO of Anthropic predicted that the first solopreneur unicorn would happen in 2026. Right? If you want to be that person, what you need to be doing is not throwing AI at the wall, but solving a deep

deep user problem you're sure people would want to pay to solve.

David Vuong (19:26)
Yeah, absolutely. You know, think about the desirability risk, ⁓ that, that Cagan talks about, right? ⁓ another way to put it would be the planning part of the Deming cycle, right? Plan, then do check act. and you know, this is the opportunity for product people to spend more time doing the planning part of it to do the market validation, right? you know, once you do sense

Ilan (19:31)
Mm-hmm.

Right.

David Vuong (19:55)
that there is a problem to solve here. check to see whether there's a willingness to pay. Right? ⁓ Cool. You built a useful tool that solves maybe a problem that nobody wants to pay for. Congratulations.

Ilan (20:02)
You

That's

All right, David. So we've each given our top five tips. We had a couple of overlaps, which I'm very happy about. And we had a few where we didn't overlap, which I'm also very happy about.

so in the end that leaves us with five top tips to give all of you for vibe coding.

Ilan (20:31)
But first let's hear from one of our sponsors

Are you having trouble wrangling too many data sources to get answers to your product questions?

Querio's AI agent sits on top of your data stack and connects the dots so that you can get product insights at your fingertips.

I use it personally and it saves me hours per week. You can try it too. Go to querio.ai and let them know that David and Ilan sent you and they'll give you two months free of Querio.

Ilan (21:02)
And starting with number five, the tip is don't be afraid to start over.

David Vuong (21:07)
That's right. Sometimes these tools can mess up. It's okay to delete the entire application. Start over with the same prompt.

Ilan (21:14)
Yeah, absolutely, David. The next one is switch tools when needed.

David Vuong (21:21)
Yeah, their capabilities are very similar. And so it's okay to go from one to another if rage quitting on one constantly doesn't seem to work.

Ilan (21:30)
along with that, don't be afraid to just pick one to start with. Pick one with the largest free tier and start there and you can always switch.

Tip number three is get Git

David Vuong (21:43)
That's right. Because these things can mess up, it's good to have a repository to keep your code safe and maybe even to help you move tools.

Ilan (21:53)
Absolutely right, David. It's so important to have a backup on the working parts of your application.

and the ability to go back if you find that your tool has just gone completely off the rails. Number two is make your prompt a PRD.

David Vuong (22:15)
That's right. Make sure that you are comprehensive with the functionality and also with documenting any kind of related information, such as the payloads from APIs.

Ilan (22:28)
And use an LLM of choice to help you get there, right? Get it to act as a senior developer or senior product team member who's writing a PRD for a junior developer ⁓ so that you don't have to put in all that precision yourself the first time around.

David Vuong (22:48)
Alright, and number one is be a great product manager.

Ilan (22:54)
That is so important, David. I don't know about you, but it drives me nuts when I see these posts on LinkedIn that are like, how to be an AI product manager? Like, no, you don't need to be an AI product manager. You just need to be a great product manager. AI is a tool. It can help you to make great products for your users. But if you don't have a good problem, you don't have good context, you don't have a good business case, it's gonna be worthless.

David Vuong (23:18)
Absolutely. Don't forget what our actual value proposition is to the business. Make sure that you are solving problems that are worth solving.

Ilan (23:28)
Well with that, those are your top five tips for vibe coding. We hope you enjoyed. Leave us a comment, leave a review. Let us know. Do you have another tip, something that you think that we didn't mention that would be hugely valuable for people to hear? Put it in the comments below.

And you can follow us on all the socials @pandcpodcast

That's all for this week. Thanks.

David Vuong (23:49)
All right. See you at the next

one.