1. estimate this sprint. let's say it's 100 points.
2. oh no, you shipped 80 points.
3. "we need to better estimates":
a) engineer spends more time trying to guess which direction the wind will blog
b) engineer starts sandbagging estimates
c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".
fwiw i know tobias and its very very unlikely he made this up.
my guess its intentionally vague to not leak any information about the culprit which i guess is fair.
It's pure bs. If you read that blog post and think "this definitely happened", let alone "wow - this is interesting" then I have a monorail to sell you.
> Technical Background
> The entire application was a single HTML file with all JavaScript, CSS, and structure written inline. The backend was a managed database service with zero access control configured, no row-level security, nothing. All "access control" logic lived in the JavaScript on the client side, meaning the data was literally one curl command away from anyone who looked.
> All audio recordings were sent directly to external AI APIs for transcription and summarization.
> There was more, but this is already enough to get the idea.
Hmmmm... interesting, now that I have the "Technical Background" I for sure know that this medical app was 100% vibe coded by a Medical Practice in the Real World and exists! (TM)
It’s unlikely any LLM tasked with a prompt involving medical records did not automatically address separation of concerns. The type of data involved is worst case scenario. One JS file is also worst case scenario. This is why it may feel manufactured. If it is true, they truly deserve to be put on blast.
I can 100% imagine prompts that would even feel natural that would never hint at any medical background of the data being processed. Could be as simple as using customer instead of patient.
Given the subject matter, it would be highly unethical to reveal the name of the company before verifying it was indeed fixed. I'd be wary of getting sued.
The first time I stumbled onto a big security vulnerability (exposed stripe/aws/play store keys. I was poking around an API a web app was using, and instead of hitting /api/v1, if you just hit /api it served them. I wasn't trying to do anything malicious), the very first thing I did was contacted a security researcher friend to ask about covering my ass while performing responsible disclosure.
You hear too much about people being persecuted for trying to point out security vulnerabilities. (Guess they haven't heard about "don't shoot the messenger").
(It turned out fine after finally managing to speak with someone. Had to ring up customer service and say "look, here are the last digits of your stripe private key. Please speak with an engineer". Figuring out how to talk with someone was the difficult thing)
yeah keeping it vague makes sense to protect the place if it's still online but the whole thing doesn't really make sense?
The timelines mentioned are weird - he spoke to them before they built it? Or after? It's not that clear, he mentions they mentioned watching a video.
> The entire application was a single HTML file with all JavaScript, CSS, and structure written inline.
This is not my experience of how agents tend to build at all. I often _ask_ them to do that, but their tendency is to use a lot of files and structure
> They even added a feature to record conversations during appointments
So they have the front-desk laptop in the doctor's room? Or they were recording conversations anyway and now they for feed them into the system afterwards?
> All "access control" logic lived in the JavaScript on the client side, meaning the data was literally one curl command away from anyone who looked.
Also definitely not the normal way an agent would build something - security flaws yes, but this sounds more like someone who just learnt coding or the most upvoted post of all time on r/programmerhorror, not really AI.
Overall I'm skeptical of the claims made in this article until I see stronger evidence (not that I'm supporting using slop for a medical system in general).
I don't know what to make of the article. First I thought it seems like a made up LinkedIn story, it seems too crazy while talking about it in such a casual manner. Ultimately I don't know, maybe it was vague for a specific reason. I guess one thing I'd find odd is that whoever developed it, that they didn't run and get stuck with CORS issues, if everything was done client side to those services and that they managed to get API keys, subscription stuff everywhere while still making mistakes like this. And no mention of leaked api keys and creds which UI side there must have been, right?
> Everything that could go wrong, did go wrong.
Then this claim seems a bit too much, since what could have gone more wrong is malicious actors discovering it, right? Did they?
Maybe I have trouble believing that a medical professional could be that careless and naive in such a way, but anything could happen.
I guess another thought is... If they built it why would they share the URL to the author? Was author like "Ooh cool, let me check that out", and they just gave the url without auth? Because if it worked as it was supposed to it should have just shown a login screen right? That's the weirdest part to me, I suppose.
> The timelines mentioned are weird - he spoke to them before they built it? Or after? It's not that clear, he mentions they mentioned watching a video.
I took that all to mean she had explained the history of it to the author, but it had already been written and deployed. It is worded a little weird. It's also translated from german, I don't know if that is a factor or not.
> The timelines mentioned are weird - he spoke to them before they built it? Or after? It's not that clear, he mentions they mentioned watching a video.
Yeah although I didn't comment I found this weird as well. Chronology was vague and ill-defined. He went to a doctors office and the receptionist mentioned vibe coding their patient records system unprompted?
> A few days later, I started poking around the application.
What!? How... was there even a web-facing component to this system? Did the medical practice grant you access for some reason?
Yeah I'm back to calling bullshit. What a load of crap. Whole post probably written by an LLM.
Having experience working with medical software, I call BS on this article as presented, unless it was some minimal support app. When you deal with patient records, there's so much of local law, communication, billing rules and other things baked in that you CANNOT vibe code an app to handle even 1% of that. Your staff would rebel and your records would completely fall apart. Even basic things like appointment bookings have a HISTORY and it's a full blown room scheduling system that multiple people with different roles have to deal with (reception and providers). It takes serious time to even reverse engineer the database of existing apps, and you first have to know how to access the database itself. Then you'll see many magic IDs and will have to reverse engineer what they mean. (yes, LLMs are good at reverse engineering too, but you need some reference data and you can't easily automate that)
I have decompiled database updaters to get the root password for the local SQL Server instance with extremely restricted access rules. (can't tell you which one...) I have also written many applications auto-clicking through medical apps, because there's no other way to achieve some batch changes in reasonable time. I have a lot of collateral knowledge in this area.
Now for the "unless it was some minimal support app" - you'll see lots of them and they existed before LLMs as well. They're definitely not protecting patient data as much as other systems. If the story is true in any way, it's probably this kind of helper that solves one specific usecase that other systems cannot. For example I'm working on an app which handles some large vaccination events and runs on a side of the main clinic management application. But accidentally putting that online, accessible to everyone, and having actual patient data imported would be hard-to-impossible to achieve for a non-dev.
For the recording and transcription, there are many companies doing that at the moment and it would be so much easier to go with any of them. They're really good quality these days.
I don't think you read the article very carefully, the timeline is that he met a person, and that person told him that they made vibe-coded an app after having seen a video. He then investigated the app.
> On my last visit i actually casually discussed their IT system with a doctor.
Oh right, cool. Did it have a public-facing web-portal that you were able to "investigate" and that "Thirty minutes in, I had full read and write access to all patient data".
The level of credulity in these comments is immense.
No, they were complaining about using expensive, overly complicated third-party system that they need like only basic features like keeping text records about visits, and prescriptions and sending invoices to health insurers.
And in some practices you get direct access to your data as a patient.
I mean the story might be fake obviously, but is definitely plausible.
Yeah sure, as a matter of rule, every time I visit any health provider I am always discussing with the medical receptionist: the software they use, the challenges the business as a whole faces, the tensions between insurers and third parties.
Things that absolutely 100% happen everytime I - a tech guy - experiences when I go to the doctor/phyiso-therapist etc... etc... These are discussions that are happening.
Yes in good faith I will one hundred percent no-lie wire you 100AUD if you can prove beyond doubt that you had a discussion like that with a Swiss health provider. Not one that you contrive now after the fact - one that happened before this wager.
Spoiler: you didn't mate and you are full of shit.
Sure, leans a bit classical and not the least bit "wanky" (at least IMHO)
> but the term was around long before it.
Wanky? DJ? Classical? Term Of His Natural Life? .. Regardless of the specific etymological chronology you're thinking of, I feel there are non-wanky examples in the broad tent of "classical".
I came here to write a similar comment. To me it read more like: When driving, do you prefer to a) turn left, b) turn right, c) press the gas pedal, d) press the brake pedal, or e) execute a sequence of actions that get you safely to your destination? There's a good idea here, perhaps, but it's obscured by very weak questions.
Starting around the mid 2010s I think, I started seeing needless use of "Design Patterns" all over the place (mostly by CS graduates). Factories, adapters, observers in places where it was just plain overkill and needless extra lines of useless code.
I started referring to it as cargo-cult programming.
Personally after being allowed to be fully remote I found this to be a weird experience. I wasn't totally sure where to live. I no longer needed to be in the bay area, I could go back "home". Idk what I wanted to do, got pressure from family about what I "should" do. I didn't really know what I wanted in a place to live. And I think for most people for most of their lives no one had this freedom to just live anywhere. There isn't a lot of good advice.
reply