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

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.

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.

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. 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.