Keeping Vibe Code Organized — Crash Course

The Core Concepts to Learn First

1. Folder Structure / Project Organization

How you organize files matters more than you think. A well-structured project means Claude can find and edit the right file without breaking something else.

2. Version Control with Git

This is non-negotiable. Git is how you never lose working code. Before every AI session, you commit what works — so if Claude breaks something, you can roll back in one command.

The single habit that saves you: Every time something works, run git commit. Treat it like hitting save in a video game before a hard boss fight.

3. Environment Variables & Config

This is where vibe coders accidentally leak API keys or break deployments. Understanding .env files keeps your secrets safe and your config clean.

4. Naming Conventions

The most underrated skill. If your files and variables are named well, Claude always knows what it's looking at. Bad naming = AI confusion = broken code.

The rules are simple:

• Files named by what they do (authService.js, userRoutes.js, ProductCard.jsx)
• One concept per file
• No utils.js dumping grounds — split them up

5. Comments & Documentation for AI

You're not writing comments for other developers — you're writing them for future-you and for Claude. A one-line comment at the top of each file explaining what it does saves enormous confusion later.

The format that works best when vibe coding:

// PURPOSE: Handles all authentication logic (login, logout, token refresh)
// DEPENDS ON: userService.js, database.js
// DO NOT EDIT: the token expiry logic without updating authMiddleware.js too

No video needed — just start doing this on your next project.

6. README Files

Every project should have a README.md in the root folder explaining what the project is, how to run it, and what each major folder does. This is what you paste to Claude at the start of every new session so it has full context instantly.

The Structural Rules for Vibe Coding Specifically

These aren't from a video — they come from the patterns that actually keep AI-assisted projects from collapsing:

1. One concern per file. Never let a single file do more than one job. If it handles users AND payments, split it.
2. Keep AI sessions scoped. Don't ask Claude to "build the whole app." Ask it to build one specific module, then commit, then move on.
3. Maintain an ARCHITECTURE.md file. A living document you update as you build. List every module, what it does, and how it connects to others. Paste this into every Claude session.
4. Never let Claude touch files it doesn't need to. Always tell Claude exactly which file to work in. "Edit only userService.js" prevents accidental breakage elsewhere.
5. Feature branches in Git. Each new feature gets its own branch. Main branch = working code only. This is the safety net that lets you experiment freely.

Total Watch Time: ~90 minutes

Git is the most important thing on this list by a wide margin. If you only do one thing from this entire plan, learn Git basics and start committing daily. Everything else compounds on top of that foundation.

Your Current Setup (Already Done)

Both EdgeClaw and EcoCell already have Git configured:

• EdgeClaw → pushes to github.com/ecocellga/edgeclaw (private)
• EcoCell → pushes to github.com/ecocellga/ecocell (private)
• Auto-push runs every 17 minutes — your code is always backed up to GitHub
• Commits already have clear, descriptive messages

You're ahead of most people starting Git. The infrastructure is done — you just need the habit.

Git Commands — The Only Ones You Need

Save your work (commit)

After something works, run these two commands:

git add -A
git commit -m "describe what you just did"

Example:

git add -A
git commit -m "fixed MLB prop edge scanner to read from correct table"

Do this every time something works. It's hitting save before a boss fight.

See what changed since last save

git diff

Shows every line that was added or removed. Green = added, red = removed.

Undo changes to one file (load last save)

git checkout -- filename.ts

Reverts that one file back to the last commit. Everything else stays.

Undo ALL changes since last commit (nuclear undo)

git checkout .

Reverts everything back to the last commit. Use with caution — all unsaved changes are gone.

See your save history

git log --oneline -10

Shows the last 10 commits (saves). Each one has a short ID and your message.

Push to GitHub manually

git push

Sends your commits to GitHub. This already happens automatically every 17 minutes, but you can force it.

The Save Game Habit

The #1 rule: commit every time something works.

• Just fixed a bug? Commit.
• Just added a feature? Commit.
• About to ask Claude to make big changes? Commit first.
• About to try something risky? Commit first.

If Claude breaks something, you can always roll back:

git log --oneline -5       # find the last good commit
git checkout -- .           # undo everything since last commit

Branches (Level 2)

Branches let you experiment without touching your working code. Think of it like making a copy of your save file before trying something crazy.

Create a new branch

git checkout -b my-experiment

You're now on a separate copy. Main branch is untouched.

Switch back to main

git checkout master

Merge your experiment into main (if it worked)

git checkout master
git merge my-experiment

Delete a branch you don't need

git branch -d my-experiment

Quick Reference Card