Stop vibe coding in a fix-it loop

You know the loop. The app mostly works, so you run it, something looks wrong, and you type fix it. The model fixes it. You run it again. Now something else is wrong — maybe the thing it fixed two turns ago. You type fix that too. Forty minutes later you have a working header, a broken checkout, no idea which change did what, and a chat scrollback you would not wish on a code reviewer.

Every person who has built something real with an AI coding tool hits this wall. The usual diagnosis is that the model is not smart enough yet. It is almost never the model. It is that you are asking one conversation to do four different jobs at once, and only one of them is coding.

Thinking of something, deciding whether it is worth doing, working out how to do it, and doing it are four separate activities. In a fix-it loop they collapse into one prompt box, and the collapse costs you more than it looks:

Here is the uncomfortable part. Your ideas, at the moment you have them, are not good yet. They arrive while you are looking at something annoying, they are phrased as complaints, half of them are the same idea wearing different clothes, and a few are actively bad ideas that feel urgent because you just got irritated by them.

That is fine — that is what first thoughts are. The mistake is handing them straight to a model that will dutifully implement all of them, including the bad ones, in the order you happened to think of them.

So put a process between the thought and the execution. It does not have to be heavy:

The difference between prompting and planning is not length. It is what the artifact can do for you once it exists.

Acceptance criteria is the load-bearing row. Everything else is convenience; that one changes the model's behavior. Given a finish line it can check itself against, an agent will keep working until it gets there. Given "fix it," it will stop at the first state that no longer throws — and those two stopping points are very far apart.

Once the plan is written and you have actually read it, the execution side changes character completely. You are no longer supervising a conversation. You are handing over a self-contained unit of work — one issue, with its context, its constraints and its finish line — and letting the model plan, build, and open a pull request against it.

The review gets easier too, because you are no longer asking "is this good code?" in the abstract. You are asking one answerable question: does this do what the issue said? You wrote that issue while thinking clearly, before you were annoyed and eight turns deep.

And when it comes back wrong, you have something the fix-it loop never gives you: a fixed reference point. Either the code missed the issue, or the issue was wrong. Both are fixable. "It still feels broken" is not.

The site you are reading was built this way, and its own history is a reasonable demonstration. The proposal system behind it — database, auth, REST API, password-gated viewer, email, tracking, CLI, admin dashboard — went from nothing to shipped in an afternoon, and the git history shows why that was possible.

Twenty-four minutes from filed to merged is the number people usually react to, but it is the least interesting one. The interesting number is the twenty-nine minutes between the batch of eleven and issue #12 — the time spent writing down what should be built, before anything was.

None of this makes the model smarter. It makes your instructions survive contact with a long session, which turns out to be most of the gap between a demo that mostly works and software you would put a customer on. The fix-it loop has a ceiling, and it is lower than people expect. You can step off it this afternoon, for the price of writing things down first.