Every Vibe Coder Needs to Hear This (2025 Advice to self)
March 21, 2025
Parker breaks down when vibe coding works, when it doesn’t, and how to actually ship reliable AI-driven features with solid prep instead of chasing hype.
Quick takes on tools and market#
- ChatGPT pricing: reportedly expensive with not clear gains vs. DeepSeek; recent app release and price changes are notable.
- Google Gemini Code Assist: part of Google’s push into code-assist tooling; signals from leaked memos suggest they’re playing free-for-now play to stay competitive.
- Deep Research: a favorite for digging into ideas and turning research into artifacts (e.g., turning Turntable FM research into a 16-page PRD).
Abe Lincoln vibe and the vibe-coding spectrum#
- Abe Lincoln vibe concept: thorough prep before “doing” the coding work. Sharpen the axe first.
- Vibe coding effectiveness model (three parameters):
- Vibe code effectiveness (0-100%)
- Skill level of the person doing the work
- Project difficulty
- The takeaway: even with top-tier talent (like Andre), high-difficulty projects rarely reach 100% vibe code. Most people sit toward the left; easy projects can hit 100% with solid prep.
- Practical implication: map projects along difficulty vs. vibe-code readiness; prep-heavy tasks should push the effectiveness toward 100%.
Practical example: AI art gallery page and prompts#
- Quick data structure approach:
- Data: name, prompt, model, image file, metadata
- Use Shad CN components for UI structure; ensure consistent toast notifications
- Why it matters: small inconsistencies (like different toast libraries) derail accuracy and UX. Define a single pattern early.
- Takeaway: start with data structure and UI scaffolding, then layer in AI-driven generation with a well-defined prompt spec.
Hybrid workflow: PRD + prompt spec#
- Core idea: vibe coding plus solid research produces high-quality prompts and results.
- PRD patterns:
- Pitch format: problem, solution, sketches, customer anecdotes, rabbit holes (things to avoid), timeboxing
- Variants: PRD + technicals; PR FAQ (Amazon style)
- Human roles:
- One technical PM to draft the PRD
- One semi-technical builder to translate into prompt specs and code hooks
- From PRD to prompt spec:
- Identify files, functions, APIs, and data touched
- Create a prompt spec that maps to actual code changes
- Use external sources (GitHub snippets, OSS examples) to bootstrap
- Key practice: the “spec prompt” should orchestrate both the product aim and the technical details to reduce 80%/20% gaps.
Turntable FM as a planning example#
- Domain architecture basics:
- Users, rooms, avatars, activity data, chat, and real-time cues
- UI components and scenes:
- Room page, chat pane, scoreboard, pulsating speaker, user cards, song banners
- Data modeling notes:
- Rooms with members (arrays/foreign keys), user avatars, timestamps
- Practical tips:
- Start with a rough domain model, then map to UI components and routes
- When evaluating tech, look for OSS real-time chat patterns and reuse where sensible
- Outcome: use the PRD to drive the architecture, then fill in tech details with targeted snippets and external references.
Client memory bank workflow (active context and project brief)#
- Concept: keep context current and reusable as you iterate
- Active context: current focus or task
- Product context: overview of the project, examples, and constraints
- Progress: track what’s done and what’s next
- Project brief: living document that ties the spec prompt to real work
- Example workflow:
- Create a spec prompt (e.g., “Generate a fake PRD for live chat like Slack, include TS snippets and file tree”)
- Extract useful snippets and drop them into the project brief
- Use the brief to guide future iterations and memory recall
- Practical takeaway: evolve a single source of truth (the project brief) that feeds back into prompts and code.
Example prompt spec you can try#
- Draft prompt (conceptual):
- Generate a fake product requirements document for a Slack-like live chat
- Include TypeScript snippets, component names, and a file tree
- Sample TS scaffold (illustrative):
type PRDSnippet = {
problem: string;
solution: string;
customers: string[];
features: string[];
milestones: string[];
successMetrics: string[];
risks: string[];
integrations?: string[];
};- Use this as a starting point to populate your project brief and drive design decisions.
Quick notes on tooling and approach#
- Reading docs and code matters more than chasing a perfect one-shot prompt.
- Domain-driven scaffolding: define models first (users, rooms, avatars, etc.) before UI.
- Consider OSS patterns for real-time features instead of reinventing the wheel.
- Self-host docs and middleware tools (like Compose.io) are interesting but may be overkill if LLMs get robust enough to handle most needs.
Final tips#
- Know your stuff: read the docs, study good code, and build a strong prompt spec from real patterns you’ve seen.
- Use the PRD + technicals approach to keep scope tight and reduce derailment.
- Expect to iterate: the project brief is your living artifact that drives the memory bank workflow.
Links#
- Google Gemini - Deep Research AI tool
- Google Gemini Code Assist - AI coding assistant
- shadcn/ui - UI component framework
- Composio - Integration platform for AI agents
Transcript
I'm Parker Rex. I led product and technology for a company that did $73 million in sales at our peak and around 50 when we exited. Crazy story there. That's for a different video. But on this channel, I update you daily on building a $100,000 a month AI services company. So, we're not there, but that's where we want to go. And so I cover what's working in the field, some of the AI stuff that I'm actually using, and some hot takes. So let's jump into it. Couple things that happen. And I I actually just covered this, but yeah, news is blue. We do some strategy stuff, which is in green, and then we have actual builds that we test stuff out. Chat GBT is expensive as hell. The latest one that just came out is I mean, if you just type it in, all of Twitter's freaking out because why would it be 99% more expensive, but not that much better than Deepseek? It just doesn't make any sense. Oh, they're doing a live stream in an hour and a half. Interesting. Either way, it's really expensive. They did release a new app. So, if I have a cursor window open and I go in here, then it's going to pre-populate this because it has Oh, it looks like it needs an extension. I already have that. That's weird. But yeah, that's kind of helpful. I still use it every day. I don't know the pro version. Some other stuff that's going on that I just wanted to mention is the new Google stuff. So, let's see. Google Gemini Code Assist. Take a look at this. There was a leaked memo that came out from Google recently, which you have to think they just wanted this to go out, but it states how models that they're putting out are behind open source in the long run or they may have a lead now in certain areas. it doesn't make any sense to charge for them. So that's why you see them putting them out for free. And my favorite one is Deep Research. I use this to solve pretty much all the problems that I'm having with different ideas. So I want to make a recreation of Turntable FM if you're unfamiliar with it. It is or was a really really viral music social app in the 2010s. So I was just curious about learning that. And so I can prompt it and it'll go and do a bunch of the research and then I'd give that output of a 16page research paper inside of a product requirements document. So I think that that's pretty pretty crazy thing that's going on. And then now the beef of this video is actually going to be talking about vibe coding best practices. So everyone knows what vibe coding is if you're in this world. But one thing I think they're missing is cool. Like here's reputable reputable guy. You know, he's the king of AI. That's Andre Harpathy. And he says this vibe coding thing is sick, right? And then everyone on Twitter is not him. They're not a 1% or a 0.00001% 0001% depth. So then you have all these people that are like, "Wow, that's amazing. We should totally do that because we're going to listen to him." Well, guess what? When he's talking to the model, it's going to be really specific. Like when he's going in and he's saying, "Oh, make, you know, this, this, and that." These three things that he says might take the normie over here like maybe 10,000 different requests to get to that. Like that's how good he is. So I think that's a big mistake. I've found it as someone who's been coding non-stop for the last few years that things go off the rails really quickly. I think if there's a spectrum on the vibe coding effectiveness scale, it is in opposite to the difficulty of the project, right? And I think that's pretty obvious. So like let's say vibe code effectiveness. There's probably three parameters here. So you'd have like the effectiveness of the of the of the vibe code. So let's call it vibe code percent out of 100. 100 meaning like this thing is just working. Then you have the skill level person who's doing the thing. And then you have the difficulty of the project. And these second and third one really go hand in hand. I don't know how I'd map this, but let's go with a uh one like this. So on this side, this would be easy projects. These would be hard projects. And this would be uh vibe code is at 100%. Then vibe is at 0%. You map this out. I mean, Andre is here, right? He can he can get away with doing it, but I think everyone else is is if they're trying to do something hard, they'll never be there. Like, you will not This just doesn't exist for the normie. But everyone can exist over here if you're decent. And that's what I found yesterday where I wanted to share some photos that I've made. And so I made a quick page just called AI art. Really easy, right? Has a couple things in it. But I wanted to give away the prompts or share the prompts that I made with these photos. And so doing that was really easy because I can already do it myself. I know how to do this. It's really simple. You need to start with the structure of the data. So we have the name of the piece, we have the prompt that's associated, we have the model, then we have the actual image file, we have a couple different components that are already done for us with Shad CN. So because I know how to do that and I know how to do sorting, I know how to do filtering, I can say the thing that will oneshot this. And this was a oneshot. This created the page. It created the TS data file just so that they were separate. Then it made the modal in line and then it did the toast so that appears because if it didn't know exactly what to say, it wouldn't be right. That's just how it works. Like even little things like on that example, well guess what? If you don't say exactly how to do it, then there's three different types of toasts that it might try to use. it might not even know that you have um shad cien. So it's going to go and it's going to try to use this I think it's called suner toast or it might use react hot toast and then you have all these different toast and then when you try to add a toast in the future and you don't know how it works well guess what it's because you have like eight different versions. So that's going to play into our next topic, which is how do you get the most out of these models by having some sort of hybrid? Like you can still vibe code, but it has to be well researched. And that's what I call Abe Lincoln vibe. Abe Lincoln vibe. And why he's important is because he has this classic tale where if you have eight hours to do something and you do six hours prep. In his case, it was, you know, he had an axe and he's talking about chopping down a tree. He had eight hours. He'd spend six of those hours doing the sharpening of it. That's what you need to do. You need to sharpen the skills and you need to end up having an artifact with those sharp skills in the form of a prompt. spec. This is a little bit different than a PRD. So, a PRD usually it's different at every company. The way I always did it was in the pitch format. So it's, you know, problem solution and then, you know, you're including maybe some sketches in there, maybe some anecdotes about customers saying stuff to you or like basically all the things that are associated with this. You have uh rabbit holes, so areas to avoid. This one's really helpful for models because 3.7 by anthropic, if you have an issue with an image, it doesn't find the image and it'll go and try to make a solution that will generate an image for you. Whoa, whoa, whoa. That's not that's not it. You have the rabbit holes and this is like basically like the most important parts of the pitch. And then for humans doing it, you'd have a time box. So, it's the constraint and then yeah, so that's one version of a PRD. A different one might look like a six- page uh PR FAQ. This is an Amazon thing. Much more involved. You're not going to do that in this case, but it doesn't get into the actual snippets. It usually doesn't name files specific to the thing. That would be second step. Like the way I like to think about all of these any AI workflow is based on a process that you've done as a person already. So you'd usually have this PRD that's written by someone that's kind of technical, technical product manager and then that would meet you would go from a oneperson thing to a two-person thing where now you have a guy who is technical and then you have a guy who's semi-technical so they're not really technical and then you actually make some sort of prompt spec is the term here but that would be like the PRD plus technical and it's custom to the actual project you're working on. So if you have a codebase and you come in with this fancy idea, then you actually need to go through and see the files it's going to touch. So you're like, "Oh, it touches this. Oh, it touches this function." And you're listing off these things. So you might have like functions in there. There might be APIs. There might be uh database things that need to change. There's all these little things that as a non-technical person you don't know about. There might be things that you tap one domino, it knocks down seven. There might be things in the PRD that aren't required to solve the problem, which is the most important part that you can just get rid of because that would be the best if you don't need it. So, this is really what you're looking for. It's the PRD plus the technicals, which goes back to the vibe coder needing to know the basics because in order to get a high quality prompt, everyone's like scratching their neck trying to get the, you know, one shot, right? It's got like a halo around it for the the one shot. In order to get that, you have to have had done the thing before and then you can do it. then you can have AI take care of the task for you. Otherwise, you'll always be at 80%. Oops. You always be at 80%. You'll be looking for this other 20%. You can look at this and say, "Oh, it's, you know, the parable or the Pareto principle, but you want to be at 100%." And the way that you do that is you read the docs, you understand it. You get good at reading. You don't need to know how to write it manually. But if you're reading a lot of good high quality code, then you'll learn exactly how to do it. I learned that yesterday when I was actually trying to build the social music thing. It was like turntable FM. There were a couple steps in there, right? It's like, okay, I need to scaffold the project. I need to do the domain based architecture which if you're unfamiliar that's when you're writing out what the models would be because the models dictate what the product will do. So in this case you know you have users and what's in there. You have maybe name, it's a string. And you have the rooms they're part of. That might be like a string array. You have the avatar, which would be a URL. So that'd be another string. You have created at, you have modified at or updated at, whatever. You have a bunch of these things and you're just kind of scaffolding out what this is going to look like. So you'd have rooms, you'd have name string, you'd have members, maybe that's an array of or that would be like a foreign key. So maybe that's actually going back to users. And you go through this and then that would be another step, right? But you wouldn't know that if you didn't do the task before. After that, you know, I'm going through and I'm like, okay, well, what would be needed on turntable FM? Well, I know that there's probably a couple different scenes, right? So, you need like I know we need the off stuff, right? So, what are we going to use for that? We need like login and and sign up. How do we get them in the door really fast? So, that might be the next thing that I'm thinking about the O. We probably need some sort of like component structure. So, what are the different components needed? What are the different scenes? Because this is going to be, you know, you'd have your rooms, have your I guess you could just call this scenes slash pages, like actual interfaces, right? Like what are the UI things that are going to be shown? You'd have the rooms. You'd have settings. You might have chat. Chat might not be its own route. You might have DMs. But then within those, you're like, "Okay, well, what what goes into the room?" Well, if we looked at an image of it, I could pull it up, but I'm not going to. And there you have like a fake looking speaker. You've got a bunch of people that are behind some turntables. Got the chat on the right. So, people are yapping. Got turntables. You've got a I think there's like a scoreboard. So, that'd be a component. This would obviously be the room page slash UI. You'd have, let's see, this would be its own thing. So, we'd call it maybe like pulsating speaker, scoreboard. We have the notion of a user, which and it would have all this stuff, right? Like, oh, they have an avatar. We need to show their face. We have some of their stats. So, maybe like as I'm looking at this, I'm like, oh, maybe they have like karma or like score or something. What else? This scoreboard. Yeah, the maybe like this would be like song banner. Then are we going to store the songs in here? I don't know. But it's going through all these steps and then thinking it through and then you end up plusing up whatever this pitch was. And this is I, you know, you could do it totally manually. Don't recommend doing that. I think this part you would do manually, but then actually making this is the sauce. So you can use AI to bring all that together. But then you'd go through and if you had an existing project be the same thing. Be looking at the existing screens, the existing domain architecture, the existing components. And then you'd be writing out what the change requests are. And then what you end up with for something new, you might do a little like googling. You might go on GitHub and and try to find like, well, okay, for this chat thing, we could probably use this subbase real time tech. And I found an example of someone that recreated Slack. So we can use that OSS project. You'll grab a snippet out of there. So then when you go back into your original PRD, which is just the idea and just the concept, then you're coming back and you're filling in basically like techy stuff, which will make uh blue. So then you're coming in and you're putting in the snippets. you're plusing it up. So then you end up with this thing which is that spec prompt what I'm calling it. And then in practice and these will be in future videos in practice you would be using the client memory bank workflow where you have active context you have a product context. So active context basically says like what's the current focus in this case that's old so I wouldn't do that. The product context gives examples or basically a highle overview of everything going on in here. Progress gets updated when you do stuff. I can delete that. Project brief. This is where you'd put the thing that you're actively working on. Right? So your spec prompt would go in here. Let's say I have example one ND. Generate a fake product requirements document for making live chat that uh mimics Slack. Include TypeScript snippets, component names, and file tree if possible. So you'd end up with you'd end up with this document and then you'd actually just take chunks of it and then move that into the project brief because the client workflow is based on looking at that. So you might have like 10 features in here and you might just pick this one off and you would have snippets in there. didn't do it. But you pick that off and you drop it into your project brief. You hit okay, go. I think that that's the best way possible to do this. I'll be doing this in future videos to show you in practice, but I just wanted to cover that. So, yeah, you need to know your stuff. You need to know how to read the docs. You need to know how to make a really specific one. We already covered this PRD pattern. So, I think that that's the move. This is backed by me having written tons of these over the time of being a product manager. And then also kind of taking the last couple years of dev experience and blending the two. Uh what else? Before we go, this is a shorter video today because I need to get going on the day, but the self-host docs. I was going to maybe cover this and uh Composeio. Let's take a look at Composeio. This is something I was interested in. The composio integration platform powers agents and LLMs to connect tool calling. I feel like a lot of these tools are not going to exist. No offense to Compose, but they seem I was making this joke with a friend yesterday, been a a developer for way longer than me. It seems like a lot of the frameworks and the tools that exist, the real question is like why do they exist? Because I just feel like this wouldn't it's kind of just it's middleware that if the foundation models do a good enough job, they won't need to exist. And I, you know, I want what's best. But I even if I look at this and I see like a calendar agent like this isn't a lot of code that you have to add and it's just a wrapper on top of a wrapper. So also why don't you have Typescript? That's all I got for today. This was a shorter style video. If you guys have any questions about how I'm building different AI services, what stuff I'm providing, make sure you reach out. and uh I'll answer those questions. If not, I'll see you tomorrow.