Someone asked a question I keep coming back to: they vibe-coded a Mole for Linux, it works for them with the official client, but they’re torn about releasing it because of the stigma around reverse-engineered, vibe-coded software. Should they?
I don’t think there’s one right answer. There’s a personal answer, and it depends on how you release it.
Would I run it? No.
Let me be honest first: I wouldn’t use it. Anything that touches my screen capture or my data, written by a stranger and downloaded at random, makes me uncomfortable. That has nothing to do with whether an AI wrote it. It’s the same reason I don’t install random binaries from the internet.
The same logic applies to paid software from an unknown developer. Someone once pitched me a tool that was supposed help me with self hosting once and for all. A real, annoying problem. They started with “I’ll open source it” and ended at “actually, a paid subscription.” They offered to show me the source code for review.
No thanks. I’m not going to audit it, and that’s the point. The value of developing in the open is that more than one pair of eyes looks at the code, assuming it ever gets enough momentum for anyone to look. Closed, paid, and unaudited, from someone I don’t know, is a hard sell for something that moves my files.
Would I tell you to release it? Yes, with conditions
If there’s nothing nasty baked in, put it out there. My hot take is that the backlash will be smaller than people expect, as long as you:
- release it openly and say clearly what it is;
- don’t charge for it or hide it behind a restrictive license;
- use the most permissive license you can. If an AI wrote it, nobody really owns it anyway, much like with AI-generated art.
And don’t sign up to maintain it for everybody. If you vibe-coded it, you may not fully understand it, which makes support promises hard to keep.
Some communities, r/selfhosted for one, hate anything vibe-coded. That’s funny, because people were writing terrible software long before AI. The difference now is that the disclosure is visible. Nobody labelled the bad code from 2015 as “written without much thought.”
Also, I wouldn’t run it, but I’d read the post and think “oh, that’s possible.” Seeing someone do it is information, and I might just build my own. That’s what a release is worth even to people who won’t install it.
The fragmented future isn’t coming, it’s here
The obvious worry is whether a fragmented world of everyone running their own software is what we want. I am sure that we don’t want it, but we’re going to get it. Actually, we already have it.
- YouTubers are building video editors for themselves, and for them these work better than Premiere. They have very specific footage formats coming in, very specific outputs going out, and no use for the rest of the feature pile.
- I know multiple people who built their own internal management software: it pulls information from all kinds of places, analyzes it, and tells them where to pull back.
That second one is the interesting part. They trust it more than the commercial alternatives, because it’s self-hosted and they made it. A credit card company’s “financial planning” feature comes with a motivation you can guess. Their own vibe-coded tool has the motivation they gave it. Whether that trust is deserved is a different question.
What worries me
Security. If trust comes from “I built it myself,” that’s a feeling, not an audit. Software that handles bank data as an example, and has never been reviewed by anyone but its author, and arguably not even by them, is a real problem. The security implications of this wave are huge, and I don’t think we’ve started to price them in.
Career mobility. If you spend three years editing in a tool only you use, what does that do to your resume? You show up at a company that uses a standard editor and you’re starting over. Maybe the answer is that everyone brings their own tool to every job. That raises the next question: what happens when a colleague is sick on Friday and someone else has to finish their work in a tool built around their personal workflow?
Knock-on effects. Nobody can fully predict what a world of millions of one-off tools does to collaboration, support, standards and compatibility. Shared software has always been a way of agreeing on how things work.
Where I land
Vibe-code the thing. Use it, experiment with it, build something that solves your own problem. I think this is the future, and it’s here to stay, even if it won’t always look like a chat window writing an app for you. If you release it, release it openly, describe it honestly, and don’t promise support you can’t give.
But don’t forget the people who actually know how this stuff works. Software that does something important, that handles sensitive data or that other people depend on, needs to be checked by real people with real knowledge. Getting an app to run isn’t the same as knowing it’s safe, and asking the model to check its own work doesn’t replace that expertise.
As an example, self-hosting doesn’t magically make it safe either. You can’t just hand your data to a vibe-coded app because it’s running on your own server. If you don’t understand what you’re hosting, what it exposes to the internet, or why you opened those ports to get it working, you may have made your private data available to anyone who finds it. “I host it myself” is only reassuring if you understand what that involves.
I think a lot of people have rushed from discovering what they can build with vibe coding straight to trusting it with things that matter. They skipped the part where you learn what can go wrong and how to recognize it. I’m pretty sure we’ll learn a lot about those consequences soon, and some of those lessons will be painful. Keep building. Just make sure someone who understands the software has checked it before you trust it with something you can’t afford to lose.