Vibe coding works. That is the part people arguing about it keep skipping. You describe what you want, the model writes it, you run it, and there is a thing that did not exist an hour ago.
Where it stops working is specific and it is worth naming, because the failure is not "the code is bad". The code is usually fine. The failure is that you no longer know what is in it, and every further change has to be described to a model that also does not know, because the description of the system now lives nowhere.
The shape of the wall
It goes like this. The first ten changes are fast. Around change fifteen something breaks that you did not touch. You describe the bug, the model fixes it, something else breaks. You describe that. By change twenty-five you are spending more time explaining the current state of the app than describing what you want, and the model is spending more tokens re-reading files to work out what previous sessions did.
Nothing failed. You just crossed the point where the system is bigger than what either of you is holding in your head, and neither of you wrote anything down.
Four habits push that wall a long way out. None of them require you to become a software engineer.
1. Make it work, then make it stop
The single highest-value habit: after anything works, get it into a state you can return to.
A commit. A copy of the folder. A duplicated file. Whatever you will actually do. The mechanism matters less than having one, because the alternative is that every session risks the thing that was already working.
The reason this matters more with an agent than without: an agent edits several files at once. When a change goes wrong it goes wrong across the codebase, and "undo" is not one keystroke. Codoro keeps edits behind an approved diff and has optimistic undo, which helps within a session. It does not help you get back to Tuesday.
2. Ask for the plan before the edit
Two-thirds of expensive sessions start with a task the model understood differently from you.
Ask what it is going to do first. Read it. Correct the part that is wrong. Then let it write.
This costs one cheap turn and routinely saves ten expensive ones, because a plan you disagreed with is caught before any code exists rather than after you have reviewed a diff built on it. It also gives you something to hold the result against — you can tell whether the change matches the plan without reading every line.
3. Say what not to touch
Models are helpful in a way that is occasionally destructive. Asked to fix the signup form, a model will happily also tidy the CSS, rename a variable it finds confusing, and update three unrelated files it read on the way.
Bound it explicitly: "change only the signup form; do not touch anything else." Then look at which files the diff touches before approving. If a file you did not expect is in there, that is the whole signal — you do not need to read the change to know something went sideways.
4. Keep a file that says what this is
One plain text file. What the app does, what the main pieces are, what you have decided not to do, what is currently broken.
This is the one that pushes the wall furthest out, because it is the missing artefact. Every session starts by re-deriving context from the code. A file that states it means the model reads a paragraph instead of reading eight files — cheaper, faster, and more likely to be right, because a paragraph you wrote is a better description of your intent than the code is.
Codoro reads scoped rules from .codoro/rules/*.md, which is a formalised version of the same idea.
A text file in the repo root works nearly as well.
Where the money goes
Worth understanding, because the bill is the thing that makes people stop.
Each turn re-sends the whole accumulated conversation as input. Turn twelve carries turns one through eleven — the files read, the diffs proposed, the tool results, everything. So a long session is not linear, it is a curve, and a task that spirals is the expensive event.
Which is why the habits above are also the cost controls. A plan agreed in one cheap turn prevents ten expensive ones. A bounded task reads fewer files. A context file replaces an exploration phase.
Concretely: set a per-run cap. Codoro's default is $2.00 per task, editable, with a $25.00 daily backstop. Set it at something you would be annoyed to hit — a cap above your worst case has never fired and is not protecting you. When it does fire, the run pauses and offers a cheaper model rather than silently switching, so you decide.
If you have your own API key from a provider, use it: the markup is 0%, the key stays in the macOS keychain, and the caps still apply. Hosted credits carry a 40% markup on cost, which pays for one bill and no key management and nothing else.
The honest limit
None of this makes you able to fix what you cannot read. There is a point where an app needs someone who understands it, and the habits above buy you time and a better handover rather than immunity.
What they reliably prevent is the specific failure of arriving at that point with no idea how you got there — which is the difference between "this needs a developer now" and "this needs a developer and nobody can tell them what it does".
Status
Codoro is in preview for macOS. There is no public download yet — the download page is a waitlist until a signed release manifest says otherwise. Everything above works in any agentic editor; the caps, the approved-diff flow and the scoped rules are how Codoro does it specifically.