Vibe Coding — When and How

In February 2025, Andrej Karpathy posted a phrase that stuck: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Sounds reckless. Sometimes it is. But vibe coding is genuinely one of the fastest ways to get working software out of Claude Code. You just need to know when to vibe and when to stop.

What This Actually Looks Like

Normal Claude Code usage involves detailed prompts, reviewing every change, staying closely involved. Vibe coding throws most of that out. You give a loose direction and let the agent run.

claude "Build a CLI tool that takes a CSV of email addresses and checks which ones have valid MX records. Use Node.js. Make it fast."

You don't specify the library. You don't define the output format. You don't dictate error handling. You describe the vibe of what you want and let Claude make all the implementation decisions.

Then you run it. Works? Great. Doesn't? "Fix it" or "make it handle large files without running out of memory." Steering by outcome, not by code.

Where It Shines

Bash scripts and small utilities. Tight feedback loops. You run it, it either works or it doesn't. Almost no hidden complexity. Vibing a shell script to rename a batch of files? Perfect.

Throwaway stuff. Prototypes, offline tools, personal utilities, static sites. If the worst case is "I delete it and start over," vibe freely.

Permutation tasks. Fifty test fixtures, a set of example configs, sample data in various formats. Let Claude generate variations while you spot-check.

Greenfield prototyping. You're exploring an idea and don't care about code quality yet. Speed matters more than architecture. Nothing gets you to a working demo faster.

Where It Destroys Things

Novel functionality. When you're exploring a new API or building something unfamiliar, vibing limits your creative scope. You won't learn how the API actually works. You just get "a thing that seems to work" without understanding why. Terrible position to be in when it breaks.

Core system modules. Authentication. Payment processing. Data pipelines. Not places for unexplained black boxes. Vibe-code your auth system and you'll have security holes you can't see because you never looked at the code.

Design-heavy work. UI, information architecture, user flows. Vibe coding produces generic, soulless output. Karpathy's community calls this "slop." Looks fine at first glance but has no personality or thought behind it.

Code you'll maintain. If you're living with this code for months, you need to understand it. Vibe coding optimizes for speed today at the cost of comprehension tomorrow. That trade isn't always worth it.

Guardrails

You don't have to choose between "full vibe" and "review every line."

Git checkpoints. The single most important guardrail. Commit before you start vibing. Commit after every successful milestone. Things go sideways? Reset.

git add -A && git commit -m "checkpoint: before vibe coding the export feature"
claude "Add CSV and JSON export to the dashboard. Include date filtering."
# test it manually
git add -A && git commit -m "checkpoint: export feature working"

Plan Mode + ultrathink. Before letting Claude run wild, activate Plan Mode with Shift+Tab and ask it to think through the approach first. Catches bad architectural decisions before they become 500 lines of janky code you have to untangle.

# In Plan Mode:
"I want to add real-time notifications. Before you build anything, use ultrathink to analyze what this would require given the current architecture."

You get a detailed analysis without any code changes. Review the plan, adjust, then let it execute. Still vibing, but with a map.

Scope limits. Tell Claude what NOT to touch. "Add the export feature but don't modify the database schema." "Build this in a new file, don't change existing components." Constraints prevent the agent from rewriting half your codebase during a vibe session.

Review gates. After vibing, switch to careful mode. Ask Claude to examine its own output for redundancy, disconnected features, and logic errors.

The Confidence Rule

Ask yourself: "How confident am I that I could fix whatever this produces if it goes wrong?"

Above 80%? Vibe away. You understand the domain well enough to catch problems and course-correct.

Below 80%? Slow down. Use Plan Mode. Review the output. Ask questions. You're in learning territory, and vibing through learning territory means you won't actually learn anything.

This threshold shifts with stakes. Personal script? 60% confidence is fine. Production payment flow? You want 95% before loosening your grip.

Try It: Vibe Code a Prototype

Pick a small idea. Something you would normally spend an afternoon on.

# Step 1: Create a checkpoint
git checkout -b vibe-experiment
git add -A && git commit -m "checkpoint: starting vibe experiment"
 
# Step 2: Give a loose prompt
claude "Build a bookmark manager CLI. I can add URLs with tags, list them, search by tag, and export to HTML. Use SQLite. Make it feel nice to use."
 
# Step 3: Test the result
# Run it, try edge cases, break it intentionally
 
# Step 4: Have Claude Code review its own work
claude "Look at the code you just wrote. Find any redundancy, missing error handling, or features that are not actually connected to anything."
 
# Step 5: Decide — keep, refine, or scrap

Break the result on purpose. Submit empty inputs. Try special characters. Upload something unexpected. If it handles everything on the first try, test harder. That's when you know you haven't pushed it enough.

The Cycle

The best workflow isn't pure vibe or pure review. It's cycling between them.

Vibe to generate. Review to validate. Vibe to iterate on feedback. Review to finalize.

Add concrete code examples to your CLAUDE.md showing patterns you prefer and patterns you want avoided. This steers the agent during vibe sessions without manual review of every line. Ask Claude to document what it built and how components connect. Test the full user journey with realistic data, not placeholder nonsense.

You're after the speed of vibing with the quality of careful development.

The Gist

Vibe coding means steering by outcome, not controlling implementation. It's great for scripts, prototypes, low-risk tools, permutation tasks. It fails hard for production systems, security-critical code, novel APIs, and design-heavy work.

Git checkpoints are non-negotiable. Commit before, commit after, roll back when needed. Plan Mode with ultrathink before execution catches architectural mistakes early. And the confidence rule: above 80% that you could fix problems yourself? Vibe away. Below that? Slow down and pay attention.