Setup

Before You Vibe

You’re about to let an AI write code for you. That’s fine. That’s the future. But before you start, you need to set up an environment where mistakes are catchable, reversible, and contained.

Think of it like this: you wouldn’t hand someone a chainsaw without safety gear. Vibe coding without guardrails is the same thing — fast, powerful, and extremely capable of removing a limb.

This chapter gets your environment ready. It’s short, it’s practical, and it will save you from disasters that are much harder to fix after the fact.

Pick Your Tools

You need three things to vibe responsibly:

1. An editor that shows you what’s happening. VS Code, Cursor, Zed, Neovim — whatever you’re comfortable with. The key is that you can see diffs, run terminals, and navigate code quickly. You’ll be reviewing a lot of generated code. Make sure your editor makes that easy.

2. An AI coding agent. Claude Code, GitHub Copilot, Cursor’s built-in agent, Codeium, or whatever works for you. This guide is tool-agnostic. The principles apply regardless of which agent you use.

3. A terminal you’re comfortable with. You’ll be running commands, checking git status, and verifying builds. If you’re not comfortable in a terminal yet, now is the time. You don’t need to be a wizard — just comfortable enough to cd, ls, and git status.

Git Init First

Before you write a single line of code — before you even open your AI agent — initialize a git repository.

git init
git add .
git commit -m “initial commit”

This is non-negotiable. Git is your undo button. Without it, every mistake your agent makes is permanent. With it, every mistake is a git diff away from being understood and a git checkout away from being reversed.

Commit Early, Commit Often

Every time your agent does something that works — commit it. Don’t wait until the feature is done. Don’t batch changes. Small, frequent commits give you fine-grained undo points.

A good rhythm:

1. Ask your agent to do something
2. Review what it did
3. If it looks good, commit
4. If it doesn’t, revert
5. Repeat

Set Up Your Guardrails

Guardrails are automated checks that catch mistakes before they ship. Your agent will generate code that looks right but isn’t. Guardrails catch the difference.

The Essentials

A linter. ESLint, Biome, Ruff, Clippy — whatever fits your language. A linter catches syntax issues, unused variables, and common mistakes instantly. Configure it once, run it always.

A formatter. Prettier, Black, gofmt — automated formatting means you never argue about style, and your agent’s code looks like yours. Run it on save or as a pre-commit hook.

Type checking. TypeScript, mypy, Flow — if your language supports it, use it. Types catch an entire class of bugs that your agent will absolutely produce. An agent that generates any everywhere is an agent without guardrails.

Pre-commit hooks. Use a tool like Husky, lefthook, or pre-commit to run your linter, formatter, and type checker before every commit. This means garbage literally cannot enter your repository.

Why This Matters for AI-Generated Code

Agents are confident. They generate code that reads well, compiles often, and fails at the edges. A linter catches the dead code they leave behind. A type checker catches the impossible function signatures. A formatter ensures consistency when the agent’s style drifts from yours.

Without guardrails, you’re relying on your own eyes to catch every mistake. Your eyes are tired. The linter is not.

Talk to Your Agent

Most AI coding agents support some form of persistent context — a file that tells the agent about your project, your preferences, and your rules. In Claude Code, it’s CLAUDE.md. In Cursor, it’s .cursorrules. Other tools have their own versions.

This file is the single most important thing you can write. It’s your agent’s instruction manual. Without it, the agent guesses. With it, the agent knows.

What to Put in Your Context File

• Project overview. What does this project do? What’s the tech stack? What’s the architecture?
• Conventions. How do you name files? Where do tests go? What patterns do you follow?
• Rules. What should the agent never do? No any types? No inline styles? No direct database queries outside the data layer?
• Preferences. Prefer functional components? Prefer early returns? Prefer named exports? Say so.

Don’t Write It From Scratch

Here’s the thing — your agent can write its own context file. It can explore your codebase, identify the patterns, and document them. You just need to tell it what to look for and how to write it.

Copy that into your agent, let it explore, and review what it produces. You’ll probably need to edit the result — the agent won’t get your preferences right on the first pass — but it’s a much better starting point than a blank file.

Keep It Updated

Your context file isn’t a one-time thing. As your project evolves, update it. Added a new library? Document it. Changed a convention? Update the file. The more current your context file is, the better your agent performs.

The Vibe Check

Here’s the habit that separates good vibe coders from people who ship garbage: review everything your agent generates before you accept it.

This doesn’t mean reading every line character by character. It means developing a quick mental checklist:

1. Does it do what I asked? Not what the agent thought I asked. What I actually asked.
2. Does it fit the codebase? Same patterns, same conventions, same style.
3. Are there side effects? Did it change files I didn’t expect? Did it add dependencies I didn’t ask for?
4. Does it handle edges? What happens with null? With empty strings? With a list of 10,000 items?
5. Can I explain it? If you can’t explain what the code does, you don’t understand it well enough to ship it.

The git diff Ritual

After every agent interaction, run git diff. Look at what changed. This is your vibe check. It takes 30 seconds and it catches problems that would take hours to debug in production.

Make it muscle memory. Agent generates code → git diff → review → commit or revert. Every time.