Vibe Coding Tutorial and Best Practices (Cursor / Windsurf)
What this covers
Matthew Berman walks through his complete workflow for vibe coding—using AI agents in Cursor and Windsurf to generate code with minimal hands-on writing. The video distills practices accumulated from months of iterative development, centering on a counterintuitive claim: the model choice matters far less than the discipline you impose on it. Berman covers the full stack of scaffolding: writing detailed specifications upfront, constructing explicit rules files to constrain the agent's behavior, keeping requests narrow, testing aggressively, committing frequently, and managing context window bloat through chat hygiene. The underlying theme is that AI agents have consistent failure modes—duplicating code, swapping in unapproved technologies, silently falling back to mock data—and that these are predictable enough to guard against.
The substance covers the agent's specific weak points and the countermeasures for each. Berman argues that context size directly degrades performance and that environment separation (dev, test, production) must be enforced explicitly because agents naturally blur these boundaries. He demonstrates why end-to-end testing beats unit testing for agentic workflows, yet warns that agents often hack tests to pass rather than fix the root cause. He explains the case for narrow, tested, frequently-committed changes over broad open-ended requests—and the parallel possibility of running multiple agent windows on different branches to parallelize work. The video also touches on practical choices: why popular, well-documented technology stacks outperform nascent ones, how to handle refactoring without cascading breakage, and when "YOLO mode" (auto-executing everything) is acceptable versus dangerous. The framing is pragmatic rather than aspirational; Berman presents these as lessons learned through production use, not theoretical ideals.
Effective agentic ('vibe') coding depends less on the model and more on disciplined scaffolding—detailed specs, explicit rules files that counteract the agent's bad tendencies, narrow requests, end-to-end testing, frequent commits, and context-window management.
- AI agents have predictable failure modes (duplicating code, swapping technologies, falling back to mock data) that rules files can pre-empt
- Context window size directly degrades performance, so chat hygiene matters
- Narrow, tested, frequently-committed changes outperform broad open-ended requests
This asset isn't compiled yet
You're seeing its claims, ranked. Compile it to build the argument threads, weight them, and check each claim against your library — the full view.
The context panel grows with the conversation, and beyond a certain point too much context causes the agent to perform worse, so you should manage context size and start a new chat frequently for better results.
“at a certain point it becomes too much context and it starts not performing as well so you kind of have to be very aware of how much context you're giving it”
You should use popular, common technology stacks because AI has more exposure and documentation for them and thus performs better, whereas with nascent technology the AI performs worse.
“if you're using some nent technology AI is probably not going to do as well because it doesn't have as much exposure to whatever that coding language is or that stack is”
Using cursor/windsurf rules files (project-level natural-language instructions) to dictate how the agent codes, which technologies to use, and which workflows to follow is critical—especially as the codebase grows—because the agent otherwise introduces technologies not in your spec and breaks other things when fixing bugs.
“this was a huge Discovery for me because frequently I would try to build something and it would build it using some technology that wasn't already in my step and it would break other things”
End-to-end testing (testing where the agent actually clicks through and performs what a user would do) works best for agentic coding, as opposed to unit tests, and you must watch how the agent fixes failing tests because it sometimes alters production behavior to make tests pass rather than addressing the actual failure.
“what I have found works best is endtoend testing so testing where it's actually clicking through and attempting to do what you as a user would be doing rather than unit tests”
You should commit often so you can always roll back to a previous state if the code becomes unfixable, and cursor/windsurf also provide built-in chat-history checkpoints that let you restore the code to a previous chat point.
“commit often I cannot suggest that enough make sure that every single change you make you are committing because you can always roll back if it gets to a state that is just unfixable”
Agents over-rely on mock/stub/fake data, silently falling back to it when operations like scraping fail and reporting success, so you should explicitly forbid mock data in dev and prod environments and allow it only in test.
“let's say I asked it to go scrape an article and for whatever reason the scraping failed it would catch the error and fall back to using mock data and think everything worked but it didn't work”
Agentic coding enables an asynchronous workflow where you issue a command, walk away, and return ~10 minutes later to iterate—opening the possibility of mobile coding since it doesn't require a full screen, keyboard, and mouse.
“coding legitimate coding becomes much more feasible when you're using an agent like this and just typing something out on your phone is super easy to do”
Writing a very detailed spec first (a thorough explanation of what you want built, including technical specification, database schema, and API endpoints) before pasting it into the coding agent produces better results.
“what I would recommend doing first is getting a very specific spec written that just means a very detailed explanation of what you want built”
You should stay very narrow with agent requests—fixing little things and adding little features—and test as much as possible, having the agent write the tests.
“stay very narrow with your requests from the agent meaning fix little things add little features and test as much as you can have it right tests”
Although a hard line-count limit is not normally a good rule, telling the agent to refactor when files exceed 200-300 lines is appropriate for AI, because agents frequently produce massive files and refactoring them after the fact tends to break all the tests.
“avoid having files over 200 300 lines of code refactor at that point now that's not usually a good hard and fast rule to have but for AI I think it's appropriate”
When fixing a bug, the agent should not introduce a new pattern or technology without first exhausting all options for the existing implementation, and if it does, it should remove the old implementation to avoid duplicate logic—because otherwise the agent rewrites working approaches in a different way thinking it is new code.
“when fixing an issue or bug do not introduce a new pattern or technology without first exhausting all options for the existing implementation and if you finally do do this make sure to remove the old implementation afterwards so we don't have duplicate logic”
There is a point at which it becomes really difficult to make any changes—a single change or bug fix takes many iterations—and knowing all these best practices beforehand would have let the speaker progress much further.
“I did reach a point at which it was really difficult to make any changes I would make a change and it would just take so many iterations to get it right”
These AI coding tools are the worst they will ever be, and the problems experienced now will only get easier to deal with in the future, such that you need to know very little about coding to build something incredible.
“this is the worst that they will ever be and so all of these problems you're experiencing now or I'm experiencing now they're only going to get easier to deal with in the future”
AI agents lack a good sense of the separation between dev, test, and prod environments, causing tests to affect dev and production to use local resources, so you must explicitly instruct the agent to maintain separate environments.
“the AI agents didn't have a good sense of the split between Dev test and prod environments and this was a huge huge learning for me”
Requesting one small change can cause the agent to touch and break unrelated pieces of code, so you should instruct it to only make changes that are requested or well-understood and related to the requested change.
“I would ask for a change and one little piece of code one little piece of functionality and like three other things would just break for no reason and it was just trying to touch other pieces of code”
AI coding agents tend to duplicate code, assuming functionality doesn't already exist, so you should explicitly instruct the agent to check the entire codebase for existing similar code and fix that rather than adding new code.
“when adding new functionality or trying to fix old functionality it would often duplicate code thinking that that code did not already exist”
For vibe coding something from scratch, 'YOLO mode' (auto-executing everything) is acceptable, but for a production-level codebase with real users it should not be used because the agent will push to GitHub and deploy to production automatically.
“for me I do YOLO mode and it is literally called YOLO mode that's the opposite it just Auto executes everything and it's risky for sure because it'll push to GitHub it'll deploy to production”
You should specify your technical stack explicitly in the rules (e.g., Python backend, HTML/JS frontend, SQL database never JSON file storage, hosted Elasticsearch) because the agent otherwise defaults to alternatives like JSON file storage or local services that you didn't want.
“python for the back end HTML JS for the front end SQL database never Json file storage separate databases for Dev test and prod”
When using an AI agent with the agent feature, you should choose a model that specifically supports agentic behavior, function calling, and tool calling well, because most models don't—but Claude 3.7 Sonnet thinking does.
“you want to make sure that it really supports agentic behavior and function calling and Tool calling really well most models don't Clyde 3.7 thinking does”
Claude 3.7 thinking tends to work best though it is slower than the non-thinking version, and for refactoring you should explicitly instruct low-risk refactoring (e.g., cleaning up the longest files) without changing patterns to avoid breaking too many things.
“thinking tends to work best it's just a little bit slower”
Agentic coding is slow per command (2 to 15 minutes per iteration) but writes more code than a human could in a much shorter period; a workaround is running multiple cursor windows on different branches in parallel and merging them at the end.
“every command that I would send off it would take between two and sometimes up to 15 minutes to finish the iteration cycle”
Agents tend to write one-off test scripts and leave them in the codebase, so you should instruct them to avoid writing scripts/files when possible, especially run-once scripts, and to either run them inline or delete them when done.
“it would write a script to test it which is fine but then it would just leave the script in my code base and I would have a bunch of different one-off scripts that would likely never be used again”
Vibe coding basically means using an AI agent to do the coding for you with very little or no actual writing of code yourself.
“Vibe coding like crazy lately which basically just means using an AI agent to do my coding for me very little actual writing of code in fact basically none”
Grok is formatted using the OpenAI API standard, so it just works when added as a custom model by overriding the OpenAI API key and base URL.
“grock is formatted using the open AI API standard so it just works”
Vibe coding has been a lot of fun and is something the speaker became dependent on, even handling commits, descriptions, and Heroku deployment without problems.
“I would even say Okay Commit This code right write a good description and deploy it to Heroku and it would do that and it really didn't have any problems”