Y Combinator Startup Podcast - How To Get The Most Out Of Vibe Coding | Startup School

Episode Date: April 25, 2025

AI can't yet one-shot an entire product—but with the rise of vibe coding, it's getting close. YC's Tom Blomfield has spent the last month building side projects with tools like Claude Code, Windsurf, and Aqua, seeing just how far you can push modern LLMs. From writing full-stack apps to debugging with a single paste of an error message, AI is becoming a legit collaborator in the dev process. This is a playbook for anyone who wants to get the most out of vibe coding and build faster.

Hi, I'm Tom and I'm a partner here at YC. For the last month, I've been experimenting vibe coding, a couple of side projects, and I found not only is it remarkably good, but it's also a practice you can get measurally better at if you're open to tinkering and picking up best practices. In this video, I want to share some ways you can get great results when vibe coding. It's kind of like prompt engineering from a year or two ago. People were discovering new stuff every week and posting about it on some sort of. social media. The best techniques are the same techniques that a professional software engineer

might use. And some people are like, well, that's not vibe coding, is it? You're now just software engineering. I kind of think that's beside the point. We're trying to use these tools to get the best results. And the YC SpringBatch just kicked off a couple of weeks ago. And before I give you my advice for vibe coding, let's hear from the founders on the tips they're using to get the best at the AI tools today. If you get stuck in a place where the AI ID can't implement or can't debug something and it's just stuck in a loop, sometimes going to the LLM's website, like literally to the UI and just pacing in your code and asking the same question can get you a result that for whatever reason the ID couldn't get to. And you can solve your problem that way.

So I'd say like just load up both cursor and WinSurf on the same project. Curser, it's a bit faster. So you can do a lot of like the front end, like a little more like full stacky, like link the front end to the back end. WinServe thinks for a bit longer. I used to just be like scrolling on my phone while I type, build this agent or like, you know, like, modify this prompt and I'll just like scroll, fix, scroll, or like, you know, paste an error. Now, while I'm waiting for a windsurf to think, I can go on cursor and like, you know, just start updating the front end. Sometimes I'll load up both at the same time and like have like the same context. Maybe if I'm trying to update the front end, I'll give it, like, style it in like the style of that file. And then I'll just press enter for both.

And then they'll both basically give me like slightly different iterations of the same front end. and I'll just pick which one I like better. My advice would be to think of the AI as a different kind of programming language and vibe coding as being a different, a new type of programming language. And so instead of programming with code, you're programming with language.

And because of that, you kind of have to provide a lot of the necessary context and information in a very detailed way if you want to get good results. I usually start vibe coding in the reverse direction. That is first starting from the test cases. I handcraft my test. test cases. I don't use any LLMs to write my test cases. And once it is done, I have strong

guardrills that my LLMs can follow for generating the code, right? And then they can freely generate the code that they want to generate. And once I see those green flags on my test cases, the job is done. I don't need to micromanage my code basis. I just take overview about the modularity of the code. Other than that, it's fine. Yeah, I think it's very important to first spend an unreasonable amount of time in like a pure LLM to build out like the scope and the actual architecture of what you're trying to build before offloading that to cursor or any other kind of coding tool and let it adjust like free run in the code page, just random making up stuff that doesn't really work. So make sure you understand what the actual goal of what you're

building is. My advice would be to really monitor whether the LLM is falling into a rabbit hole when that's answering your question. And if you notice that it just keeps regenerating code and it looks kind of funky, it's not really able to figure it out. If you're having to find yourself copying, pasting error messages all the time, it probably means something's gone awry and you should take a step back, even prompt the LM and say, hey, let's take a step back and try to examine basically why it's failing. Is it because you haven't provided enough context for the LM to be able to figure it out? Or have you just gotten unlucky and it's unable to do your request? The overarching theme here is to make the LLM follow the processes that a good professional

software developer would use. So let's dive in and explore some of the best vibe coding advice I've seen. First, where to start? If you've never written any code before, I would probably go for a tool like Replit or Lovable. They give you an easy-to-use visual interface and it's a great way to try out new U.S. directly in code. Many product managers and designers are actually going straight to implementation of a new idea in code rather than designing mock-ups in something like Figma, just because it's so quick. But when I tried this, I was impressed with the UIs, but tools like Lovable started to struggle

when I wanted to more precisely modify back-end logic rather than just pure UI changes. I'd change a button over here and the back-end logic would bizarrely change. So if you've written code before, even if you're a little bit rusty like me, you can probably leap straight to tools like windsurf, cursor or Claude code. Once you've picked the tool you want to use, the first step is not to dive in and write code. Instead, I would work with the LLM to write a comprehensive plan. Put that in a markdown file inside your project folder and keep referring back to it. This is a plan that you develop with the AI and you sort of step through while you're implementing the project rather than trying to one-shot the whole thing. And so what I do, after you've created the first draft of

this plan, go through it, delete or remove things that you don't like. You might mark certain features explicitly as won't do too complicated. And you might also like to keep a section of ideas for later, you know, to tell the LLM, look, I consider this, but it's out of scope for now. Once you've got that plan, work with the LLM to implement it section by section. And explicitly say, let's just do section two right now. Then you check the LLM. that it works, you run your tests and you Git commit, then have the AI go back to your plan and mark Section 2 as complete. I probably wouldn't expect the models to one-shot entire products yet, especially if they're complicated. I prefer to do this piece by piece and make sure I have a

working implementation of each step and crucially commit it to Git so that you can revert if things go wrong on the next step. But honestly, this advice might change in the next two or three months. The models are getting better so quickly that it's hard to say where we're going to be in the near future. My next tip is to use version control. Version control is your friend. Use Git religiously. I know the tools have these kind of revert sort of functionality. I don't trust them yet.

So I always make sure I'm starting with a kind of a clean Git slate before I start a new feature so that I can revert to a known working version if the AI goes off on a vision quest. So don't be afraid to Git reset head hard. if it's not working, and just roll the dice again. I found I had bad results if I'm like prompting the AI multiple times to try to get something working. It tends to accumulate layers and layers and layers of bad code rather than like really understanding the root cause.

You might go and try four or five, six different prompts and you finally get the solution. I'd actually just take that solution, get reset, and then feed that solution into the AI on a clean code base so you can implement that clean solution without layers and layers of craft. The next thing you should do is write tests. Well, get your LLM to write tests for you. They're pretty good at this, although they often default to writing very low level, like unit tests. I prefer to keep these tests super high level. Basically, you want to simulate someone clicking through the site or the app and ensure

that the features are working end-to-end rather than testing functions on a kind of of unit basis. And so make sure you write high-level integration tests before you move on to the next feature. LLMs have a bad habit of making unnecessary changes to unrelated logic. So you tell it to fix this thing over there, and it just changes some logic over here for really no reason at all. And so having these test suites in place, catch these regressions early, it will identify when the LLM has gone off and made unnecessary changes so that you can get reset and start again. Keep in mind, LLMs aren't just for coding. I use them for a lot of non-coding work when I'm building these kind of side projects.

For example, I had Claude Sonnet 3.7, configure my DNS servers, which is always a task I hated, and set up Heroku hosting via a command line tool. It was a DevOps engineer for me and accelerated my progress, like 10X. I also used chat GPT to create an image for my site's favicon, that little icon that appears at the top of the browser window, and then Claude took that image and wrote a quick throwaway script to resize it into the six different sizes and formats I needed for favicon's across all different platforms. So the AI is now my designer as well. Okay, so now let's look at bug fixes.

The first thing I do when I encounter any bug is just copy paste the error message straight back into the LLM. It might be from your server log files or the JavaScript console in the browser. often this error message is enough for the AI to identify and fix a problem. You don't even need to explain what's going wrong or what you think's going wrong. Simply the error message is enough. It's so powerful that pretty soon I actually expect all the major coding tools to be able to ingest these errors without humans having to copy paste. If you think about it, our value being the copy paste machine is kind of weird, right?

We're leaving the thinking to the LLM. But I think that copy pasting is going to go out the window and these LLM tools are going to be able to tail logs or, you know, spin up a headless browser and inspect the kind of JavaScript errors. With more complex bugs, you can ask the LLM to think through three or four possible causes before writing any code. After each failed attempt at fixing the bug, I would Git reset and start again, again, so you're not accumulating layers and layers of craft. Don't make multiple attempts at bug fixes without resetting because the LLM just adds more layers of crap. Get reset, start again. And add logging. Logging is your friend. If in doubt, if it's not working, switch models.

Maybe it's Claude Sonic 3.7. Maybe it's one of the open AI models. Maybe it's Gemini. I often find that different models succeed where the others fail. And if you do eventually find the source of a gnarly bug, I would just reset all of the changes and then give the LLM very specific instructions on how to fix that precise bug on a clean code base to avoid this like layers. and layers of junk code accumulating. Next tip is to write instructions for the LLM. Put these instructions in, whether it's cursor rules, windsurf rules,

clawed markdown file. Each tool has a slightly different naming convention. But I know founders who've written hundreds of lines of instructions for their AI coding agent, it makes them way, way more effective. There's tons of advice online about what to put in these instruction files.

I'll let you go and find that on your own. Okay, let's talk about documentation I still find that pointing these agents at online web documentation is a little bit patchy still. Some people are suggesting using an MCP server to access this documentation, which works for some people. It seems like overkill to me. So I'll often just download all of the documentation for a given set of APIs and put them in a sub-directory of my working folder so the LLM can access them locally. And then in my instructions, I'll say, go and read the docs before you implement this. this thing, and it's often much more accurate. A side note to remember, you can use the LLM as a teacher,

especially for people who are less familiar with the coding language. You might implement something and then get the AI to walk through that implementation line by line and explain it to you. It's a great way to learn new technologies. It's much better than scrolling stack overflow like we all used to do. Now let's look at more complex functionality. If you're working on a new piece of functionality a new feature that's more complex than you'd normally trust the AI to implement. I would do it as a standalone project in a totally clean code base. Get a small reference implementation working without the complication of your existing project or even download a reference implementation if someone's written one and posted it on GitHub. Then you point your LLM at the implementation and tell it to

follow that while re-implementing it inside your larger code base. It actually works surprisingly well. Remember, small files and modularity are your friend. This is true for human coders as well. I think we might see a shift towards more modular or service-based architecture, where the LLM has clear API boundaries that it can work within while maintaining a consistent external interface, rather than these huge mono-repoes with massive interdependencies. These are hard for both humans and LLMs.

It's just not clear if a change in one place is going to impact another kind. part of the code base. And so having this modular architecture with a consistent external API means you can change the internals as long as the external interface in the test still pass, you're probably good. Now a note on choosing the right tech stack. I chose to build my project partially in Rubion Rails, mostly because I was familiar with it from when I used to be a professional developer, but I was blown away by the AI's performance, especially when it was writing Rubium Rails code. And I think this is because Rails is a 20-year-old framework with a ton of well-established conventions. A lot of Rails code bases look very, very similar, and it's obvious to an experienced

Ruby on Rails developer where a specific piece of functionality should live, or the right Rails way of achieving a certain outcome. That means there's a ton of pretty consistent, high-quality training data for Rails codebases online. I've had other friends have less success, with languages like Rust or Elixir, where there's just not as much training data online. But who knows, that might change very soon. Okay, next bit of advice. Use screenshots. You can copy and paste screenshots into most coding agents these days,

and it's very useful either to demonstrate a bug in the UI implementation that you can see, or to pull in design inspiration from another site that you might want to use in your project. voice is another really cool way to interact with these tools. I use Aqua, a YC company, and basically I can just talk at my computer and Aqua transcribes whatever I'm saying into the tool I'm using. I'm switching a lot between windsurf and Claude Code at the moment, but with Aqua, I can effectively input instructions at 140 words per minute, which is about double what I can type. And the AI is so tolerant of minor grammar and punctuation mistakes that it honestly doesn't matter if the transcription's not perfect. I actually wrote this entire talk with

Aqua. Next, make sure to refactor frequently. When you've got the code working and crucially the tests implemented, you can refactor at will, knowing that your tests are going to catch any regressions. You can even ask the LLM to identify parts of your code base that seem repetitive or might be good candidates for refactoring. And again, this is just a tip that any professional software developer would follow. You don't have files that are thousands of lines long. You keep them small and modular. It makes it much easier for both humans and LLMs to understand what's going on. Finally, keep experimenting. It seems like the state of the art of this stuff changes week by week. I try every new model release to see which performs better in each different scenario. Some are better

at debugging or long-term planning or implementing features or refactoring. For example, at the moment, Gem and I seems best for whole code-based indexing and coming up with implementation plan, while Sonnet 3.7, to me at least, seems like the leading contender to actually implement the code changes. I tried GPT 4.1 just a couple of days ago, and honestly I wasn't yet as impressed. It just came back with me with too many questions and actually got the implementation wrong too many times. But I'll try it again next week, and I'm sure things will have changed again. Thanks for watching, and I'd love it if you have tips or tricks for getting the most out of these models, please share them in the comments below.