Set a hotfix budget before your vibe coded bug eats the night

A while back I lost the better part of two nights to a scroll bug on this site. Mid-page, at rest, two sections were bleeding through each other. You would scroll down and a headline from one panel would sit ghosted on top of the content of the next, like two slides stuck in the same projector. It looked like a timing problem, the kind where a layout measurement runs a beat too early, so I did what the bug was quietly daring me to do. I started fixing it.

Here is the part that actually saved the night, and it was not a clever fix. Before I touched anything, I gave myself a hotfix budget: two attempts. If the bug was still alive after two real fixes, I was not allowed a third patch. I had to stop and assume I was working at the wrong layer. That rule is the whole post. When your vibe coded app has a bug that will not die, the move is almost never a smarter patch. It is a colder question asked sooner: what layer is this actually in.

why does my agent keep failing to fix the same bug?

Because a failed fix that changes nothing is not a near miss. It is information, and the information is usually "you are aiming at the wrong layer." The trap is that a fix which does not work still feels like progress. The screen shifts a little, some numbers move, the agent reports done, and you file it as "closer" and ask for one more. With an agent in the loop that instinct gets dangerous, because it will write attempt three, four, and five as fast as you can describe them. The speed you love for building is the same speed that lets you stack five confident wrong patches on a cause none of them touched. Nobody sat down and decided to re-prompt a bug ten times. It happened one reasonable-feeling attempt at a time.

A hotfix budget interrupts that. You name a number before you start, while you are still calm and honest, and each failed attempt spends against it. The point of the cap is not discipline for its own sake. It is that hitting the cap forces the one question the momentum keeps you from asking: not "what is a better version of this fix," but "what if this whole category of fix is wrong."

the two fixes that were both aimed at the wrong thing

My first hotfix was legitimate. The scroll wheel had actually died, so I rewired it to be resilient instead of firing once and hoping, and I added a single coordinated refresh so the scroll engine recomputed positions after the deferred pieces loaded. The wheel came back. The bleed did not. I want to be honest about a small thing I did there: when I wrote up that change, I made myself describe it as partial, because the tidy version of the message would have claimed a pass, and claiming a pass on a bug that is still visible is exactly how you lose the next hour.

Second hotfix, one layer up in cleverness. The site loads its scenes code-split, so each one was creating its own scroll triggers on its own schedule, and I figured the bleed was those independent pieces refreshing out of sync. So I routed every scene through one shared, debounced refresh and deleted the standalone calls. Architecturally it was the right thing to do. It was cleaner, it was correct, and it did nothing for the bleed. Same ghosting, same band of the page.

That was the budget gone. Two real fixes, both reasonable, both spent, bug fully alive. The rule said stop, and stopping was the fix.

what the bug actually was

I stopped treating it as a refresh problem and looked at the structure instead, and the cause was sitting in plain sight the whole time. An earlier change had pulled the solid background off the sections and dropped a single fixed canvas behind everything, which left the sections themselves transparent and stacked in the same paint space. Long sections that got pinned during scroll were now see-through panels held in place on top of see-through panels. They were not bleeding because a refresh ran late. They were bleeding because I had made them literally transparent and asked them to overlap. It was never a timing bug. Every refresh fix I wrote, both of them, had been a well-aimed answer to a question the bug was not asking.

This is the whole case for diagnosing before you fix, made concrete. Surface signals propose, and the surface here was screaming "scroll timing" because the artifact was visibly a scroll artifact. But the layer that decides is underneath, and you only get to it by refusing to spend a third patch on the layer that is loud. The hotfix budget is just the mechanism that makes you refuse. It converts a stubborn bug from an endless patch loop into a forced re-diagnosis.

how do I actually run a budget on a stuck bug?

Pick the number before the first fix, when you are not yet frustrated. Two is a good default for a bug you do not understand yet, three if the surface is genuinely noisy. Write down, in one plain sentence, what layer each attempt assumes the bug lives in, because that sentence is what tells you later that all your attempts assumed the same layer. When the budget is spent, do not negotiate with yourself for one more. Change the question instead: list the layers this could live in that you have not touched, the data, the structure, the environment, the build, and go look at the one you have been ignoring. The re-diagnosis is cheap once you let yourself do it. It is the not-letting-yourself that costs the night.

With vibe coding this is not optional hygiene, it is the load-bearing discipline, because the cost of another wrong attempt has dropped to almost nothing and your judgment is the only thing left rationing them. The agent is not going to stop and say "we have tried this three times, maybe it is structural." That sentence is yours to say. I wrote about a cousin of this in the mobile speed win that broke scroll, where three fast hotfixes each corrected the wrong thing, and about the same instinct from the other side in where to start when your vibe coded app breaks. Same root every time: a wrong move executed instantly is just a faster route to a worse state.

If you are staring at a vibe coded site with a bug that will not die and you want a second set of eyes before you spend the third hotfix, /work-with-us. Half of good AI orchestration is just knowing which layer you are actually in before you let the agent start typing.

questions that keep coming up

How big should the budget be? Small. Two attempts for a bug you cannot yet explain, three if the surface is genuinely misleading. The number matters less than naming it before you start, because a cap you set while calm is one you will actually respect while annoyed.

What if I do not know what the other layers are? That is the useful part of hitting the cap. Write the layers you can name, data, structure, environment, build, config, and the fact that your two attempts all lived in one of them tells you where to look next. The gap in your own list is often the answer.

Isn't this just giving up? It is the opposite. Re-prompting the same layer ten times is giving up on understanding the bug in favor of hoping. A budget is you deciding that after two honest tries you are owed a real diagnosis, not another guess.