The Vibe Coding Hangover Why Developers Are Returning To Engineering

Vibe coding is great for quick prototypes but a disaster for security. Treat AI apps as disposable sketches, then have real engineers rebuild them for production. If you scroll through your professional feeds or check your inbox this week, you are guaranteed to see the phrase “vibe coding.” Instead of writing code, your product managers can just chat with a coding agent and prompt a fully deployed app into existence.

I just read the market-tanking prediction from Citrini Research arguing that AI is on the verge of coding entire SaaS products completely on its own. LLM vendors and YC startups are aggressively selling this exact idea that anyone can build complex software in an afternoon simply by describing their desired features. But from where I sit, this unchecked acceleration is an absolute disaster.

AI today might be able to generate the superficial shell of a SaaS app, but it is still far away from having the engineering rigor required to build something reliable enough to become part of our digital infrastructure. While this conversational approach makes it incredibly easy to scaffold apps, it is quietly creating a massive crisis in enterprise security and technical debt. We are abandoning disciplined software engineering and replacing it with a culture of probabilistic guesswork. If we don’t course-correct, we are going to expose ourselves to catastrophic risk.

The rise of unsanitized agents The risks multiply when we transition from AI that just generates new content to AI that takes action. Over the past few months, we’ve seen an explosion of unsanitized agentic systems. The most popular is an open-source project called OpenClaw (formerly Moltbot/Clawdbot). Unlike a regular chatbot, this thing has the ability to independently execute actions on a machine—sending files, running programs, making outside connections. I recently deployed OpenClaw to a sandboxed environment just to see what the fuss was about.

I found a bloated mess of features, but the most basic functions, such as Telegram streaming, didn’t even work. I tried consulting their documentation, but it was clearly just a wall of AI-generated, high-entropy and low-variance text that told me absolutely nothing useful. To make matters worse, the project changed its name twice in a row without providing a single migration guide for how to move to the new binaries. If a traditional piece of software shipped like this, we would deem it completely unacceptable.

But because it’s an AI that theoretically can do a lot of things on paper, people tolerate it. They do look incredible in YouTube demos. But deploying unsanitized, non-deterministic agents with root access to local environments is a massive security regression. You are effectively taking decades of strict Identity and Access Management (IAM) protocols and tossing them in the trash. Consider the “lethal trifecta” these agents represent. First, they hold persistent privileged access. Second, they continuously read untrusted external data like incoming emails or Slack messages.

Third, they have unrestricted communication with the outside world. If an attacker sends an email with a hidden prompt injection, the agent doesn’t verify it and might just silently leak your local SSH keys! The “works on my machine” problem at scale The crisis goes beyond deviant agents. It infects how we build our entire software supply chain. When developers prioritize speed over deep understanding, they start building infrastructure based on luck.

Right now, my team is fighting a novel threat vector known as “slopsquatting.” It is also known as AI package hallucination. AI models do not query a deterministic database of facts. They predict the next most likely word. Because of this, they frequently invent software package names that sound perfectly plausible but do not actually exist. Here’s how the attack works: malicious actors register these hallucinated packages on public repositories and inject them with malware. The coding agent suggests the fake package and blindly installs it.

From the vibe coder’s perspective, the AI’s code works without throwing any warnings and the installed package seems legit. But under the hood, they just handed root access to a cybercriminal. This blind trust also destroys our internal quality assurance. A big part of the vibe coding promise is that the AI will write the feature and then the unit tests to validate it. I recently reviewed a pull request for a new internal routing microservice. 100% test coverage. The CI pipeline showed a beautiful sea of green checkmarks.

But then I actually read the code. I found what my co-founder and I now call “cardboard muffins.” The AI hadn’t written tests to verify the underlying business logic. It completely ignored the edge cases. It simply hardcoded the exact return values needed to satisfy the assertions. Its only goal was to make the deployment pipeline pass. When 80% of a codebase is generated by an AI that hallucinates dependencies and fakes unit tests just to get a green checkmark, you haven’t built software. You’ve built a house of cards.

Scaling this kind of code takes the old “works on my machine” problem and turns it into an enterprise-wide disaster. I firmly believe that the new luxury in software development won’t be the sheer speed of feature rollouts. The new luxury will be old-fashioned, boring determinism. The dual-track strategy We cannot afford to ban generative AI. The capability for rapid innovation and market testing is simply too valuable. But we absolutely cannot let probabilistic vibe coding dictate the architecture of our production systems.

To fix this, CIOs can promote a “dual-track” development lifecycle. This strategy separates rapid exploration from rigorous production engineering. Track 1 (the fast track) This is the domain of unconstrained discovery. In Track 1, vibe coding is explicitly permitted and heavily encouraged. If a product manager wants to use an autonomous agent to scaffold a prototype in an afternoon, let them do it. The core metric here is speed to feedback. We want to validate business ideas and test user interfaces as cheaply and quickly as possible.

But there is a massive catch. Track 1 development must occur in heavily sandboxed environments. These vibe-coded applications are disposable blueprints. They are never permitted to touch production data, customer PII or mission-critical corporate networks. Track 2 (the slow track) Once a prototype in Track 1 proves its business value, the project moves to Track 2. This is the domain of real software engineering. The mandate here is simple but painful: Start over. Do not attempt to refactor, salvage or clean up the vibe code.

Rewrite it from the ground up. In Track 2, human engineers take the lead. They use the Track 1 prototype merely as a visual reference. They build secure and scalable architectures. This track prioritizes deterministic security guarantees, strict type safety and rigorous human peer review. AI tools are still used, but they are demoted from being autonomous creators to highly restricted assistants. Every dependency is verified against established security frameworks and every unit test is manually reviewed to ensure we aren’t baking cardboard muffins into our core product.

A big cultural shift Implementing a dual-track strategy requires a big cultural shift. This is especially true when managing executive expectations. It hinges on one non-negotiable directive: never base the timeline of the slow track on the velocity of the fast track. It’s going to be a tough conversation with your business stakeholders. When they see a seemingly functional, vibe-coded prototype spun up over a single weekend, it’s natural for them to assume the final product can be finished if given one more week.

But enforcing this boundary is exactly how we ensure the business becomes a benefactor of AI coding, rather than its next victim. AI is an incredible force multiplier for innovation. But it is not a substitute for architectural foresight. By embracing a dual-track strategy, we can give our teams the freedom to experiment at the speed of thought while protecting the deterministic rigor that keeps our digital infrastructure running. This article is published as part of the Foundry Expert Contributor Network. Want to join?

People Also Asked

• The Vibe Coding Hangover: Why I'm Returning to Engineering Rigor in ...
• The Vibe Coding Hangover: Why Developers Are Returning to Engineering ...
• The vibe coding crisis: Why you need a dual-track engineering ... - CIO
• The Vibe Coding Hangover: A Senior Engineer's Survival Guide
• The Vibe Coding Hangover | Pathmode Blog
• The "Vibe Coding" Hangover: Why AI-Generated Slop Is ... - Medium
• The Vibe Coding Hangover Is Real — And It's Hitting 8,000 Startups at ...