How To Get The Most Out Of Vibe Coding | Startup School

Summary

Highlights

• Discover how AI can make coding feel effortless and productive! ✨
• Tom shares his journey of using AI for side projects and the learning curve involved. 🔍
• AI tools like Replet and Lovable offer intuitive UI experiences for coders at all levels! 👩‍💻
• Version control and modularity are crucial in maintaining clean and effective codebases. 📂
• Remember to treat AI like a development partner—craft plans with it, not just code! 🤝
• Frequent testing and resetting keep the codebase clean and avoid clutter! 📊

Key Takeaways

• Use AI tools like Vibe Coding to enhance coding productivity! 🤖
• AI is not just for coding; it's your personal DevOps engineer too! 🚀
• Version control is a coder's best friend; use it religiously! 🔄
• Start by building a comprehensive plan with the AI, not diving into code! 📝
• Embrace modularity - it helps both AI and human coders alike! 🛠
• Experimentation is key as AI models rapidly evolve! 🔬

Overview

Chapters

• 00:00 - 00:30: Introduction to Vibe Coding In the chapter titled 'Introduction to Vibe Coding', Tom, a partner at YC, shares his experiences experimenting with vibe coding over the past month. He has discovered that not only is vibe coding remarkably effective, but one can also improve their skills through practice and adopting best practices. Tom aims to share methods for achieving excellent results in vibe coding.
• 00:30 - 01:00: Comparison to Prompt Engineering The chapter discusses the evolution of 'Vibe Coding' and its comparison to prompt engineering from a couple of years ago, highlighting that discoveries and discussions around techniques were frequent on social media. It underscores that the most effective techniques in Vibe Coding mirror those used by professional software engineers, addressing a critique that equates these practices to typical software engineering. Despite this critique, the focus remains on leveraging tools to achieve optimal results. Additionally, the chapter mentions the initiation of the YC Spring Batch, preluding some advice for Vibe Coding.
• 01:00 - 01:30: Founders Share AI Tool Tips In the chapter 'Founders Share AI Tool Tips,' the founders discuss strategies for effectively utilizing AI tools. They specifically provide advice for situations where the AI development environment (IDE) struggles with implementing or debugging code and seems to get stuck. A recommended tip is to visit the language model's (LLM's) website and directly engage with the user interface by pasting the problematic code and posing the same question, as this might produce a solution that the original IDE couldn't provide. Furthermore, they suggest running both Cursor and Windsurf AI tools on the same project to optimize performance and efficiency. Cursor is noted for its speed, making it suitable for lightweight frontend development and potentially full-stack projects.
• 01:30 - 02:00: AI Tools - Cursor and Windsurf The chapter discusses the integration and concurrent use of AI tools, 'Cursor' and 'Windsurf', for software development. The narrator describes how they balance waiting for 'Windsurf' to process by working on the front end with 'Cursor', sometimes running both tools simultaneously. This allows them to efficiently manage time and maintain context by loading the same environment, enabling seamless updates and styling in the development process.
• 02:00 - 02:30: Vibe Coding as a New Programming Language The chapter explores the concept of 'Vibe Coding' as a new form of programming language. It suggests that instead of the traditional coding with syntax, programming can be done through natural language, requiring detailed context and information to guide AI effectively. Vibe Coding emphasizes selecting from different iterations by intuition or 'vibe' and fostering communication with AI as if communicating in a new programming language. The process is detailed, possibly starting in reverse, focusing on end results before coding.
• 02:30 - 03:00: Focus on Test Cases in Vibe Coding The chapter focuses on the process of creating test cases in Vibe Coding, emphasizing manual crafting of test cases without the use of Language Learning Models (LLMs). Once test cases are set with strong guard rules, LLMs can then generate code freely within these constraints. Upon passing all test cases, the development process is considered complete, and the focus shifts to ensuring code modularity rather than micromanagement.
• 03:00 - 03:30: LLMs in Coding Workflow The chapter discusses the integration of large language models (LLMs) in the coding workflow. It highlights the importance of defining the architecture and scope of a project before relying solely on LLMs or coding tools like Cursor. Caution is advised against allowing these models to operate unchecked within a codebase as they might produce unreliable results. The key advice is to monitor the LLM's performance closely to ensure it aligns with the project goals and to be wary of it generating random, non-functional code. The chapter emphasizes the importance of understanding the end goal to prevent the LLM from going off course.
• 03:30 - 04:00: Reset and Version Control This chapter focuses on the importance of reset and version control in coding. If code behaves unexpectedly or you're frequently copying and pasting error messages, it's a sign that something is wrong. It's important to step back and reassess the situation. The chapter suggests using language models (LLMs) to analyze and understand the root cause of a problem, questioning if insufficient context or other factors are leading to the current issues. The key takeaway is to maintain control and clarity in your coding process by stepping back and evaluating when necessary.
• 04:00 - 04:30: Use of LLMs Beyond Coding The chapter discusses the application of Large Language Models (LLMs) beyond traditional coding tasks. It highlights how LLMs adopt processes akin to those used by proficient software developers.
• 04:30 - 05:00: Bug Fixing with LLMs Chapter 'Bug Fixing with LLMs' explores the practical implementation of new ideas in code, preferring it over mock-ups due to the speed and efficiency of available tools. However, it highlights the struggle with current tools like Lovable, which falter on backend logic modifications. The narrative suggests that if one has previous coding experience, even slightly rusty, they can transition directly to more robust tools like Windsurf Cursor or Claude Code for precise backend changes.
• 05:00 - 05:30: Writing Instructions for LLMs The chapter emphasizes the importance of planning before jumping into writing code when using Language Learning Models (LLMs). It suggests collaborating with the AI to develop a comprehensive plan and documenting it in a markdown file within the project folder. This plan serves as a reference throughout the project implementation. After drafting the initial plan, it recommends reviewing and refining it by removing unnecessary elements.
• 05:30 - 06:00: LLMs and Documentation The chapter discusses how to work with Large Language Models (LLMs) for implementing plans and documenting processes. It suggests marking certain features as out of scope or as ideas for later if they're too complex. The strategy involves working with the LLM to implement one section at a time, testing the functionality, making a commit, and then marking that section as complete in the plan.
• 06:00 - 06:30: Using LLMs as a Learning Tool The chapter discusses the use of large language models (LLMs) as learning tools. The speaker prefers to tackle complex tasks one step at a time, ensuring each step works before committing it to version control systems like Git, allowing for easy reversion if needed. The rapid advancement of models is noted, suggesting that strategies might soon evolve. Emphasizing the importance of version control, the speaker encourages the use of Git to manage changes effectively.
• 06:30 - 07:00: Modular Architecture and LLMs This chapter delves into the aspect of ensuring a clean workflow when dealing with modular architectures and large language models (LLMs). It discusses the importance of starting with a clean repository before initiating new features. This approach is crucial to allow easy reversion to a stable version if unpredictable issues arise when leveraging AI tools. The speaker highlights a personal strategy, indicating reluctance towards relying solely on tools that revert changes, instead preferring to manually ensure a clean slate using known Git commands. Additionally, there’s an emphasis on avoiding repetitive prompting of AI, as it may yield undesirable, cumulative complexities.
• 07:00 - 07:30: Choosing the Right Tech Stack This chapter discusses the importance of a clean and efficient tech stack in software development. The focus is on avoiding layers of poor code by understanding the underlying issues, experimenting with multiple solutions, and ultimately feeding the best solution into the AI or LLM (Large Language Model) on a fresh codebase. It emphasizes the need for writing tests or using LLMs to generate tests, highlighting their proficiency in this area.
• 07:30 - 08:00: Interactive Tools - Screenshots and Voice This chapter discusses the importance of writing high-level integration tests instead of low-level unit tests. The focus is on simulating a user's interaction with a site or app to ensure end-to-end functionality of features rather than testing individual functions. There is also a caution about large language models (LLMs) inadvertently making changes to unrelated logic when asked to fix specific issues.
• 08:00 - 08:30: Refactoring with LLMs The chapter discusses the use of Large Language Models (LLMs) in refactoring code and their role in identifying unnecessary changes made to the code. It highlights the importance of having test suites to catch regressions and maintain code quality. Beyond coding, LLMs are versatile tools that can assist in non-coding tasks, using the personal example of configuring DNS servers and setting up Heroku hosting with Claude Sonet 3.7.
• 08:30 - 09:00: State of LLMs and Continuous Learning The chapter titled 'State of LLMs and Continuous Learning' discusses personal experiences with AI tools like a command line tool that significantly boosted the productivity of a DevOps engineer. It highlights the utility of Chat GPT in generating creative content, such as designing a favicon for a website. Additionally, Claude, another AI, is used for adapting images into various needed formats, showcasing the transformative role of AI in various creative and technical tasks. The narrative also sets the stage for discussing bug fixes.
• 09:00 - 09:30: Outro and Call for Community Tips The chapter discusses the effective method of handling bugs by simply copying and pasting error messages into a Language Learning Model (LLM). These messages can come from server log files or the JavaScript console in the browser. It's emphasized that these error messages are often sufficient for the AI to identify and address the problem, without any need for additional explanation from the user. The method is highlighted for its power and efficiency, and it's suggested that in the future, major coding tools may automatically process these errors without human intervention.

How To Get The Most Out Of Vibe Coding | Startup School Transcription

• 00:00 - 00:30 [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
• 00:30 - 01:00 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
• 01:00 - 01:30 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
• 01:30 - 02:00 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
• 02:00 - 02:30 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
• 02:30 - 03:00 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
• 03:00 - 03:30 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
• 03:30 - 04:00 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
• 04:00 - 04:30 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
• 04:30 - 05:00 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
• 05:00 - 05:30 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
• 05:30 - 06:00 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
• 06:00 - 06:30 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
• 06:30 - 07:00 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
• 07:00 - 07:30 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
• 07:30 - 08:00 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
• 08:00 - 08:30 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
• 08:30 - 09:00 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
• 09:00 - 09:30 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
• 09:30 - 10:00 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
• 10:00 - 10:30 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
• 10:30 - 11:00 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
• 11:00 - 11:30 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
• 11:30 - 12:00 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
• 12:00 - 12:30 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
• 12:30 - 13:00 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
• 13:00 - 13:30 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
• 13:30 - 14:00 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
• 14:00 - 14:30 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
• 14:30 - 15:00 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
• 15:00 - 15:30 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
• 15:30 - 16:00 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
• 16:00 - 16:30 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
• 16:30 - 17:00 [Music]