Comment by spaceman_2020
1 day ago
How are you completely disregarding the data integrity and privacy aspects of rolling your own tools?
I vibecode an app that only I use and store data locally. That means my data never leaves my device, I never have to share my email with anyone, never have to enter my credit card info anywhere
You buy SaaS and you have to then login, share credit card info, and have your data stored in the cloud somewhere with godknows what security practices
That’s worth more than the cost of any tokens
> You buy SaaS and you have to then login, share credit card info, and have your data stored in the cloud somewhere with godknows what security practices
I'm speaking more about fake SaaS "we have an app and we charge monthly for it and license it." Obviously, a tool with cloud-based storage and sharing will be a different beast.
But do you trust a vibe coded app to do cloud-based storage and sharing better than a company or an indie developer? If you need these functions (like sharing a todo list between two users), you have a lot more concerns than "does it boot".
If I vibe coded it? Absolutely. I can definitively answer what S3 buckets are in use, and that public access is disabled! Like, that parts really really not that hard, and people keep fucking it up. Plus the threat model for the Todo so that my small friends/family group uses is totally different from the problems google keep faces.
But that's cheating because I do this stuff professionally. Would I trust a vibe coded Todo app my uncle's son Jimmy who smoke a lot of pot uses? I'm not saving my bank account number to it, but I'd have no problem using it for reminders that my aunt's birthday is coming up so I need to buy a gift. If it gets popular within in the family unit, uncle will have me talk to his son and take a deep look at it anyway, try and encourage Jimmy to go back to school and look for a job and all that stuff too.
Plus, theres nothing stopping the company and indie developer from vibecoding as well.
Another way to look at this is that you're giving away all of your source code as context, and probably a lot of things you don't necessarily want to share, if you aren't using self-hosted models.
Especially with agents that slurp up files, have access to databases, etc. You're literally giving access to your computer, your network and your data to third parties and letting them run code.
During development you don't use prod data, though. So I don't see much problem here, even if I'm developing something where I would store sensitive data later.
(If there is a bug though which I would want to debug and if I were not a developer, then your concerns are more valid)
> During development you don't use prod data, though.
I’ve seen projects where testing is done in prod and also projects where API keys for some external services (e.g. Mapbox) are shared across prod and dev. Or cases where credentials end up in Git repos (edit: wrote GitHub originally, but meant typically non-public repos on any platform) due to ease of use and how inadequate secret management solutions can be.
Luckily that’s not the majority of projects, but I bet it happens a lot more elsewhere. Definitely a bunch for your average outsourced/freelance/scrappy/non-funded project.
Whether anyone will actually use your secrets or even code that’s sent to these large AI shops, though, that’s another question. You might as well question using GitHub cause it’s owned by M$.
1 reply →
Data privacy is a real concern, but any SaaS provider worth their salt is using Stripe or similar for payments, not rolling their own. That's not as good as not providing the info in the first place but that makes it much less likely that your CC info is going to turn up in an S3 bucket with bad permissions or something.
Yes, but at this point I'd almost rather have my CC info exposed than my personal info. There is law and consequence for fraudulent charges that protects me from loss (if not inconvenience) but there is basically no protection for playing fast and loose with my PII--in fact, it's the opposite! They sell it!
I haven’t thought about it this way but yeah I totally agree. Most of the major consequences from my CC info getting leaked can be dealt with without major long term impact to my life. The same cannot be said about PII currently
privacy.com let's you generate per-merchant credit card numbers and put limits on them, limiting the damage a leaked CC number can do.
To my mind, this is the huge bit that should not be overlooked.
So much infrastructure is there to support doing "it" in the Cloud, for all definitions of "it." If we can vibe-code bespoke one-offs to solve our problems, a lot of that Cloud interaction goes away... And that stuff is expensive and complicated.
Hypothetically, open source app stores (I'm counting apt here) address this, but then it's someone else's solution to my problem, which doesn't quite fit my problem perfectly.
This approach to software engineering could be what 3D printing is to tangible artifacts (and I mean that including the limits of 3D printing regarding tangible artifacts, but even still.)
There’s also speed - no matter what you do, a local app will simply be faster than using one from a SaaS provider
> That means my data never leaves my device
I mean, if you vibecoded it you don't actually know that, do you?
If you want to be completely watertight, you can absolutely run an on premises model. No data ever leaves your network, ever. Some pretty good models run on $5-10k hardware
Can’t do that with SaaS
Also, I’m baffled that on HN of all places, I have to actually defend the idea of rolling your own apps and protecting your data from cloud providers
Until vibecoding agents somehow develop the capability to sign up for a cloud storage API and pay for it on their own, you can probably be pretty sure about that.
An exfiltrator would have a blind upload box sitting somewhere the poisoned prompt knows about
1 reply →
vibe code manifest.xml to disallow network access. If you're really paranoid, you can use Google search to look up the permissions names instead of relying on an LLM to do it.