Where to start when your vibe-coded app breaks

I get handed broken vibe-coded apps the way some people get handed a box of tangled cables. Something in there worked once, nobody remembers the order it went together in, and now it doesn't. The most expensive instinct in that moment is the one that feels the most productive: open the code and start fixing.

I want to make the case for doing nothing first. Not nothing as in giving up. Nothing as in orienting before you touch a single line, because in a drifting codebase the thing you can see and the thing that is actually running are usually two different things, and you can't fix the first by editing the second.

the forty minutes I spent fixing code that wasn't running

A while back I was chasing a result that would not move. I changed the code, reloaded, nothing. Read it again, found another thing to change, reloaded, still nothing. The screen kept showing me the old behavior while I kept feeding it new fixes, and every dead reload made me more sure the problem was deeper and nastier than it was.

It wasn't deeper. The dev server had outlived its build. It had spun up against an earlier version of the artifact and never restarted, so it was faithfully serving code from forty minutes ago no matter what I saved to disk. I killed the process, served the current build, and the screen immediately showed me the change I had written near the start of the hour. The fix had been right almost the whole time. It just was never the thing running.

That is the trap underneath most "the AI says it fixed it but it's still broken" stories, and it has a name worth keeping. The running app is a surface. It shows you behavior. What is actually built and served underneath it is the semantic reality, and the two drift apart all the time: a stale server, a cache sitting in front, a process that quietly never restarted, a build step that didn't rerun. Surface signals propose. Measuring the real artifact disposes. When you skip that check and start editing, you are debugging a ghost, and the ghost will let you work on it for an hour without ever telling you it isn't real.

orient before you modify

So when a broken vibe-coded app lands in front of me, the first twenty minutes are not coding. They are orientation, and it comes down to three moves.

First, establish what is actually running before any edit. Restart the thing. Confirm the build you are looking at is the build being served, that the URL is the live instance and not a cached tab, that the process came up clean. This is the stale-server check, and it costs a minute. It is the cheapest insurance on the board against spending your morning fixing a version nobody is using. Ground truth first, then opinions.

Second, read before you write. One independent pass over the territory, eyes only, no fixing. You are building a map: where state lives, what calls what, where the thing that broke actually sits. If an agent built the drift, do not let that same agent both diagnose and repair in one breath. A model handed a broken app and told "fix it" will change code confidently and immediately, and confidence aimed at the wrong layer is how the second problem gets born. Separate the reading from the writing, even if you are the only one in the room.

Third, change one thing at a time and keep the blast radius small. In a codebase you don't understand yet, every edit is a hypothesis, not a fix. Make one, watch what it does, keep it isolated enough that when it fails the failure actually teaches you something. Vibe coding is fast at generating; it is just as happy to generate five changes as one, and five tangled changes against an unfamiliar build give you nothing to learn from when the screen stays red.

the failure mode this is steering you around

The trap has a shape, and I have walked into it more than once. You treat the broken screen, or the red error, as a diagnosis instead of a symptom. You re-prompt: "still broken, fix it." More code changes, fast and sure, and now the original fault is buried under a layer of well-meant edits that were aimed at the wrong thing. I told one version of this in the build error that lied, where a reflex install on the wrong package manager turned one problem into two before I stopped to look at the actual state. Same shape every time. A wrong move executed instantly is just a faster route to a worse state. With AI in the loop the speed is the danger, not the help, because the loop will happily sprint in the wrong direction as long as you keep pointing it there.

If you want the triage version of this, the very first things to check the moment an agent breaks something, I wrote that as a first response when an AI coding agent broke your app. This post is the posture underneath it: don't start by fixing. Start by seeing.

If you've inherited a vibe-coded app that's drifting and you want a second set of eyes to think through the orientation with you before anyone touches the code, /work-with-us. Good AI orchestration is mostly this discipline anyway, knowing what is real before you act on it, and it is a lot cheaper to wire in at the start of a rescue than to unwind after a week of confident edits.

The reason this works isn't clever. You can't fix what you can't see, and most of what a broken build shows you is surface. Orient first. Find the ground truth. Then change one thing.