Sign in Subscribe

Day 14: What Vibe Coding Actually Is And the Mindset Shift That Makes It Work

Vibe coding isn't about being lazy. It's shifting what you think about: outcomes vs implementation. Learn the director mindset that makes it work.

Day 14: What Vibe Coding Actually Is And the Mindset Shift That Makes It Work

Hey, it's G.

Day 14 of the Claude Code series. New track: Vibe Coding.

Vibe coding is the most misunderstood term in AI development right now.

People hear "vibe coding" and think it means:

  • Being lazy
  • Skipping the thinking
  • Just throwing prompts at AI and hoping for the best
  • Not understanding your own code

That's not what vibe coding is.

Let me show you what it actually means — and the mindset shift that makes it work.

The Problem (The Old Way Is Exhausting)

Here's how I used to code with AI before I understood vibe coding:

  1. Think through the entire implementation in my head
  2. Ask Claude a question: "How do I fetch data on component mount?"
  3. Get an answer
  4. Manually copy the code
  5. Paste it into my editor
  6. Ask the next question: "How do I handle loading states?"
  7. Get another answer
  8. Copy, paste, adjust
  9. Repeat 20 times

Every. Single. Feature.

The problems with this:

  • I was still doing all the typing
  • I was switching constantly between thinking and executing
  • I was managing the implementation details myself
  • The AI was just a fancy Stack Overflow

I wasn't actually working with AI. I was working next to it.

The Concept (What Vibe Coding Actually Is)

Vibe coding is not about being lazy or skipping the thinking.

It's about shifting what you spend your thinking on.

Instead of thinking about implementation details, you think about outcomes.

Instead of writing code, you direct an agent that writes it.

The mindset shift sounds small but it changes everything about how a session flows.

Vibe coding is three things working together:

1. Plain English Direction

You describe what you want in outcome terms, not implementation terms.

Not "write a useEffect that fetches from /api/users on mount"

But "when this page loads, fetch the user list and display it in the table."

Claude Code figures out the how. You define the what.

2. Fast Iteration

You don't aim for perfect on the first pass.

You get something working. Review it. Course correct. Move forward.

Ship first, refine as you go.

The goal of each session is forward momentum, not perfection.

3. Full Flow State

You stay in the director's chair the entire session.

Claude Code executes. You review, approve, redirect.

Minimal interruptions.

You're not switching between thinking and typing — you're continuously making decisions while Claude handles the execution.

The Old Way vs The Vibe Coding Way

Old Way: Coding with AI

You: How do I fetch data in React?
AI: Here's a useEffect example...
You: [copies code, pastes, adjusts]
You: How do I handle loading states?
AI: Add useState for loading...
You: [copies code, pastes, adjusts]
You: How do I handle errors?
AI: Add useState for errors...
You: [copies code, pastes, adjusts]

You're the typist. AI is the reference.

Vibe Coding Way

You: Build a subscriptions page that fetches and displays 
     all subscriptions in a table. Show loading state while 
     fetching and error message if it fails. Match the style 
     of /app/users/page.tsx

Claude Code: [builds entire feature]

You: /review

You: Good. Two adjustments: add empty state message when 
     no subscriptions, and make upgrade button disabled 
     if already on Pro plan.

Claude Code: [makes adjustments]

You: Perfect. /ship

You're the director. Claude Code is the crew.

Claude Code closes the loop between idea and implementation.

The Director Mindset (The Key Shift)

Here's the mindset shift that makes vibe coding work:

Stop thinking like a typist. Start thinking like a director.

A film director doesn't operate the camera.

They don't set up the lights.

They don't edit the footage.

But they know exactly what shot they want.

And they communicate it clearly.

The crew executes. The director reviews the take and calls for adjustments.

That's the relationship with Claude Code.

You are the director. Claude Code is the crew.

Your job is to:

  • Know what you want (the outcome)
  • Communicate it clearly
  • Review what gets built
  • Redirect when needed

Claude Code's job is to:

  • Figure out how to implement it
  • Write the actual code
  • Follow your existing patterns
  • Execute quickly

The Three Rules of Vibe Coding

Rule 1: Describe Outcomes, Not Implementations

❌ Implementation thinking (old way):

> Write a React component with useState for loading and error 
> states, useEffect to fetch from /api/subscriptions, map the 
> response into a table with columns for name, status, and date

This tells Claude Code exactly how to build it.

But you still had to think through every implementation detail.

✅ Outcome thinking (vibe coding):

> Build a subscriptions page that fetches and displays all 
> subscriptions in a table. Show a loading state while 
> fetching and an error message if it fails. Match the 
> style of /app/users/page.tsx

This tells Claude Code what the feature should do.

Both prompts produce the same result.

The second one:

  • Takes half the time to write
  • Gives Claude Code room to follow your existing patterns
  • Lets you focus on outcomes, not implementation

More examples:

❌ Implementation:

> Create a new file utils/validation.ts with a function 
> validateEmail that uses a regex to check if an email 
> is valid and returns a boolean

✅ Outcome:

> Add email validation to the signup form. Invalid emails 
> should show an error message before the form submits.

❌ Implementation:

> Add a useState hook for the modal, create a button with 
> onClick that sets it to true, and render a modal component 
> conditionally based on that state

✅ Outcome:

> Add a "Delete Account" button that opens a confirmation 
> modal. The modal should have Cancel and Confirm buttons.

Rule 2: Plan First, Then Flow

Every vibe coding session starts with orientation and planning.

claude

# Orient Claude Code to what you're building:
> Here's what we're building today: a billing page where 
> users can see their current plan, usage this month, and 
> upgrade to Pro. Stripe is already configured in /lib/stripe.ts

# Get the plan before touching anything:
> /plan

Claude responds with detailed plan:

Plan for billing page:

Files to create:
1. app/billing/page.tsx - main billing page
2. components/billing/PlanCard.tsx - current plan display
3. components/billing/UsageMeter.tsx - usage this month
4. components/billing/UpgradeButton.tsx - upgrade to Pro CTA
5. utils/stripe/getSubscription.ts - fetch subscription data

Pattern to follow:
- Match layout from app/dashboard/page.tsx
- Use existing Stripe client in /lib/stripe.ts
- Use shadcn/ui Card components

Estimated steps: 12

Proceed?

You review the plan.

If it's good: Approve and let it run.

If something's off: Redirect before any code gets written.

> Good plan but don't create separate components yet. 
> Build everything in page.tsx first, we can extract 
> components later if needed.

Plan first habit is what separates vibe coding from vibe chaos.

Without a plan, it gets messy fast.

Rule 3: Review in Batches, Not After Every Line

Don't interrupt after every small change.

Let Claude Code complete a logical chunk, then review.

❌ Bad (interrupting constantly):

> Add a title to the page

[Claude adds title]

> Make it bigger

[Claude adjusts]

> Actually center it

[Claude centers it]

> Add some margin below it

[Claude adds margin]

This kills the flow. You're micromanaging.

✅ Good (review in batches):

> Build the basic page layout: header with title, 
> three sections for plan/usage/upgrade

[Claude builds entire layout]

> /review

> Good structure. Two adjustments: center the title 
> and add more vertical spacing between sections.

[Claude makes both adjustments at once]

Let Claude Code work. Then review and redirect.

The Basic Vibe Coding Session Structure

This is the structure I use for every feature:

1. Orient

Tell Claude Code what you're building today.

> Today we're adding a billing page. Users should see 
> their current plan, usage this month, and a button 
> to upgrade. Stripe is already configured. Look at 
> /app/dashboard/page.tsx for the layout pattern.

2. Plan

Get the plan before touching anything.

> /plan

Review the plan. Approve or redirect.

3. Execute

Claude Code builds. You stay in the director's chair.

> Looks good. Go ahead.

Then let it run. Don't interrupt.

4. Review

After a logical chunk is complete, review.

> /review

Check for:

  • Does it do what I asked?
  • Does it follow our patterns?
  • Any obvious issues?

5. Redirect

Course correct with clear outcome-focused feedback.

> Good. Two things: the upgrade button should be disabled 
> if the user is already on the Pro plan, and the usage 
> meter needs a percentage label. Fix those.

Notice: Still describing outcomes, not implementations.

6. Ship

When the session is done, run the pre-commit workflow.

> /ship

Review findings. Commit. Move on.

Real Vibe Coding Session (Start to Finish)

Let me show you a real session building a billing page for Resiboko.

Step 1: Orient

cd ~/projects/resiboko
claude

> Today we're adding a billing page. Users should be able to 
> see their current plan (Free or Pro), how many expenses 
> they've logged this month, and a button to upgrade to Pro. 
> 
> Stripe is already configured in /lib/stripe.ts. 
> 
> Look at /app/dashboard/page.tsx for the layout pattern 
> to follow — same card-based layout with dark mode support.

Step 2: Plan

> /plan

Claude responds:

Plan for billing page:

Files to create:
1. app/billing/page.tsx
   - Fetch current subscription from Stripe
   - Display plan name (Free/Pro)
   - Show usage count for current month
   - Upgrade button (disabled if already Pro)

2. utils/stripe/getSubscription.ts
   - Helper to fetch subscription status
   - Returns plan tier and usage count

Pattern to follow:
- Match dashboard card layout
- Use shadcn/ui Card components
- Dark mode via Tailwind dark: classes
- Loading state while fetching
- Error state if fetch fails

Dependencies:
- Uses /lib/stripe.ts (already configured)
- Uses Supabase auth for user ID

Estimated steps: 8

Proceed?

I review the plan.

Looks good. I approve:

> Looks good. Go ahead.

Step 3: Execute

Claude Code builds the entire feature.

I don't interrupt. I let it complete the full implementation.

Step 4: Review

> /review

Claude responds:

Review findings:

app/billing/page.tsx:
✅ Follows dashboard layout pattern
✅ Uses shadcn/ui Card components
✅ Dark mode implemented correctly
✅ Loading and error states present
⚠️ Line 34: Upgrade button not disabled when user is on Pro
   Fix: Add disabled={plan === 'Pro'} to Button component

utils/stripe/getSubscription.ts:
✅ No issues found

Summary: 1 issue found. Fix suggested above.

Step 5: Redirect

I give clear feedback:

> Good catch. Fix the button. Also add a percentage label 
> to the usage meter showing how close they are to the 
> free tier limit.

Claude makes both adjustments.

Second review:

> /review

All clear.

Step 6: Ship

> /ship

Claude responds:

Pre-Commit Workflow Complete

1. REVIEW FINDINGS:
✅ No issues found

2. CONVENTION CHECK:
✅ Named exports only
✅ No `any` types
✅ Tailwind utilities only
✅ All files under 150 lines

3. SUGGESTED COMMIT MESSAGE:
add billing page with subscription management

Implemented billing page showing current plan (Free/Pro),
monthly usage count, and upgrade button. Uses Stripe for
subscription data. Matches dashboard layout pattern.

4. FOLLOW-UP TASKS:
- Add Stripe checkout integration for upgrade flow
- Add webhook handler for subscription updates
- Write tests for subscription utils

Perfect. I copy the commit message and commit.

Entire feature. One session. I wrote maybe 6 prompts total.

Orient → Plan → Execute → Review → Redirect → Ship

That's vibe coding.

What Vibe Coding Is NOT

Let me clear up the misconceptions:

❌ Vibe Coding Is NOT Being Lazy

You're not doing less thinking.

You're thinking about different things:

  • What should this feature do?
  • Does this behavior feel right?
  • Is this the right pattern for our codebase?

Those are director questions. They're harder than implementation questions.

❌ Vibe Coding Is NOT Skipping Understanding

You still need to understand the code.

But you understand it by:

  • Reviewing what gets built
  • Using /explain when needed
  • Running /review to catch issues

You understand through direction and review, not through typing every character.

❌ Vibe Coding Is NOT Just Throwing Prompts

There's structure:

  • Orient before starting
  • Plan before executing
  • Review in batches
  • Redirect clearly

It's a system, not chaos.

❌ Vibe Coding Is NOT Only for Simple Tasks

I built both Resiboko and 1MinThumb this way.

Full production apps. Complex features. Real business logic.

Vibe coding scales to any complexity level — as long as you can describe the outcome clearly.

Why This Matters

Vibe coding is not about writing less code.

It's about spending your energy on the decisions that actually matter.

What should this feature do?

Does this behavior feel right?

Is this the right pattern for our codebase?

Is this the user experience we want?

Those are director questions.

Claude Code handles everything below that.

The developers shipping the most right now are not the fastest typists.

They're the clearest thinkers.

They know what they want.

They communicate it well.

They review critically.

They redirect precisely.

That's the skill.

My Raw Notes (Unfiltered)

This is how I built both Resiboko and 1MinThumb even before I had a name for it. Just describing what I wanted and letting Claude figure it out.

The director analogy is the one that clicked for me — I stopped feeling like I needed to know every implementation detail before starting and just started describing outcomes.

The plan first habit is what separates vibe coding from vibe chaos. Without a plan it gets messy fast.

Review in batches not after every change — interrupting too much kills the flow.

The mindset shift is real. Once you stop thinking "how do I implement this" and start thinking "what do I want this to do," everything moves faster.

Tomorrow (Day 15 Preview)

Topic: Feature-First Workflow — building a complete feature from scratch in a single Claude Code session.

What I'm sharing: A complete feature build from empty folder to shipped code. The exact workflow. Every command. Every redirect. Real session, real code.

Following This Series

Phase 2 (Days 8-14): Getting Productive ⬅️ Complete! 🎉

Phase 3 (Days 15-21): Vibe Coding ⬅️ Starting now

So far:

  • Day 8: CLAUDE.md structure and sections
  • Day 9: Writing rules Claude actually follows
  • Day 10: Evolving CLAUDE.md over time
  • Day 11: Slash commands basics
  • Day 12: Building your command library
  • Day 13: Advanced slash commands
  • Day 14: Vibe coding mindset (today)
  • Day 15: Feature-first workflow (tomorrow)

G

P.S. - The mindset shift: stop thinking like a typist, start thinking like a director. That's vibe coding.

P.P.S. - Plan first habit = vibe coding. No plan = vibe chaos. Always use /plan.

P.P.P.S. - Describe outcomes, not implementations. "When this page loads, show the user list" not "write a useEffect that fetches on mount."