Vibe coding in 2026 — my full setup with Claude Code

"Vibe coding" gets a bad reputation because people assume it means shipping without thinking. That's not what it is — or at least not how I use it.

For me, vibe coding is a specific working state: high intent, low friction. You know what you want to build. You stop fighting the tools to get there.

Claude Code is the piece that made this possible for me. (If you're still weighing tools, I broke down Claude Code vs Cursor vs Copilot separately — this post assumes you've landed on Claude Code.)

The mental model shift

Before: I'd open my editor, think about the implementation, write the code, realize the types were wrong, fix the types, realize the pattern was wrong, refactor.

Now: I describe the outcome, Claude proposes a plan, I approve or redirect, it executes, I review. The decision-making is mine. The typing is Claude's.

This isn't automation — it's delegation. You're still the architect. You're just not the bricklayer.

My full setup

1. CLAUDE.md — conventions as guardrails

Every project has a CLAUDE.md at the root. It's a short markdown file that tells Claude what's true about this codebase: the stack, the folder structure, the patterns we use, the things we never do.

Without it, Claude guesses and gets things wrong. With it, the output is commit-ready the first time.

Mine includes:

• Stack (Next.js, TypeScript strict, Tailwind 4, Prisma)
• Import order rules (single block, no blank lines between imports)
• Action pattern (next-safe-action, never raw try/catch)
• Service pattern (throw DomainError, never return { success: false })
• Logging format (log.info(\Message | key=$`)`)

It takes 30 minutes to write. It saves hours per week.

2. Hooks — invisible automation

Claude Code hooks are shell commands that run automatically on events: session start, file write, tool call, stop.

The three I can't work without:

Session start → inject project briefing

cat .claude/briefing.md 2>/dev/null && git log --oneline -5 2>/dev/null

Claude starts every session knowing the current sprint goal and the last 5 commits. No context re-explaining.

Post-write → auto-lint

file=$(echo "$CLAUDE_TOOL_INPUT" | jq -r '.file_path')
[[ "$file" == *.ts || "$file" == *.tsx ]] && npx eslint --fix "$file" --quiet 2>/dev/null || true

Every TypeScript file gets linted immediately after Claude writes it. No lint debt accumulates.

Stop → push notification

osascript -e 'display notification "Claude is done" with title "Claude Code"'

I switch to something else during long tasks. I know when to come back.

3. Plan Mode — catch mistakes before they happen

For any task touching more than two files, I prefix with Plan: or press Shift+Tab. Claude maps out every file it will touch, in order, with reasons.

I spend 30 seconds reviewing. I catch wrong assumptions before they become wrong implementations. Then I approve and it executes.

This alone cut my "that's not quite right, try again" cycles by half.

4. Skills — reusable workflows

Skills are markdown files in .claude/skills/ that define repeatable workflows. I have one for commits, one for code review, one for debugging.

Instead of describing the same workflow every time, I run /commit and it knows: check the diff, write a concise message with the right format, push.

The starter kit I share includes the ones I use daily.

A typical morning

1. Open terminal, start Claude Code in the project dir
2. Session start hook injects today's context and recent commits
3. I describe what I'm building today
4. Claude plans it (if non-trivial)
5. I review and approve
6. It executes — writes files, runs type checks, fixes what breaks
7. Stop hook pings me when done
8. I review the diff, make small adjustments if needed
9. /commit — done

The whole loop from "I want to build X" to "X is committed" is faster than it used to take just to set up the scaffolding.

What this isn't

It's not "let the AI drive". The decisions are still mine:

• What to build and why
• Whether the plan makes sense
• Whether the output meets the standard

The vibe part is that the execution friction has dropped to near zero. Which means I can spend more time on the parts that actually matter.

If you want the time-tracked version of this — where the speedup actually comes from — I wrote that up in how I use Claude Code to code 3x faster.

Want my setup as a starting point? The Claude Code Skills Starter Kit bundles the skills and hooks from this post — drop it in ~/.claude/ and you're running in five minutes.