An AI Vibe Coding Horror Story

I did something similar to a local company here in Spain. Not medical, but a small insurance company. Believe it or not, yes, they vibecoded their CRM.

I sent them an email and they threatened to sue me. I was a bit in shock from such dumb response, but I guess some people only learn the hard way, so I filed a report to the AEPD (Data protection agency in Spain) for starters, known to be brutal.

I've also sent them a burofax demanding the removal of my data on their systems just last friday.

Meanwhile on Linkedin… Every sales bozo with zero technical understanding is screaming top of their virtual lungs that evrything must be done with AI and it is solution to every layoff, economic problem, everything.

It is just a matter of time when something really really bad happens.

I think vibe-coding is cool, but it runs into limits pretty fast (at least right now).

It kinda falls apart once you get past a few thousand lines of code... and real systems aren't just big, they're actually messy...shit loads of components, services, edge cases, things breaking in weird ways. Getting all of that to work together reliably is a different game altogether.

And you still need solid software engineering fundamentals. Without understanding architecture, debugging, tradeoffs, and failure modes, it's hard to guide or even evaluate what's being generated.

Vibe-coding feels great for prototypes, hobby projects, or just messing around, or even some internal tools in a handful of cases. But for actual production systems, you still need real engineering behind it.

As of now, I'm 100% hesitant to pay for, or put my data on systems that are vibe-coded without the knowledge of what's been built and how it's been built.

I saw something very similar a few months ago. It was a web app vibe coded by a surgeon. It worked, but they did not have an index .html file in the root web directory and they would routinely zip up all of the source code which contained all the database connection strings, API credentials, AWS credentials, etc.) and place the backup in the root web directory. They would also dump the database to that folder (for backup). So web browsers that went to https://example.com/ could see and download all the backups.

The quick fix was a simple, empty index.html file (or setting the -Indexes option in the apache config). The surgeon had no idea what this meant or why it was important. And the AI bots didn't either.

The odd part of this to me was that the AI had made good choices (strong password hashes, reasonable DB schema, etc.) and the app itself worked well. Honestly, it was impressive. But at the same time, they made some very basic deployment/security mistakes that were trivial. They just needed a bit of guidance from an experienced devops security guy to make it Internet worthy, but no one bothered to do that.

Edit: I do not recommend backing up web apps on the web server itself. That's another basic mistake. But they (or the AI) decided to do that and no one with experience was consulted.

Software engineering is looking more and more like it needs a professional body in each country, and accreditation and standards. Ie it needs to grow up and become like every other strand of engineering.

Gone should be the days of “I taught myself so now I can [design software in a professional setting / design a bridge in a professional setting].” I’m not advocating gatekeeping - if you want to build a small bridge at the end of your garden for personal use, go for it. If you want to build a bridge in your local town over a river, you’re gonna need professional accreditation. Same should be true for software engineering now.

> All "access control" logic lived in the JavaScript on the client side, meaning the data was literally one command away from anyone who looked

This is the top!

This is a typical example of someone using Coding Agents without being a developer: AI that isn't used knowingly can be a huge risk if you don't know what you're doing.

AI used for professional purposes (not experiments) should NOT be used haphazardly.

And this also opens up a serious liability issue: the developer has the perception of being exempt from responsibility and this also leads to enormous risks for the business.

Every other field that's figured out high stakes failure models eventually landed on the same solution - make sure two people that understand the details are looking at it - pilots have copilots surgeons with checklists and nuclear plants have independent verification. Software was always the exception, cause when it broke it mostly just broke for you, vibe coding is not going to change the equation, it barely removes one check that existed before is that the people who wrote the code understood what was going on, but now that's gone too

This reads like internet fiction to me. Very vague and short.

I know, through personal acquaintance, of at least one boutique accounting firm that is currently vibe-building their own CRM with Lovable. They have no technical staff. I can't begin to comprehend the disasters that are in store.

What would a responsible on-boarding flow for all of these tools look like?

> Welcome to VibeToolX.

> By pressing Confirm you accept all responsibility for user data stewardship as regulated in every country where your users reside.

Would that be scary enough to nudge some risk analysis on the user's part? I am sure that would drop adoption by a lot, so I don't see it happening voluntarily.

I think the issue here is less about AI misbehaving and more about people doing things they should not be doing without thinking too hard about the consequences.

There are going to be a lot of accidents like this because it's just really easy to do. And some people are inevitably going to do silly things.

But it's not that different from people doing stupid things with Visual Basic back in the day. Or responding to friendly worded emails with the subject "I love you". Putting CDs/USB drives in work PCs with viruses, worms, etc.

That's what people do when you give the useful tools with sharp edges.

Is there anybody making some framework where you declare the security intentions as code (for each CRUD action) and which agents can correctly do and unit test? I have seen a Lovable competitor's system prompt have 24 lines of "please consider security when generating select statements, please consider security when generating update statements..." since it expects to dump queries here and there.

I think it is wonderful.

It's reminiscent of the 90s, where every middle manager had dragged and dropped some boxes on some forms, and could get a salesman to sell it, without a care in the world for what was going on behind the scenes.

Until something crashed and recovery was needed, of course.

The piper always needs to be paid.

Archived version:

https://archive.ph/GsLvt

https://web.archive.org/web/20260331184500/https://www.tobru...

I think AI will be too expensive soon for normal/non technical people to tinker with and this kind of vibe coding stories will disappear.

The takeaway is to vet new companies one is dealing with - even just calling them up and asking if they've AI generated any system which deals with customer/patient data.

This is going to get more common (state sponsored hackers are going to have a field day)

I believe there are various dimensions to vibe coding. If you work with an existing codebase, it is a tool to increase productivity. If you have domain specific knowledge, in this case - patient management system, you can build better systems.

Otherwise, you endup simulating the production. Lot of the non technical folks building products with AI Vibe coding are basically building Product Simulations. It looks like a product, functions like a product but behind the scene, you can poke holes.

Damn!!! And I keep hardening my RSS app which was partly vibe coded and not exposed to the WAN while "professionals" give data away.

So much is missing from this story. Did they report it to the relevant data authority? Did the fix they said they applied actually fix anything? Etc.

Who should get jailed ?

Does the company which willingly sells the polymorphic virus editor bear any responsibility, or should the unaware vibe coder be incumbent ?

I interviewed some years ago for an AI related startup. After looking at the live product, first thing I see is their prod dB credentials and openAI api key publicly send in some requests... Bad actors will be having a lot of fun these days

I really hope OP also contacted their relevant national privacy authority, this is a giant violation

I have my doubts on the story. I consulted on a medtech project in the recent past in similar space, and at various points different individuals vibe-coded[0] not one but three distinct, independent prototypes of a system like the article describes, and neither of them was anywhere near that bad. On the frontend, you'd have to work pretty hard to force SOTA LLMs to give you what is being reported here. Backend-side, there's plenty of proper turn-key systems to get you started, including OSS servers you can just run locally, and even a year ago, SOTA LLMs knew about them and could find them (and would suggest some of them).

I might be biased by my experience, because we actually cared about GDPR and AI act and proper medical data processing, and I've spent my fair share of time investigating the options that exist. Still, I'm struggling to imagine how one could possibly screw it up anywhere near as what the article described. Like, I can't think of a way to do it, to the point I might need to ask an LLM to explain it to me.

--

[0] - Not as a means of developing an actual product, but solely to see if we can, plus it was easier to discuss product ideas while having some prototypes to click around.

To me it just sounds like eventually someone will figure out how to make vibecoding more reasonably secure (with prompts to have apps be looked at for security practices?)

unless cybersecurity is such a dynamic practice that we can't create automated processes that are secured

Essentially a question of what can be done to make vibecoding "secure enough"

Technology for greed vs technology for need. Greed has its cost.

this is exactly the kind of vibe coding horror stories I asked for just few days ago :)

https://news.ycombinator.com/item?id=47707681

Anyone else read the title on HN and shudder not wanting to actually click it?

The worst blunder I made was when I explored cloud resources to improve the product's performance.

I created a GCP project (my-app-dev) for exploring how to scale up the cloud service. I added several resources to mock the production, like compute instances/cloud SQL/etc, then populated the data and run several benchmarks.

I changed the specs, number of instances and replicas, and configs through gcloud command.

  $ gcloud compute instances stop instance-1 --project=my-app-dev
  $ gcloud compute instances set-machine-type instance-1 --machine-type=c3-highcpu-176 --project=my-app-dev
  $ gcloud sql instances patch db-1 --tier=db-custom-32-131072 --project=my-app-dev

But for some reason, at one point codex asked to list all projects; I couldn't understand the reason, but it seemed harmless so I approved the command.

  $ gcloud projects list
  PROJECT_ID     NAME       PROJECT_NUMBER
  my-app-test    my app     123456789012
  my-app-dev     my app     234567890123     <- the dev project I was working on
  my-app         my app     345678901234     <- the production (I know it's a bad name)

And after this, for whatever reason it changed the target project from the dev (my-app-dev) to the production (my-app) without asking or me realizing.

Of course I checked every commands. I couldn't YOLO while working on cloud resources, even in dev environment. But I focused on the subommands and its content and didn't even think it had changed the project ID along the way.

It continued to suggest more and more aggressive commands for testing, and I approved them brain-deadly...

  $ gcloud sql instances patch db-1 --database-flags=max_connections=500 --project=my-app
  $ gcloud compute instances delete instance-1 --project=my-app
  $ echo 'DELETE FROM users WHERE username="test";' \
      | gcloud sql connect my-db 
   --user=user --database=my-db --project=my-app
  $ wrk -t4 -c200 -d30s \
      "http://$(gcloud compute instances describe instance-1 \
      --project=my-app \
      --format='get(networkInterfaces[0].accessConfigs[0].natIP)')"

It took a shamefully long time to realize codex was actually operating on production, so I DDoSed and SQL-injected to the production...

Fortunately, it didn't do anything irreversible. But it was one of the most terrifying moments in my career.

There’s another version of the Mythos narrative that reads like:

AI companies realized that all this vibe coding has released a shitstorm of security vulnerabilities into the wild and so unless they release a much better model to fix that mess they’ll be found out and nobody will touch AI coding with a 100ft pole for the next 15 years. This article points more towards this narrative.

A perfect example of why a product like Medplum exists, as opposed to completely reinventing the wheel from scratch

The only thing what helps is deleting the database. Every day. Until the thing goes down because the 'developer' thinks he has a bug that he can't find.

Avoid javascript like plague, it can be overwritten at the client side.

Report them - that right there is 5+ different violations. Only then will they realize their stupidity.

It's nothing new, dunning kruger existing long before AI entered coding realm.

Several years ago ran into one american company which consulted with me. They had 4000 paying customers and they rolled out their billing solution which accept crypto, paypal and stripe.

They had problem with payment going missing, i migrated them to WHMCs with hardening and they never had any issues after.

Now people may laugh at whmcs but use the right tool for job

U need battle tested billing solution then whmcs does count it can support VAT, taxes, reporting/accounting and pretty all which you'll error while you try to do it all yourself.

Too bad there aren't battle tested opensource solution for this

Kinda crazy but hopefully the future holds a Clippy-esque thing for people who don’t know to set up CI, checkpoints, reviews, environments, etc. that just takes care of all that.

It sorta should do this anyway given that the user intent probably wasn’t to dump everyone’s data into Firebase or whatever.

I personally would like this as well since it gets tiring specifying all the guardrails and double-checking myself. Using this stuff feels too much like developing a skill I shouldn’t need while not focusing on real user problems.

Hard to believe... This activity should certainly land you in a German prison?!

Cool story bro. Of course it’s true if it made it to HN. Who needs proofs.

You guys realise this is AI slop on AI slop, right?

Some people only care about actual consequences. Download all the data and send it, in the post on a flash drive, to the GDPR regulator's office and another copy to the medical licensing board because why not.

Don't blame the AI for what is clearly gross human negligence. It's like renovating your entire house and then acting surprised when the pipes burst because you used duct tape as a permanent fix.

Do you think if the agency hired a consultant to build this , a consultant couldn’t have made the same mistakes?

Lack of security theater is a good thing for most businesses