When it comes back wrong

You ran it. Something is off.

This is the normal state of a build, not a setback. What matters is what you type next, and there is a right shape for it.

Describe the symptom, not the cure

The instinct is to diagnose:

You forgot to use local storage. Add local storage.

Sometimes right. Often not — and when it is wrong, you have just sent the agent off to fix a thing that was not broken, and it will comply, because it complies.

The better message:

I added two links, refreshed the page, and the list was empty.
I expected the links to still be there.

Three facts: what you did, what you expected, what happened. That is a bug report, and it is the highest-value message in vibe coding.

Now the agent can investigate. Maybe local storage was never wired. Maybe it saves but reads back wrong. Maybe it saves fine and the render on load is broken. You did not know which, and now you do not have to.

One problem at a time

You will spot four things at once. Send one.

Batched corrections produce batched changes: the agent touches four areas in one pass, and if the result is worse, you cannot tell which change did it. You have also just made the diff too big to read, which matters more than it sounds — level 3 is entirely about reading changes.

Order them by how much they block you:

1. It does not run at all.
2. It runs but the core thing does not work.
3. It works but behaves oddly.
4. It looks wrong.

Fix downward. Cosmetic issues last, always — half of them disappear on their own when the structural ones are fixed.

Repeat the constraint that got dropped

Agents drift. You said “no dependencies”, and three messages later there is a package being installed.

This is not defiance. Your constraint is far back in a long conversation, and the most recent instruction dominates. Restating it costs one line:

Reminder: one HTML file, no dependencies. Undo the package you just added.

If a constraint keeps getting dropped, that is a signal to put it somewhere permanent — a project notes file the agent reads every time. That is the subject of the next level.

When to throw it away instead

Not everything is worth correcting. Use this split:

Steer when the shape is right. Right kind of page, right technology, right general structure, wrong details. Correcting is fast and each fix compounds.

Restart when the shape is wrong. You wanted one file and got a project with a build system. You wanted local storage and got a login screen. You asked for a page and got a command-line tool.

Restarting feels like a defeat and is usually the fastest route. You are not going back to zero — you are going back with a much better brief, because you now know exactly which assumption was missing.

Let's start this file over. Same goal, but strictly one HTML file
with inline CSS and JavaScript, no build step and no packages at all.

The trap: fixing it yourself too early

You spot the wrong number, you know where it is, and it would take you ten seconds to change by hand.

Fine — as long as you tell the agent afterwards. What breaks sessions is silent hand-editing: the agent’s picture of the file is now out of date, and the next thing it writes will be based on a version that no longer exists. It may overwrite your fix, or build on an assumption you already removed.

If you edit by hand, say so:

I changed the button label to "Save link" myself. Keep that.

The loop, in practice

Run. See something specific. Report it as action-expectation-observation. Run again.

Four or five rounds of that and Readlist works. Not because any single message was clever — because none of them tried to do too much.

Try it yourself

The result misses the point. Pick your way out.