Vibe coding is real, useful, and produces working software. It is also, past a certain point, a way of generating a mess faster than any one person can clean it.
The term has come to mean a specific way of working with an agent: open the chat, describe what you want, look at what comes back, run it, describe the next thing, repeat. No upfront design. No structured workflow. No tests, often. Just iteration through conversation until the program does the thing.
The argument against vibe coding has usually been moral: "real engineers don't do this." That argument is not interesting and it is not even right. The interesting argument is structural. Vibe coding works inside a specific envelope, and outside that envelope it produces predictable failure modes. Knowing where the envelope ends is more useful than disapproving of the technique.
Where vibe coding works
There are real categories of work where vibe coding is the correct approach.
Throwaway scripts. A one-off data transformation, a quick automation, something you will run twice and never touch again. The cost of getting it slightly wrong is bounded. The cost of building any scaffolding is unrecoverable. Vibe coding is the rational choice.
Exploration in a new domain. You do not know what you want yet. You are sketching, trying things, building intuition. Imposing structure on a problem you have not understood is premature. Vibe coding lets you find the shape of the problem before you commit to a shape for the solution.
Small, isolated additions to a codebase you understand. A new endpoint shaped like the existing endpoints. A new component shaped like the existing components. You know the patterns; the agent can fill them in. The supervision is light because the risk is light.
Solo projects with no collaborators. You are the entire audience for the code. Future-you might be annoyed, but future-you does not have to coordinate with anyone else about how the code is organized. The cost of incoherence is internal.
In each of these cases, the upper bound on what can go wrong is small. The codebase is not going to grow much. The team is not going to onboard people who need to understand it. The systems it depends on are not going to evolve out from under it. Vibe coding stays inside its envelope because the envelope is tight.
Where it stops working
The same approach, in a larger context, fails in a specific way.
It does not fail catastrophically. There is no single moment when the vibe stops working. It fails gradually, as the codebase accumulates choices that were never coordinated, conventions that were never documented, abstractions that were introduced because the model felt like introducing them, and tests that were never written because the chat was about getting the thing to work, not about proving it would keep working.
The signs are recognizable:
Every new feature takes longer than the last one, not because the system is more complex but because the agent has to spend more context reading the inconsistencies before it can add anything.
Two changes in different files produce conflicting patterns, and nobody can say which one is "right" because there is no document that says.
A regression appears that nobody can trace, because the change that introduced it was made in a chat session that nobody saved.
A new team member joins and asks where the conventions are written down, and the answer is "ask the agent" or "look at recent code," which is the answer that means the conventions do not actually exist.
The agent itself starts producing worse output, because the codebase it is pattern-matching against has become a patchwork of patterns rather than a single coherent style.
None of these are failures of vibe coding as a technique. They are the cost of using a technique past its envelope.
The thresholds
The envelope ends at a few specific thresholds. Crossing any of them is the signal to switch modes.
Codebase size. Once the project is large enough that nobody on the team can hold the whole thing in their head, the agent cannot either. The convention has to be on disk, not in the conversation.
Team size. Once more than one person is contributing, the cost of incoherence falls on people who were not in the original chat. Vibe coding becomes a tax on collaborators. Convention has to be shared, which means written down.
Time horizon. Code that will run in production next year is code that will need to be modified next year, by someone who is not currently in the conversation. The conversation does not survive. The code does. Convention has to be in the code or near it.
Regression risk. The moment a bug in this code could affect a customer, a system, or a number that matters, the cost of "we'll fix it if we notice" exceeds the cost of having tests and a real PR process.
Crossing any one of these is the threshold. The mistake is to keep using the same approach past the threshold because it worked yesterday.
The upgrade path
If you have been vibe coding and you have crossed the threshold, the upgrade is not a return to "real engineering" in some pre-agent sense. It is a transition to a different mode of working with the agent. One in which the harness, the conventions, and the sensors do the work that the conversation was doing implicitly.
The minimum upgrade:
Write down the conventions the agent has been inferring. Move them out of the chat history and into a file the next session loads.
Add the tests for the parts you have been treating as "I'll check it works manually." Future sessions cannot check it manually; the test is what proves it across changes.
Adopt a PR practice. Even for a solo project, the PR is where the change is reviewed and the checks run. It is the gate that turns vibes into commits.
Start a rules file, even a small one. The first three rules in it should be the three things you have corrected the agent on most recently.
None of this is a renunciation of vibe coding. It is the recognition that the technique works inside its envelope, and that outside the envelope a different set of techniques does the same job for a different problem. Use the right one for the situation.
The teams that get into trouble are not the ones that vibe coded. They are the ones that vibe coded past the point where it stopped working and did not notice.
