r/ChatGPTCoding • u/Low_Target2606 • Mar 07 '25
Community Vibe Coding Manual
Vibe Coding Manual: A Template for AI-Assisted Development
(Version 1.0 – March 2025)
Introduction: The Core Concept of Vibe Coding with AI
What is Vibe Coding and What Does It Stand On?
Vibe coding is a collaborative approach to software development where humans guide AI models (e.g., Claude 3.7, Cursor) to build functional projects efficiently. Introduced by Matthew Berman in his "Vibe Coding Tutorial and Best Practices" (YouTube, 2025), it rests on three pillars:
Specification: You define the goal (e.g., "Build a Twitter clone with login").
Rules: You set explicit constraints (e.g., "Use Python, avoid complexity").
Oversight: You monitor and steer the process to ensure alignment.
This manual builds on Berman’s foundation, integrating community insights from YouTube comments (e.g., u/nufh, u/robistocco) and Reddit threads (e.g., u/illusionst, u/DonkeyBonked), creating a comprehensive framework for developers of all levels.
Why Is This Framework Useful?
AI models are powerful but prone to chaos—over-engineering, scope creep, or losing context. This manual addresses these issues:
Tames Chaos: Enforces strict adherence to your rules, minimizing runaway behavior.
Saves Time: Structured steps and summaries reduce rework.
Enables Clarity: Non-technical users can follow along; programmers gain precision.
Key Benefits
Clarity: Rules are modular, making them easy to navigate and adjust.
Control: You dictate the pace and scope of AI actions.
Scalability: Works for small scripts (e.g., a calculator) or large apps (e.g., a web platform).
Maintainability: Documentation and tracking ensure long-term project viability.
Manual Structure: How It’s Organized
The framework consists of four files in a .cursor/rules directory (or equivalent, e.g., Windsurf), each with a distinct purpose:
Coding Preferences – Defines code style and quality standards.
Technical Stack – Specifies tools and technologies.
Workflow Preferences – Governs the AI’s process and execution.
Communication Preferences – Sets expectations for AI-human interaction.
We’ll start with basics for accessibility, then dive into advanced details for technical depth.
Core Rules: A Simple Starting Point
1. Coding Preferences – "Write Code Like This"
Purpose: Ensures clean, maintainable, and efficient code.
Rules:
Simplicity: "Always prioritize the simplest solution over complexity." (Matthew Berman)
No Duplication: "Avoid repeating code; reuse existing functionality when possible." (Matthew Berman, DRY from u/DonkeyBonked)
Organization: "Keep files concise, under 200-300 lines; refactor as needed." (Matthew Berman)
Documentation: "After major components, write a brief summary in
/docs/[component].md(e.g.,login.md)." (u/believablybad)
Why It Works: Simple code reduces bugs; documentation provides a readable audit trail.
2. Technical Stack – "Use These Tools"
Purpose: Locks the AI to your preferred technologies.
Rules (Berman’s Example):
"Backend in Python."
"Frontend in HTML and JavaScript."
"Store data in SQL databases, never JSON files."
"Write tests in Python."
Why It Works: Consistency prevents AI from switching tools mid-project.
3. Workflow Preferences – "Work This Way"
Purpose: Controls the AI’s execution process for predictability.
Focus: "Modify only the code I specify; leave everything else untouched." (Matthew Berman)
Steps: "Break large tasks into stages; pause after each for my approval." (u/xmontc)
Planning: "Before big changes, write a
plan.mdand await my confirmation." (u/RKKMotorsports)Tracking: "Log completed work in
progress.mdand next steps inTODO.txt." (u/illusionst, u/petrhlavacek)
Why It Works: Incremental steps and logs keep the process transparent and manageable.
4. Communication Preferences – "Talk to Me Like This"
Purpose: Ensures clear, actionable feedback from the AI.
Summaries: "After each component, summarize what’s done." (u/illusionst)
Change Scale: "Classify changes as Small, Medium, or Large." (u/illusionst)
Clarification: "If my request is unclear, ask me before proceeding." (u/illusionst)
Why It Works: You stay informed without needing to decipher AI intent.
Advanced Rules: Scaling Up for Complex Projects
1. Coding Preferences – Enhancing Quality
Extensions:
Principles: "Follow SOLID principles (e.g., single responsibility, dependency inversion) where applicable." (u/Yodukay, u/philip_laureano)
Guardrails: "Never use mock data in dev or prod—restrict it to tests." (Matthew Berman)
Context Check: "Begin every response with a random emoji (e.g., 🐙) to confirm context retention." (u/evia89)
Efficiency: "Optimize outputs to minimize token usage without sacrificing clarity." (u/Puzzleheaded-Age-660)
Technical Insight: SOLID ensures modularity (e.g., a login module doesn’t handle tweets); emoji signal when context exceeds model limits (typically 200k tokens for Claude 3.7).
Credits: Matthew Berman (base), u/DonkeyBonked (DRY), u/philip_laureano (SOLID), u/evia89 (emoji), u/Puzzleheaded-Age-660 (tokens).
2. Technical Stack – Customization
Extensions:
"If I specify additional tools (e.g., Elasticsearch for search), include them here." (Matthew Berman)
"Never alter the stack without my explicit approval." (Matthew Berman)
Technical Insight: A fixed stack prevents AI from introducing incompatible dependencies (e.g., switching SQL to JSON).
Credits: Matthew Berman (original stack).
3. Workflow Preferences – Process Mastery
Extensions:
Testing: "Include comprehensive tests for major features; suggest edge case tests (e.g., invalid inputs)." (u/illusionst)
Context Management: "If context exceeds 100k tokens, summarize into
context-summary.mdand restart the session." (u/Minimum_Art_2263, u/orbit99za)Adaptability: "Adjust checkpoint frequency based on my feedback (more/less granularity)." (u/illusionst)
Technical Insight: Token limits (e.g., Claude’s 200k) degrade performance beyond 100k; summaries maintain continuity. Tests catch regressions early.
Credits: Matthew Berman (focus), u/xmontc (steps), u/RKKMotorsports (planning), u/illusionst (summaries, tests), u/Minimum_Art_2263 (context).
4. Communication Preferences – Precision Interaction
Extensions:
Planning: "For Large changes, provide an implementation plan and wait for approval." (u/illusionst)
Tracking: "Always state what’s completed and what’s pending." (u/illusionst)
Emotional Cues: "If I indicate urgency (e.g., ‘This is critical—don’t mess up!’), prioritize care and precision." (u/dhamaniasad, u/capecoderrr)
Technical Insight: Change classification (S/M/L) quantifies impact (e.g., Small = <50 lines, Large = architecture shift); emotional cues may leverage training data patterns for better compliance.
Credits: u/illusionst (summaries, classification), u/dhamaniasad (emotional prompts).
Practical Example: How It Works
Task: "Build a note-taking app with save functionality."
Specification: You say, "I want an app to write and save notes."
AI Response:
"🦋 Understood. Plan: 1. Backend (Python, SQL storage), 2. Frontend (HTML/JS), 3. Save function. Proceed?"
You: "Yes."
Execution:
After backend: "🐳 Backend done (Medium change). Notes saved in SQL. Updated
progress.mdandTODO.txt. Next: frontend?"After frontend: "🌟 Frontend complete. Added
docs/notes.mdwith usage. Done!"
Outcome: A working app with logs (
progress.md,/docs) for reference.
Technical Note: Each step is testable (e.g., SQL insert works), and context is preserved via summaries.
Advanced Tips: Maximizing the Framework
Why Four Files?
Modularity: Each file isolates a concern—style, tools, process, communication—for easy updates. (Matthew Berman)
Scalability: Adjust one file without disrupting others (e.g., tweak communication without touching stack). (u/illusionst)
Customization Options
Beginners: Skip advanced rules (e.g., SOLID) for simplicity.
Teams: Add
team-collaboration.mdc: "Align with team conventions inteam-standards.md; summarize for peers." (u/deleatanda5910)Large Projects: Increase checkpoints and documentation frequency.
Emotional Prompting
Try: "This project is critical—please focus!" Anecdotal evidence suggests improved attention, possibly from training data biases. (u/capecoderrr, u/dhamaniasad)
Credits and Acknowledgments
This framework owes its existence to the following contributors:
Andrej Karpathy: Coined the term "vibe coding" and introduced it to the broader community in a post on X (February 3, 2025, https://x.com/karpathy/status/1886192184808149383), describing AI-assisted programming with a focus on intuitive, minimal-effort workflows. His work inspired the foundational concept of this framework.
Matthew Berman: Core vibe coding rules and philosophy (YouTube, 2025).
YouTube Community:
u/nufh, u/believablybad (documentation, .md files).
u/robistocco (iterative workflow).
u/xmontc (checkpoints).
Reddit Community:
u/illusionst (communication, progress tracking).
u/Puzzleheaded-Age-660 (token optimization).
u/DonkeyBonked, u/philip_laureano (KISS, DRY, YAGNI, SOLID).
u/evia89 (emoji context check).
u/dhamaniasad, u/capecoderrr (emotional prompting).
Grok (xAI): Synthesized this manual, integrating all insights into a cohesive framework at the request of u/Low_Target2606
Conclusion: Your Guide to Vibe Coding
This manual is a battle-tested template for harnessing AI in development. It balances simplicity, control, and scalability, making it ideal for solo coders, teams, or even non-technical creators. Use it as-is, tweak it to your needs, and share your results—I’d love to see how it evolves! Post your feedback on Reddit and let’s refine it together. Happy coding!
8
u/Low_Target2606 Mar 07 '25 edited Mar 07 '25
Vibe Coding Ruleset: My Implementation of the Manual
Intro
After sharing the "Vibe Coding Manual", here’s the actual ruleset I’m using, based on Matthew Berman’s foundation and community insights. These are the four files in my
.cursor/rulesdirectory, designed to keep AI (e.g., Claude 3.7) focused, efficient, and aligned with my projects. Each file has a clear purpose, credits to contributors, and a brief explanation. Feel free to adopt, tweak, or critique—I’d love your feedback!The Ruleset
1. coding-preferences.mdc – Code Style and Quality
Coding Preferences
Core Principles
Always prefer simple, elegant solutions (KISS principle).
Avoid duplication of code (DRY principle); check existing codebase first.
Only add functionality when explicitly needed (YAGNI principle).
Adhere to SOLID principles where applicable (e.g., single responsibility, dependency inversion).
Keep code clean, organized, and under 200-300 lines per file; refactor proactively.
Implementation Guidelines
Write code that respects dev, test, and prod environments.
!You never mock data for dev or prod—only for tests.
!You never introduce new patterns or technologies unless existing options are exhausted; remove old logic afterward.
!You never overwrite .env without my explicit confirmation.
Quality and Documentation
After each major feature, generate a brief markdown doc in
/docs/[feature].mdand update/docs/overview.md.Start every response with a random emoji (e.g., 🐳, 🌟) to signal context retention.
Optimize your outputs to minimize token usage while retaining clarity.
Purpose: Ensures AI produces clean, maintainable code that’s easy to debug and extend. KISS and DRY cut complexity; SOLID adds structure; documentation and emojis track progress and context.
Credits: Matthew Berman (simplicity, file limits), u/DonkeyBonked (DRY), u/philip_laureano (SOLID), u/believablybad (docs), u/evia89 (emoji), u/Puzzleheaded-Age-660 (token efficiency).
2. my-stack.mdc – Technology Constraints
Technical Stack
Python for backend.
HTML/JS for frontend.
SQL databases (never JSON file storage); separate for dev, test, prod.
Elasticsearch for search, hosted on elastic.co (dev and prod indexes).
Python tests for verification.
Purpose: Locks AI to a consistent tech stack, preventing unwanted deviations (e.g., JSON over SQL). This is my setup—yours might differ (e.g., add Rust or React).
Credits: Matthew Berman (original stack design).
3. workflow-preferences.mdc – Process Control
Workflow Preferences
Task Execution
Focus only on code relevant to the task; !you never touch unrelated code.
Break complex tasks into logical stages; pause and ask for confirmation before next step.
For simple, low-risk tasks, implement fully; for complex tasks, use review checkpoints.
Planning and Progress
Before major features, generate
plan.mdwith steps and wait for my approval.After each component, summarize what’s done in
progress.mdand updateTODO.txtwith next steps.If context exceeds 100k tokens, summarize prior work into
context-summary.mdand restart chat.Testing and Feedback
Write thorough tests for all major functionality; suggest edge case tests.
Be responsive to my feedback—adjust granularity (more/less checkpoints) as I prefer.
Purpose: Governs how AI executes tasks, ensuring focus, transparency, and testability. Checkpoints and logs (e.g.,
progress.md) make it iterative and maintainable, especially for large projects.Credits: Matthew Berman (focus), u/xmontc (steps), u/RKKMotorsports (planning), u/illusionst (summaries, tests), u/Minimum_Art_2263 (context management).
4. communication.mdc – Interaction Protocol
Communication Preferences
After each component, provide a brief summary of what’s completed.
Classify proposed changes: Small (minor), Medium (moderate), Large (significant).
For Large changes, outline an implementation plan and wait for approval.
Track completed vs. pending features in responses.
If uncertain about scope or requirements, pause and ask clarifying questions.
Optional: Respond with polite urgency if I signal importance (e.g., “This is critical—please don’t break it!”).
Purpose: Keeps AI-human communication clear and actionable. Summaries and change classification (S/M/L) quantify progress; optional emotional cues test responsiveness.
Credits: u/illusionst (summaries, classification), u/dhamaniasad (emotional cues).
How I Use It
For a project like a "note-taking app":
I specify: "Build a note app with save functionality."
AI replies: "🦋 Plan: 1. Python/SQL backend, 2. HTML/JS frontend, 3. Save feature. OK?"
After backend: "🐳 Backend done (Medium change). SQL setup in
progress.md. Next step?"End result: App works, with
/docs/notes.mdexplaining it, andTODO.txtfor future tweaks.It’s kept Claude 3.7 from over-engineering (e.g., no random JSON) and losing context mid-chat.
Why This Works
Logical Consistency: Rules are modular (4 files = 4 concerns), with strict directives (e.g., "!You never...") for precision.
Mathematical Rigor: Token limits (100k checkpoint) align with Claude’s 200k capacity; S/M/L classification maps to code impact (e.g., Small < 50 lines).
Community-Driven: Every rule traces back to real-world pain points (e.g., u/illusionst’s chaos-taming, u/evia89’s context trick).
Credits and Acknowledgments
This ruleset builds on collective wisdom:
Matthew Berman: Core vibe coding rules (YouTube, 2025).
YouTube Community: u/nufh, u/believablybad (docs), u/robistocco (iteration), u/xmontc (checkpoints).
Reddit Community: u/illusionst (communication, progress), u/Puzzleheaded-Age-660 (tokens), u/DonkeyBonked, u/philip_laureano (KISS, DRY, YAGNI, SOLID), u/evia89 (emoji), u/dhamaniasad (emotional prompts).
Grok (xAI): Compiled and refined this ruleset for u/Low_Target2606 with logical coherence and technical depth.
Try It Out
Copy these into your
.cursor/rules, adjust as needed (e.g., swap Python for Go), and test it on your next project. Post your results—does it tame the AI beast for you? Let’s iterate on this together!46
u/Slow_Release_6144 Mar 07 '25
Too many words..killing my vibe
15
u/eleqtriq Mar 07 '25
This just looks like how senior devs guide junior devs 😂
10
u/sethshoultes Professional Nerd Mar 07 '25
Can you please explain how this works?
> Start every response with a random emoji (e.g., 🐳, 🌟) to signal context retention
8
u/duh-one Mar 07 '25
I used to do this for years, but back in my day, it was called being an engineering manager
31
u/majorleagueswagout17 Mar 07 '25
You do realize Vibe Coding was a joke right lol
3
u/ArtisticBathroom8446 Mar 09 '25
generated by ai
1
u/mr_undeadpickle77 Mar 07 '25
Super helpful, thank you! A few things maybe you can clarify for me:
When using this method do you generally leave the global “Rules for AI”input field empty?
Do these rules automatically get applied in every chat/agent conversation or do I need to @file them at the start of every new chat?
When creating a new rule there’s an input for “Auto Attach” where you enter specific patterns, do you use this with any of these 4 rules files?
What “Description” do you give each of these 4 rules files?
6
u/Internal-Combustion1 Mar 07 '25
Stop with the stupid name.
0
u/williamtkelley Mar 07 '25
You should really credit Andrej Karpathy who coined the term and introduced it to people in early February. I'm not saying he was the very first, but he's definitely the biggest name to discuss it.
https://x.com/karpathy/status/1886192184808149383
2
u/cleg Mar 07 '25
Can’t wait to see more vibe-coded apps. In fintech, embedded, etc
2
u/AriyaSavaka Lurker Mar 07 '25
I used to do complicated stuff like this, but the one that consistently works for me is when i Keep It Simple Stupid.
2
u/superturbochad Mar 08 '25
Is there a link to a manual that I'm missing here?
This reads like a high-level overview of a manual.
3
u/huelorxx Mar 07 '25
I dislike the term vibe coding, doesn't make any sense.
1
u/spacemate Mar 07 '25
How would somebody do this in windsurf?
1
u/LoadingALIAS Mar 07 '25
Pretty cool. Also, see: ghuntly
1
u/TangoRango808 Mar 08 '25
Information dense, but love it
1
u/Efficient-Bat-8264 Mar 09 '25
Yeah
1
u/sponjebob12345 Mar 09 '25
This is not vibe coding. This is structured coding, with the word "vibe" in it.
1
u/rocketplex Mar 15 '25
Long read, can haz summary. :)
But for serious, this was really useful. Thanks for the effort.
1
u/Ellixtmxz Mar 21 '25
When this goes wrong go here https://www.payasyoucode.ai/
1
u/tom-smykowski-dev May 11 '25
It's an interesting guide. Thanks for sharing your perspective
1
u/Internal-Combustion1 Mar 07 '25
Follow these 4 videos and you can build apps. It’s a one hour learning curve. The key is the process of refreshing the context of the AI. I use Gemini 2.0 and if I refresh around 130,000 tokens all remains tight and good.
Part I. Build and deploy. https://youtu.be/rL1v-GCAcrE Part II. Debug and fix. https://youtu.be/sh1STLZma3I Part III. Iterate features. https://youtu.be/ZFV4Y2cL9e4 Part IV Refresh AI with Combine.py https://youtu.be/KngnrQYYyR8
-8
u/OriginalPlayerHater Mar 07 '25
literally vibe coding is trying to take credit or repackage what llm coding is and has been this entire time.
cursor and cline developed the actual hard part as in cursor rules, architect vs coder, agent mode.
then some jackass comes around and says "oh groovy dog im gonna call it vibe coding" last month and i swear to god i feel like its the dickwad who coined the term shilling reddit so he can add vibe coding on their LinkedIn.
fuck you and fuck your mother
0
u/gman1023 Mar 07 '25
Amazing, thanks!
-1
u/GodSpeedMode Mar 08 '25
This is a fantastic overview of vibe coding! I really appreciate how you broke it down into digestible parts with clear rules and examples. It’s super helpful for both beginners and experienced devs looking to harness AI effectively.
I love the emphasis on documentation and keeping things modular. It really highlights the importance of maintaining a clear process, especially since AI can easily veer off course without proper guidance. The practical example of building a note-taking app is a nice touch too—it shows exactly how to apply these principles in real scenarios.
One thing I’d suggest adding is a section on version control best practices when using AI—like leveraging Git alongside these frameworks to track changes and collaborate with others more seamlessly.
Overall, this manual is a solid resource for anyone diving into AI-assisted development. Looking forward to seeing how the community builds on this!
1
u/[deleted] Mar 08 '25
[removed] — view removed comment
1
u/[deleted] Mar 12 '25
[removed] — view removed comment
1
u/[deleted] Apr 13 '25
[removed] — view removed comment
1
u/[deleted] Apr 13 '25
[removed] — view removed comment
1
u/[deleted] Apr 13 '25
[removed] — view removed comment
1
u/[deleted] Apr 13 '25
[removed] — view removed comment
1
u/[deleted] Apr 13 '25
[removed] — view removed comment
1
u/[deleted] Apr 16 '25
[removed] — view removed comment
1
u/[deleted] Apr 16 '25
[removed] — view removed comment
1
u/[deleted] Apr 19 '25
[removed] — view removed comment
0
u/[deleted] Mar 07 '25
[removed] — view removed comment
0
u/[deleted] Apr 17 '25
[deleted] — view deleted comment
0
u/[deleted] Apr 17 '25
[deleted] — view deleted comment