Vibe coding with Claude Code: what the third hour looks like

Quick Answer (June 2026): Hour three of vibe coding with Claude Code is where the magic wears off and the real work begins. The agent starts drifting (re-implementing helpers, calling renamed props, hedging in prose), and your job shifts from passenger to navigator. The rituals that keep the session productive: commit at every green moment so the agent has clean checkpoints, re-ground the context against real files every 30 to 40 minutes, narrow the agent's scope when it wanders, and start a fresh session when the context is too poisoned to save. Flow is a tool, not the goal. The agent supplies momentum. You have to supply the brakes.

It's hour three. The easy part is long gone. The first hour of a vibe-coding session with Claude Code is basically a magic trick: you describe a feature, it scaffolds the routes, wires the components, and you nod along like a producer approving takes. But the third hour is where the real work lives, and it looks nothing like the demo videos. This is a field note about what actually happens deep in a session, when the dopamine has worn off and the codebase has opinions.

I'm writing this the same day I shipped a feature this way, so it's fresh. Let me tell you what hour three feels like, where it goes wrong, and the small rituals that keep it from turning into a debugging swamp.

The first hour lies to you

The first hour is frictionless because the agent is operating on a clean slate. There are no constraints yet. No half-built abstractions to respect. No naming conventions it has to honor. It can just generate.

So you get this false read on velocity. You think, this is incredible, I'll have the whole thing done by lunch. You stop reading diffs carefully. You start hitting accept on autopilot. That's the trap.

Because every line the agent writes in hour one becomes context it has to reason about in hour three. The codebase it generated is now the codebase it has to navigate. And it navigates its own code with the exact same confidence whether that code is good or quietly wrong.

The lie of the first hour is that velocity is the metric. It isn't. The metric is how much of what got built you actually understand. If that number is low, hour three is going to collect the debt with interest.

What the third hour actually looks like

By hour three the shape of the session has changed. The agent is no longer generating from nothing. It's editing, threading state through three files, reconciling a type it defined ninety minutes ago with a new one it needs now.

This is where context drift shows up. The agent starts referencing a function signature that used to exist but you refactored together an hour back. It confidently calls a prop that got renamed. It re-implements a helper that already lives two directories over, because that helper has scrolled out of its working memory.

None of this is dramatic. That's the dangerous part. It's not a crash. It's a slow accumulation of small, plausible wrongness. The code compiles. The page renders. And somewhere in there a date is being formatted in the wrong timezone because the agent guessed at a convention instead of checking.

The tells that drift has set in

I've learned to watch for specific signals rather than vibes:

• The agent re-explains something it already established earlier in the session, as if it's the first time. Memory is fraying.
• It proposes a "small refactor" that touches files unrelated to the task. It's lost the thread of what we're actually doing.
• Diffs start getting bigger for smaller asks. A one-line behavior change comes back as forty lines.
• It starts hedging in its prose: "this should work," "you may need to adjust." Confidence dropping is information.

When two of these show up in a row, that's my cue. The session needs an intervention, not another prompt.

Taking the wheel back

Taking the wheel back doesn't mean firing the agent. It means changing my role from passenger to navigator. I stop asking for features and start asking for inventory.

I'll say something like: list every file you've touched this session and one sentence on what each now does. That single request does two things. It forces the agent to rebuild an accurate map of its own work, and it shows me exactly where its mental model has diverged from reality.

Half the time the act of listing surfaces the bug on its own. The agent writes out "formats the date for display" and I go, no, that one is supposed to store UTC, and we've found the drift before it shipped.

The rituals that keep it productive

Past the first hour, vibe coding stops being about prompting and starts being about session hygiene. Here are the rituals I actually run.

Commit at every green moment

The moment something works, I commit. Not when the feature is done, when any coherent piece is done. A working session is a series of save points. If hour three goes sideways, I want to roll back to a known-good state, not untangle four overlapping half-changes.

This also gives the agent honest checkpoints. A clean git history is the cheapest context summary that exists. When I tell it "we're back to the state after the auth commit," that's a precise, verifiable anchor.

Re-ground the context on purpose

Every 30 to 40 minutes I re-ground. I paste the current type definitions back in, or point the agent at the actual file instead of trusting its memory of the file. The cost is a few seconds. The payoff is the agent reasoning about what exists rather than what it remembers existing. On the token side, how Claude prompt caching actually pays off on a long session is mostly a function of how steady your re-grounding rhythm is.

Here's the kind of re-grounding prompt I keep around. Boring, deliberate, effective:

# Re-ground prompt I drop in around hour two

Before we continue, do NOT write code yet.

1. Read these files fresh and summarize their current shape:
   - src/lib/orders.ts
   - src/app/api/orders/route.ts
   - src/types/order.ts

2. List any place where the types and the API route disagree.
3. Then propose the smallest change for the task. Wait for my go.

The "wait for my go" matters. It puts a human gate between the agent's plan and the agent's edits, which is exactly the gate that erodes when you're in flow.

Keep one source of truth outside the chat

The chat context is volatile. So I keep the real spec somewhere durable, a scratch file or the task description, and I refer the agent to it instead of to our conversation. The conversation is where we think; the file is where we agree. Totalum, the AI app builder I'm using, leans on a project guide and docs the agent reads on demand, and treating those as the canonical memory rather than the chat history has saved me more than once.

Narrow the agent's blast radius

When I sense drift, I shrink the scope hard. Instead of "fix the orders flow," I say "in this one function, the total is off by the shipping cost; show me only that function's diff." Small, surgical, reviewable. A drifting agent given a wide scope produces a wide mess. The same agent given a narrow scope produces a clean fix, because there's less room to guess.

Flow state is real, and it's a tool not a goal

I won't pretend the flow isn't intoxicating. There's a genuine state where you and the agent are passing the ball back and forth and the feature is just appearing. It's one of the best feelings in this job right now.

But flow is a tool, not the goal. The goal is working software I understand. Flow that produces code I can't vouch for isn't productivity, it's gambling with extra steps. So I let myself enjoy the flow in hour one and I get suspicious of it in hour three. Same feeling, different meaning depending on where in the session I am.

The version of me that's good at this isn't the one who prompts fastest. It's the one who knows when to break the flow on purpose. To stop, commit, re-ground, and read the diff like I mean it. The agent supplies momentum. I have to supply the brakes, because it never will. It's happy to drive at full speed off a cliff and narrate how clean the road looks.

Knowing when to stop the session entirely

Sometimes the right move at hour three isn't to re-ground. It's to quit.

If I've re-grounded twice and the agent keeps reintroducing the same confusion, the session is poisoned. The context has too much contradictory history in it. The fix is brutal and simple: start a fresh session. New context window, a tight summary of the current state, the relevant files attached. It's like the agent took a nap and woke up clear-headed.

I used to resist this because it felt like losing progress. It isn't. The progress is in the committed code, not in the chat. A fresh session with a clean prompt and the real files beats a three-hour conversation carrying ninety minutes of dead context. Every time.

Funny how this maps onto the user-facing side too. The same way I burn a poisoned session and start clean, my users sometimes burn a half-streamed answer and reload the tab. The fix on the server side is a tiny ring buffer and the platform's Last-Event-ID header, and the resume-Claude-streams writeup on AgentNotebook walks the whole pattern end to end, with measured numbers from a real run.

I've changed a lot of habits around this over the past year, and a bunch of them ended up baked into my editor too, which I wrote about in ide-settings-changed-after-year-ai-pair-programming. If you want the agent to re-ground against live project state instead of its own memory, wiring it up properly matters, and I walked through that in wiring-mcp-server-ide-30-minutes.

The actual takeaway

Hour three is the real test of whether you're good at this, not hour one. Anyone can ride the first hour. (Worth reading: Anthropic's own engineering team talks about the same drift-and-discipline pattern across their internal Claude Code use.) The skill is everything after the easy magic runs out: spotting drift early, taking the wheel back without killing the agent, committing at every green, re-grounding on purpose, and knowing when the session is too far gone to save.

Vibe coding isn't vibes all the way down. The vibes get you started. Discipline gets you shipped. The agent is an extraordinary collaborator and a terrible auditor of its own work, and the third hour is exactly where that distinction starts to cost you. So I let it run, and I stay ready to take the wheel.

FAQ

What is vibe coding?
Working with an AI agent in a flow state where you describe outcomes and the agent generates the code, while you steer, review, and commit. Hour one feels frictionless. Hour three is where the real skill lives, because the agent is now reasoning about code it generated earlier and the small wrongness compounds.

Why does Claude Code drift in long sessions?
The agent's working memory has a budget. By hour three it's referencing function signatures that got refactored, calling renamed props, and re-implementing helpers that already exist. The codebase it generated in hour one is now the codebase it has to navigate, and it navigates its own code with the same confidence whether that code is good or quietly wrong.

How do I tell when an AI agent is losing the thread?
Watch for four tells: it re-explains something it already established, it proposes "small refactors" that touch unrelated files, diffs get bigger for smaller asks, and its prose starts hedging ("this should work", "you may need to adjust"). When two of these stack in a row, the session needs an intervention, not another prompt.

Should I just start a fresh Claude Code session when things go sideways?
Yes, if you've re-grounded twice and the agent keeps reintroducing the same confusion. The progress is in the committed code, not in the chat. A fresh session with a clean prompt and the relevant files attached beats a three-hour conversation carrying ninety minutes of dead context.

What does "re-grounding" mean in practice?
Every 30 to 40 minutes I drop a "do not write code yet, read these files fresh and summarize them, list any place where the types and the API route disagree, then propose the smallest change for the task" prompt. The "wait for my go" line matters. It puts a human gate between the agent's plan and the agent's edits, which is the gate that erodes when you're in flow.

Is flow state actually productive when vibe coding?
Flow is intoxicating but it's a tool, not the goal. The goal is working software you understand. Flow that produces code you can't vouch for isn't productivity, it's gambling with extra steps. Let yourself enjoy it in hour one and get suspicious of it in hour three.