{"slug": "when-vibe-coding-stops-working", "title": "When Vibe Coding Stops Working", "summary": "A developer has identified the structural limits of \"vibe coding\"—a conversational, test-free approach to building software with AI agents. The technique works well for throwaway scripts, solo projects, and small additions to familiar codebases, but predictably fails as the codebase grows, introducing uncoordinated patterns, undocumented conventions, and untraceable regressions. The envelope ends at thresholds like codebase size and team onboarding, where the cost of accumulated inconsistency outweighs the speed of iteration.", "body_md": "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.\n\nThe 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.\n\nThe 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.\n\nThere are real categories of work where vibe coding is the correct approach.\n\nThrowaway 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.\n\nExploration 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.\n\nSmall, 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.\n\nSolo 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.\n\nIn 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.\n\nThe same approach, in a larger context, fails in a specific way.\n\nIt 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.\n\nThe signs are recognizable:\n\nEvery 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.\n\nTwo changes in different files produce conflicting patterns, and nobody can say which one is \"right\" because there is no document that says.\n\nA regression appears that nobody can trace, because the change that introduced it was made in a chat session that nobody saved.\n\nA 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.\n\nThe 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.\n\nNone of these are failures of vibe coding as a technique. They are the cost of using a technique past its envelope.\n\nThe envelope ends at a few specific thresholds. Crossing any of them is the signal to switch modes.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nCrossing any one of these is the threshold. The mistake is to keep using the same approach past the threshold because it worked yesterday.\n\nIf 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.\n\nWrite down the conventions the agent has been inferring. Move them out of the chat history and into a file the next session loads.\n\nAdd 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.\n\nAdopt 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.\n\nStart 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.\n\nNone 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.\n\nThe 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.", "url": "https://wpnews.pro/news/when-vibe-coding-stops-working", "canonical_source": "https://dev.to/tacoda/when-vibe-coding-stops-working-3nkc", "published_at": "2026-05-29 20:21:31+00:00", "updated_at": "2026-05-29 20:41:04.713695+00:00", "lang": "en", "topics": ["ai-agents", "generative-ai", "ai-tools", "ai-products", "large-language-models"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/when-vibe-coding-stops-working", "markdown": "https://wpnews.pro/news/when-vibe-coding-stops-working.md", "text": "https://wpnews.pro/news/when-vibe-coding-stops-working.txt", "jsonld": "https://wpnews.pro/news/when-vibe-coding-stops-working.jsonld"}}