Mastering Vibe Coding: Tips and Techniques for Effective AI Programming

[Music] 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 measurably 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 uh prompt engineering from

a year or two ago. People were discovering new stuff every week and posting about it on social media. The

best techniques are the same techniques that a professional software engineer might use. And some people like, well,

that's not vibe coding, is it? You're now just software engineering. I I I kind of think that's beside the point.

We're trying to use these tools to get the best results. And the YC Spring Batch 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 out of 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

pasting in your code and asking the same question can get you a result that for whatever reason the ID like couldn't get

to and you can solve your problem that way. So I'd say like just load up both cursor and windsurf on the same project.

Um cursor 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. Windsurf 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 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 uh winds surf to think I can go on cursor and like you know start

updating the front end. Uh, 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 uh think of the AI as a different kind of

programming language and vibe coding as being a different um a new type of programming language. And so instead of

programming with code, you're programming with language. And uh because of that you kind of have to

provide a lot of the necessary context and uh information in a very detailed way if you want to get good results. I

usually start wipe coding in the reverse direction that is first starting from the test cases. I handcraft my test

cases. I don't use any LLMs to write my test cases and once it is done I have strong guard rules that my LLMs can uh

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 bases. I just I just

uh take overview about the modularity of the code. Other than that, it's fine. Yeah, I think it's very important to

first spend like unreasonable amount of time uh 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 uh and

let it just like free run in the codebase just random making up stuff that doesn't really work. Um 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 it'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 copy and

pasting error messages all the time, it probably means something's gone uh ary and you should take a step back, even

prompt the LLM and say, "Hey, you know, let's take a step back and try to examine basically why it's failing. Is

it a, you know, 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 Replet or Lovable. They give you an easy to use visual interface and it's a great way to try out new UIs

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 backend

logic rather than just pure UI changes. I'd change a button over here and the backend 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 oneshot the whole thing. And so what I'd 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

that it works. You run your tests and you get commit. Then have the AI go back to your plan and mark section two as

complete. I probably wouldn't expect the models to oneshot 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 if things go wrong on the the next step. But honestly, this advice

might change in the next 2 or 3 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 get 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 and try four, 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 codebase so you can implement that

clean solution without layers and layers of of craft. The next thing you should do is write tests or 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. uh basically you want to simulate someone clicking through the the site or

the app and ensure that the features are working end to end rather than testing uh functions on a kind of unit basis and

so make sure you write highlevel 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 will identify when the LLM has 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 uh Claude Sonet 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 a um an image for my site's favicon, that little icon that appears

at the top of the 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 favicons 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 copypaste machine is is uh kind of

weird, right? We're like we're we're leaving the thinking to LLM. But I think that copyping is going to go out the

window and these LLM tools are going to be able to tail logs or you know um spin up a headless browser and inspect the

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 get reset and start again again so

you're not accumulating layers and layers of crust. 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 um Sonic 3.7, maybe it's one of the OpenAI models,

maybe it's Gemini. I often find that um 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 um 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 of junk code

accumulating. Next tip is to write instructions for the LLM. Put these instructions in whether it's cursor

rules, windsurf rules, claw markdown file. Each tool has a slightly different naming convention. But I know founders

who've written hundreds of lines of instructions for uh their AI coding agent and it makes them way 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. I mean, some people are suggesting uh using an MCP server to

access this documentation, which works for some people. Uh 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 subdirectory 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 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 uh we all used to do. Now, let's look at more

complex functionality. If you're working on a 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 codebase. Get a small

reference implementation working without the the complication of your existing project or even download a reference

implementation if someone's written one and posted on GitHub. Then you point to your LLM at the implementation and tell

it to follow that while reimplementing it inside your larger codebase. 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 uh monor repos 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 part part of the codebase. And so having this this modern 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 text stack. I chose to build my project partially in Ruby on Rails mostly

because I was familiar with it from when I used to um be a professional developer. But I was blown away by the

AI's performance especially when it was writing uh Rubon Rails code. And I think this is because Rails is a 20-year-old

framework with a ton of wellestablished 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 highquality training

data for Rails code bases 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 uh 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 Windinsurf and Clawude 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 codebase 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 um 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, Gemini seems best for whole codebase indexing and coming up with implementation plans,

while Sonet 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 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. [Music]