Vibe coding: not the prompt, the limits

The question is not whether a coding agent writes good code. It writes good code. The question is whether it writes the code that belongs in your project. Those are not the same thing, and the difference is not decided in the prompt. It is decided by the limits you drew beforehand.

What is vibe coding, and where does it stop working?

Vibe coding means checking the result without understanding the path to it. You describe what should come out, look at whether it runs, and carry on. That is a legitimate way to work, and I use it myself. For a prototype meant to answer one question and then be thrown away, it is even the right choice.

It breaks the moment someone has to maintain the result. Not because the code is bad, but because nobody knows any more why it looks the way it looks. The mistake is rarely vibe coding as such. The mistake is vibe coding somewhere the code is meant to stay.

Why does the AI not take the clean path on its own?

Because “clean” is not a property of the code. It is a property of the relationship between the code and your project, and the model does not know that relationship. It sees what you show it and infers from everything else it has seen. Three patterns kept coming back.

It rebuilds instead of looking. A helper it needs, it writes. That the project already has that helper is something it learns only by checking, and checking costs steps. The result runs, it is even written well, and it is still the third version of the same thing.

It optimises for the green tick.“Done” means tests pass and the typecheck is clean. Whether the path there is one you will still want to understand in six months appears in none of those checks. An agent aiming at completion finds the shortest route to it, and the shortest route rarely ages best.

When a rule is in the way, it removes the rule. This one cost me the most before I understood it. There is no ill will in it, it is again just the shortest solution. An eslint-disable removes an error message more reliably than a restructure does, and formally the run is green afterwards. If you only look at the result, you will not notice.

What helps?

Limits rather than instructions. An instruction is a suggestion the model weighs against other goals. A limit is something it fails against. I now carry a fixed set of rules into every new project, and four insights from that made the largest difference.

A rule that is not machine-checked does not exist. A convention in a document nobody executes is a request. Only when a run turns red is it a rule. The same is true for people, it just shows up more slowly. With an agent making twenty changes an hour, it shows up immediately.

The safest path is the one where the wrong path does not exist. Instead of writing that nobody should access the database directly, build the application so there is no route there. No access, no violation. What is not there cannot be misused, and you no longer have to explain it either. This is where architecture is worth more than any rules file.

Context is a budget, not a shelf. Everything loaded into every session competes with the actual task for attention. My permanent rules are therefore short, a few lines per area, essentially prohibitions and a pointer. The reasoning and the detail live in separate documents and get read when they are needed. Sending everything every time only moves the problem.

Prohibitions are more precise than preferences. “Prefer X” leaves room, and room gets used. “Never Y, always X” leaves none. I rewrote my rules from the first form into the second over time, and the hit rate rose noticeably. It sounds harsher than it is. An agent will not hold it against you.

What does it cost?

Preparation that does not pay for itself in the first project. If you are building something once and it can go afterwards, do not spend the time. From the second project on it carries, because you bring the same base and only adapt it.

And the effort is not one-off. Rules go stale, because libraries change and because you learn. A rule that no longer holds is worse than none: it creates friction where there should be none, and eventually you switch it off yourself. Then you are back at the start.

Where this stops holding

Limits do not replace judgement. They prevent the mistakes you already know about, not the ones you have not made yet. No set of rules will spot that a data model is cut wrong, or that the requirement you are having cleanly implemented was the wrong requirement. That stays your work.

What you gain is the attention for it. You stop spending it on helpers that already existed and on disabled checks you only notice three weeks later. That is the whole point of agentic engineering: not trusting the model with more, but setting the frame so its capability lands where it counts.