Vibe Coding Reference

By the end of this lesson, you will have a reference for every power feature across the four CLI tools we teach — planning modes, autonomous modes, thinking levels, context management, and project memory. Bookmark this page and come back whenever you need to look something up.

What is vibe coding?

Andrej Karpathy coined the term in February 2025: “fully give in to the vibes, forget that the code even exists.” You describe what you want, the AI writes the code, and you accept the results based on whether the output feels right — without necessarily reading every line.

Simon Willison drew an important distinction: vibe coding is for throwaway prototypes where you do not review the code. Vibe engineering is for production work where you are accountable for every line the AI writes.

Tool modes at a glance

Every CLI tool has at least two operating modes. This table shows the big picture.

Planning modes

Planning modes let the AI analyze your project and propose a strategy before making any changes. Think of it as “read-only thinking.”

Autonomous / YOLO modes

These modes let the AI execute tasks with minimal or no confirmation. Useful for speed; risky if you are not careful.

Thinking and effort levels

Some tools let you control how deeply the AI thinks before responding. Higher effort = slower but more thorough.

Context management

As conversations get long, the AI can lose track of earlier details. These commands help you manage the conversation window.

Real Session Workflow

This is the rhythm experienced practitioners actually follow — not one-shot commands, but a cycle of thinking and building:

The mode dance: The back-and-forth between plan mode and execute mode IS the skill. You think in plan mode, build in execute mode, checkpoint with git, and repeat. When context gets stale, /compact preserves key decisions. When you’re starting a completely new task, /clear gives you a fresh start — but commit first.

Why -d for prototyping: claude -d (short for --dangerously-skip-permissions) removes the confirmation prompts so you can move fast on throwaway work. Use claude (without the flag) for anything you care about keeping.

Describe, don’t command: “I need a contact form with validation” beats “create a file called form.html with an input element.” Give context and intent — let Claude figure out the implementation.

Project memory files

Project memory files tell the AI about your project’s conventions, preferences, and structure before you say anything. They persist across sessions. The files below are commonly used conventions in this course — check each tool’s documentation for which files are officially auto-read vs. manually referenced.

MCP (Model Context Protocol)

All four CLI tools now support MCP — a standard protocol that lets AI tools connect to external services (databases, APIs, documentation servers, etc.) through plug-in “servers.” You configure MCP servers in your project config, and the AI can call them during a session.

Context window management

Your context window is like a physical desk — the longer you work without cleaning up, the harder it is to find what you need. Research shows every frontier model degrades as input grows, even well before hitting the maximum token limit.

Rule of thumb: A model’s effective context is roughly 60-70% of its advertised maximum. A focused 30K conversation will outperform a sprawling 200K one.

Best practices:

1. One task, one session. Build, commit, clear, move on. The single most impactful habit.
2. Commit before you clear. Git is your permanent save. Conversation is temporary.
3. Use plan mode for complex work. Natural breakpoints for clearing between phases.
4. Save state before clearing. Ask the AI to summarize progress, then add it to your project memory file.
5. Use /btw for throwaway questions (Claude Code). Sees context but does not grow it.
6. Delegate research to subagents. They run in their own context, keeping your main conversation clean.

The safety spectrum

Not every project needs the same level of caution. Use this spectrum to decide how much autonomy to grant:

Safe to vibe code                              Always review carefully
     |                                                    |
     v                                                    v
 Throwaway       Learning        Internal         Production
 prototype       exercise        tool             / public-facing
     |               |               |                |
  YOLO mode      Auto-edit      Plan first       Plan mode +
  Don't read     Skim output    Review diffs     read every line
  the code

When things go wrong

Quick recovery commands when the AI makes a mess:

Common workflows

Safe prototype flow:

1. mkdir prototype && cd prototype && git init
2. Start your AI tool in default (interactive) mode
3. Describe what you want. Review proposed edits before accepting.
4. Test the output. If it works, git add . && git commit -m "working prototype".

High-risk task flow:

1. Activate plan mode (/plan or Shift+Tab)
2. Review the AI’s proposed plan
3. Approve step by step, checking diffs along the way
4. Test thoroughly before committing

Long session rescue flow:

1. Run /compact to condense conversation history
2. If quality is still poor, try /model to switch models
3. If context is completely lost, /clear and restate your goal from scratch

Key takeaways

• Vibe coding = speed over review for throwaway work. Vibe engineering = same tools but you read every line. Both are valid depending on the stakes.
• Planning modes (Shift+Tab, /plan) let the AI analyze before acting. Use them for any non-trivial task.
• Autonomous modes are powerful but risky. Never use them near important data, research files, or production systems without backups.
• /compact saves your context window. Use it when conversations get long and the AI starts forgetting earlier decisions.
• Project memory files (CLAUDE.md, .github/copilot-instructions.md) persist across sessions. Start with /init and customize from there.