

Vibe Coding Tutorial and Best Practices (Cursor / Windsurf)
Got a lot of questions asking about my stack and what I do when vibe coding. So I made a full video on it!
π Learn more on https://mammouth.ai/
Join My Newsletter for Regular AI Updates ππΌ
https://forwardfuture.ai
My Links π
ππ» Subscribe: https://www.youtube.com/@matthew_berman
ππ» Twitter: https://twitter.com/matthewberman
ππ» Discord: https://discord.gg/xxysSXBxFW
ππ» Patreon: https://patreon.com/MatthewBerman
ππ» Instagram: https://www.instagram.com/matthewberman_ai
ππ» Threads: https://www.threads.net/@matthewberman_ai
ππ» LinkedIn: https://www.linkedin.com/company/forward-future-ai
Media/Sponsorship Inquiries β
https://bit.ly/44TC45V
Video Stats
Video Info
Watch Options
Vibe Score Components
Sentiment
Technical Depth
Engagement
Topic Relevance
Quality Score
Overall
Engagement
Content
Technical
Top Topics
Sentiment Analysis
Polarity (Positive/Negative)
Subjectivity (Opinion/Fact)
Top Comments
Vibe coding = what everybody who wasn't already into software development has been doing with AI since they first started. Before Cursor, I just copied and pasted what ChatGPT gave me into vscode and put the errors back into chatgpt π
# Coding pattern preferences
β Always prefer simple solutions
β Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality
β Write code that takes into account the different environments: dev, test, and prod
β You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested
β 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 this, make sure to remove the old implementation afterwards so we donβt have duplicate logic.
β Keep the codebase very clean and organized
β Avoid writing scripts in files if possible, especially if the script is likely only to be run once
β Avoid having files over 200β300 lines of code. Refactor at that point.
β Mocking data is only needed for tests, never mock data for dev or prod
β Never add stubbing or fake data patterns to code that affects the dev or prod environments
β Never overwrite my .env file without first asking and confirming
One trick I found when starting new chats is ask for a summary of what itβs done so far and I paste that summary in the new chat
I recently build a three tiers web application (Angular frontend, Python/FastAPI backend and PostgreSQL database) on Docker using Cursor with Claude Sonnet 3.5 and Gemini 2.0 Flash Thinking. I took more of a step-by-step approach and proceeded by iterations, e.g, set up the docker configuration for FE/BE/DB, once that was done I described the data I needed and got the SQL done, then asked to expose CRUD APIs for the SQL tables etc. It's like being a Tech Lead engineer coordinating a team of devs and assigning tasks. The whole thing turned out very good, super satisfied with the results - it would have easily taken me 10x the time to build it myself.
For starting a new chat, I simply tell Windsurf that I want to create a new chat. Then, I ask it to generate a simplified version of the context in a .md file. After that, I start the new chat and instruct it to read the .md file first.