Skip to content
mcy_
← cd ..
8dcca24

Falling Asleep in the Passenger Seat: Vibe Coding and Your Mental Model

Vibe coding feels great right up until you realize you can no longer say what your codebase actually does. This piece is about that drift: how it sneaks up on you, why agents can't fix it, and the one habit that keeps you in the driver's seat.

3 min read

You started with a clear idea. Three hours of vibe coding later, you couldn’t say what the codebase actually does anymore. Your initial idea has been challenged and amended by the LLM too many times. Fully understanding the impact of every decision would have exhausted you and slowed you down, at least in the short run. So you start accepting decisions you only half understand.

At least, that’s what happened to me.

You end up in the passenger seat

Drift isn’t visible at first. Each individual decision is reasonable, so no single step feels like a loss of control. But the gap between your mental model and the actual code keeps growing.

The usual answer is to set anchors: unit tests, an initial structure, a few clear design principles. Fixed points you can reason from when you’ve stopped following every line.

But the anchors don’t hold. New tests, classes, and modules appear faster than you can keep track of them. At some point, you’re no longer watching the road. You’re just sitting in the passenger seat, waiting for the LLM to take you to its next destination.

The resync habit

Drift will happen, and I’ve stopped pretending otherwise. So resyncing is part of my process now. The longer I wait, the more it costs.

I resync at two points: after a milestone, because that’s when I know where I want to be, or after an exploration, when I’ve let the LLM build a big new feature or change. Then I use the app, see what I actually need, and either restart with a clear spec and scope, or cut the current version down.

At first I intended to write about “anti-drift agents”, as if the right agent could fix this. It can’t. The agents aren’t what helps me. The resync itself is the human effort: the one part of the work I can’t delegate.

How I resync

I know when my understanding has grown too thin: I can’t answer the next decision properly. I don’t need a signal for that, I can feel it. What I need is a fast way to see where the drift is.

That’s the agents’ job. Not to take control, but to tell me where to look. An agent here is nothing fancy: a separate session where I ask an LLM one focused question about the codebase, and read its answer with my own eyes.

Before resyncing, I run a quick cleanup pass: a dead code hunt, a complexity check. These are more about helping the LLM than me: they strip the noise so the next session starts from a clean base.

The main check is a concept drift check: “Which concepts, responsibilities, or naming conventions have changed since the original design?” For that check I need a reference: a short document describing the application’s core ideas and concepts, plus its contracts, the rules that certain modules must respect.

Then comes the part the agents can’t do, the resync session:

  1. Ask the agents to find changes and additions in the concepts, and in the contracts: how far is the code from previous concepts?

  2. Ask why the drift happened: why did we move away from the original ideas?

  3. Update concepts until it’s clear again, for me.

  4. If needed, update the code to match the updated concepts.

Get back in the driver’s seat

The goal isn’t to understand every line of AI-generated code. It’s to know when the code has moved beyond your understanding, and catch it before the gap becomes too expensive to close.

That means making time to stop, look around, and figure out where you are.

Vibe coding gives you speed. Your mental model is the map that helps you choose the right direction. When you can no longer answer the next decision properly, it’s time to stop and resync.

That’s my takeaway: no LLM can put understanding in your head. Only your own effort can, and the resync is that effort. Delegate the typing, keep the understanding, because delegating this effort means giving away your own added value. Otherwise you really do become useless.

It’s also why I don’t believe in the lights-out factory: there is no clear direction to hand over in the first place. It’s the travelling salesman problem: always driving to the nearest town does not give you the shortest path. A factory of agents optimizes locally; someone still has to hold the global route. And that someone can only be you.

It’s your mental model, after all.