• What vibe coding actually is
• The Huntarr pattern
• The invisible debt
• The numbers are getting worse
• Why this is different from normal bad code
• The blast radius problem
• What happens next

A few weeks ago, someone on Hacker News posted about helping their dog vibe code video games. The post got over a thousand upvotes. People thought it was hilarious. The joke was that the dog, obviously, had no idea what the code did. The dog was just pressing buttons and watching things happen.

The same week, on r/selfhosted, a security researcher posted a routine audit of a popular open-source application called Huntarr. He found 21 security vulnerabilities, including one that let anyone on the internet pull every password and API key stored in the application with a single command. No login required. No authentication of any kind.

The developer of Huntarr claimed to work in cybersecurity. He said he had spent over 120 hours in four weeks building the project with AI-generated “steering documents” for security hardening. When the vulnerabilities were posted publicly, he didn’t fix them. Within an hour, he deleted the GitHub repository, nuked his Reddit account, and made the project’s subreddit private. He disappeared.

Here is what connects the dog and the developer: neither one understood the code they were shipping.

§What vibe coding actually is

Andrej Karpathy coined the term “vibe coding” in early 2025. He meant it as a description of a workflow: you describe what you want to an AI, it writes the code, you run it and see if it works. If it doesn’t, you describe the problem and the AI tries again. You never read the code line by line. You never need to understand what it does internally. You just check whether the output matches what you wanted.

For personal projects, throwaway scripts, weekend experiments, this is fine. Maybe even great. The barrier to building things has never been lower. If you want a tool that renames your files or scrapes a website or generates a playlist, vibe coding will get you there in minutes instead of hours.

The problem starts when vibe-coded software leaves the laptop. When it gets shared on GitHub, promoted on Reddit, installed by strangers, connected to the internet, integrated with systems that hold real credentials. The developer built it by checking whether the output looked right. They never checked whether the internals were right, because they never read the internals. They couldn’t. That wasn’t the workflow.

The code is a black box to the person who “wrote” it. And the box works fine, right up until it doesn’t.

§The Huntarr pattern

The Huntarr incident is worth understanding in detail because it’s not an edge case. It’s a template.

The application was designed to sit on top of a stack of media management tools, connecting to Sonarr, Radarr, Prowlarr, and similar services. These tools have years of security hardening behind them. Huntarr punched a hole through all of it.

The researcher who audited it found that the most sensitive API endpoint in the entire application, the one that returns configuration data including every connected service’s API keys, had been explicitly whitelisted to skip authentication. Not accidentally. The code contained a deliberate list of endpoints that didn’t require login, and the settings endpoint was on that list.

How does this happen? It happens when the developer asks an AI to “make the settings page work” and the AI generates code that skips auth to get the page loading. The developer sees the settings page load. It works. They move on to the next feature. They never read the authentication module because they didn’t write it. The AI wrote it, and the AI doesn’t understand security architecture any more than the developer does. It just produces code that makes the immediate request succeed.

The security researcher described finding this with “basic code review and standard automated tools. The kind of stuff any maintainer should be running.” The vulnerabilities were not subtle. The 2FA enrollment endpoint was unauthenticated. The setup-clear endpoint could be called by anyone, allowing a complete account takeover. There was a textbook Zip Slip vulnerability, a path traversal bug that let anyone delete arbitrary directories. Twenty-one findings total, several of them critical.

The post on r/selfhosted got nearly nine thousand upvotes and over a thousand comments. One commenter, with 673 upvotes, put it simply: “I think vibecoding is one of the biggest threats to selfhosted apps right now.”

Another described the broader shift: “I really like finding neat little projects on GitHub to mess around with and boy howdy have I seen some shit over the past year or two.”

§The invisible debt

There is a concept in software engineering called technical debt: shortcuts taken during development that create future maintenance costs. Every developer knows about technical debt because they can see it. They wrote the shortcut. They know what they skipped.

Vibe-coded software creates something different. Call it blind debt: maintenance costs from code that nobody, including the person who shipped it, has ever understood. You can’t estimate it because estimation requires comprehension. You can’t prioritize fixing it because you don’t know where the worst problems are. The developer has no mental model of the architecture. The AI has no persistent understanding of what it built. Nobody holds the map.

When things go wrong, the typical response is exactly what the Huntarr researcher predicted: “The maintainer will most likely prompt these problems away, feed the findings to an AI and ship a patch. But fixing 21 specific findings doesn’t fix the process that created them. The next batch of features will have the next batch of vulnerabilities.”

This is what I think of as the Vibe Code Time Bomb. Every feature adds code nobody understands. Every integration adds an attack surface nobody mapped. The application grows, the users pile up, and the blast radius of the eventual failure grows with them. The developer isn’t malicious. They’re building a house they’ve never seen the blueprints for.

§The numbers are getting worse

A Natively analysis of AI-generated code found that 45% contains security flaws. Wiz Research, the cloud security company, investigated applications generated by vibe coding tools and found that one in five exposed organizations to security risk. They also discovered an AI-built social network called Moltbook that had 1.5 million API keys exposed in its frontend code, visible to anyone who opened the browser’s developer tools.

Ravenna.ai documented 69 vulnerabilities across popular vibe coding tools themselves, not in the code they generate, but in the tools people use to generate it.

Meanwhile, adoption is accelerating. Over 80% of developers are using or planning to use AI code generation, according to a Keywords Studios survey. The new wave isn’t professionals using AI as an assistant. It’s people who have never written code using AI as a replacement for learning how to.

The selfhosted community noticed. Subreddits that used to surface interesting hobby projects are now, as one commenter put it, flooded with “vibecoded trash” and “clones of existing projects.” The signal-to-noise ratio shifted because the barrier to publishing a project dropped to near zero while the barrier to publishing a secure project stayed exactly where it was.

§Why this is different from normal bad code

People have been writing bad code forever. The difference with vibe-coded software is the developer’s relationship to the badness.

A traditional developer who writes a security vulnerability has usually made a specific mistake. They forgot to validate an input. They trusted a header they shouldn’t have. They can be told about the mistake, understand it, and fix it, because they understand the system they built. The fix improves their understanding. They are unlikely to make the exact same mistake in the same project.

A vibe-coding developer who ships a vulnerability usually can’t explain why the vulnerability exists. They didn’t make a decision to skip authentication. They didn’t choose to trust user input. They asked an AI to build a thing, and the AI made those decisions, and the developer never saw them. When told about the problem, the fix is to ask the AI to fix the problem. This patches the specific vulnerability but does nothing to improve the developer’s understanding. The same class of error will reappear in the next feature because the process that produces errors hasn’t changed.

One SubredditDrama commenter put it bluntly: “That’s not even coding, that’s telling AI to code.” And those are different things with different failure modes. When you code, you make mistakes you can learn from. When you tell an AI to code, you get mistakes you can’t even describe, because you were never close enough to the code to see them form.

§The blast radius problem

If Huntarr had stayed on one person’s home server, none of this would matter. Bad code on a personal project hurts nobody except the person who runs it.

But Huntarr didn’t stay on one server. It was promoted on Reddit, listed on GitHub, integrated into people’s self-hosted stacks. It connected to ten or more other applications and held their credentials. The developer solicited donations. They had a presence, a community, a subreddit. Users trusted the application because it appeared to be a maintained open-source project with an active developer.

This is the mechanism that turns vibe-coded applications into time bombs. The code ships fast because AI generates it fast. It accumulates users because it works, in the sense that it does what the user interface promises. The users have no way to evaluate the security of the code, and why would they? They’re not security researchers. They’re people who wanted an application that manages their media library.

The blast radius grows quietly. More users, more exposed credentials. More integrations, more systems depending on code nobody understands. The bomb just sits there ticking until someone bothers to actually read the source. When someone finally did with Huntarr, the researcher’s assessment was almost casual: “I did little more than the basics. The project was terrible.”

§What happens next

I don’t think vibe coding goes away. The productivity gain is real, and people who couldn’t build software before can now build software. That’s good. I’m not interested in arguing otherwise.

But we figured out decades ago that power tools need safety guards. Table saws have blade guards. Nail guns have sequential triggers. Nobody argues that these slow down experienced carpenters. The tools are powerful enough to hurt people, so the tools account for that.

Vibe coding tools have nothing like this. Cursor, Copilot, Bolt, Replit Agent: they generate code without any integrated security review. No warning when you’re about to ship an unauthenticated endpoint that exposes credentials. No static analysis before the code is suggested. The only friction between “generate” and “deploy” is the developer’s own understanding, which, in the vibe coding paradigm, is explicitly not required.

Some of this will get built. GitHub is already adding security scanning. AI companies are working on models that are more security-aware. But the gap between “AI generates code” and “AI generates secure code” is large, and the market doesn’t wait for safety features. People are deploying now.

The Vibe Code Time Bomb is a timing problem. More people are building software with AI than there is security infrastructure to catch what they’re building. Every month that gap stays open, more applications accumulate more users running more unreviewed code.

The developer of Huntarr didn’t stick around to fix the 21 vulnerabilities. He deleted everything and vanished. I don’t think he panicked because he was caught doing something cynical. I think he panicked because he was confronted with a codebase he couldn’t fix, in a language he couldn’t really read, with consequences he never considered. He was the dog. He just didn’t know it until someone looked at the code.

That’s the part that should bother you. Not this one guy. The pattern. There are a lot of Huntarrs out there right now, running on a lot of servers, holding a lot of credentials. Most of them haven’t been audited yet. The researcher who found 21 critical vulnerabilities said it took him basic tools and a few hours. The project had been live for months.

Sources:

• “Huntarr - Your passwords and your entire arr stack’s API keys are exposed,” r/selfhosted (8,863 pts, 1,282 comments)
• “r/huntarr goes private, the creator nukes both their reddit and GitHub accounts,” r/SubredditDrama (1,228 pts, 133 comments)
• “I’m helping my dog vibe code games,” Hacker News (1,082 pts, 365 comments)
• Security audit with 21 findings: github.com/rfsbraz/huntarr-security-review
• “45% of AI-generated code has flaws,” Natively.dev analysis (2026)
• “1 in 5 vibe-coded applications expose organizations to risk,” Wiz Research (2026)
• “Exposed Moltbook database reveals 1.5M API keys,” Wiz blog (2026)
• “69 vulnerabilities discovered across vibe coding tools,” Ravenna.ai (2026)
• “80%+ developers using or planning to use vibe coding,” Keywords Studios survey (2026)
• “Vibe coding could cause catastrophic ‘explosions’ in 2026,” TheNewStack

Originally published at https://noahaust2.github.io/strategist-dashboard/blog/the-vibe-code-time-bomb.html