I don't know... I read the article, and what I really saw was a simpler argument: The buy vs build decision had drifted so far to capture by vendor, where the vendor charged to gather the already in-existence in-house knowledge, that it was much cheaper to build in-house. The AI bits could be seen as a speed-up, but I think it more likely that those designing the new system were designing from pain. That is, they knew the pain points based upon years of intimate knowledge. No wonder the new system, stood up quickly, and quite possible still in MVP mode, is so popular.
In brief, the story isn't AI as an accelerant. It's someone finally letting loose their internal knowledge to build to spec rather than buy.
Interesting idea. I cannot say that I can answer affirmatively nor negatively. There are also human elements to be considered. Humans are status-seeking social creatures. There will always be a stain of humanoid-delivered care, no matter how high-quality, as being not as high quality of all-human delivered care. This is, status accounts for a lot.
I can also draw pictures of how dangerous humanoid care can be, as there is a possibility in a break in the chain of responsibility. If a human medical professional messes up, you (or your survivors) can sue and seek damages directly, as well as sue the hospital and insurance system (with mixed results).
With humanoids? Currently, the bar is higher as the entity being sued is not the hospital, nor a person, or even a team. The only entities that can be addressed are the corporation the runs the hospital and the corporation that produced the humanoid. These two entities have an incredible out-sized advantage in terms of sheer delaying tactics, not to mention arbitration clauses and other legal innovations. Most injured will simply give up, which is a legal win for the two entities.
In my opinion, humanoid care will take a large amount of time, damage, and treasure to lower the costs. No actor will willingly give up their cash flow. My view may be too strong.
The quickest way to rile up an existing mob is to make them fear their livelihood is being reduced or removed. The _robot_ is not taking away healthcare, but the effect of the robot existing hit directly at the livelihood of the masses.
In the US, health insurance is largely tied to employment. Health insurance, in a personal economic sense, reduces to being able to pay for healthcare. This policy is largely a left-over of World War II era employment policies. No one is taking healthcare _away_ from anyone (strictly speaking), but the ability to be able to _pay_ for healthcare is reduced to zero when employment ceases. Accessing the safety net is a separate skillset. This skill set becomes more difficult to achieve because the political class does not want to provide healthcare for everyone, only the worthy (their loyal voters).
I grew up in and am still a member of the precariat. I am educated and doing well, but I wear a well-polished pair of golden handcuffs due to how my ability to afford healthcare for myself, and my family, is tied to employment. Politically, I _do not_ like being tied to my employer by such a chain, but my arguments to change the system have been met with quite firm push-back.
Like any group of humans, there are power structures and edge cases that can lead to horrific outcomes. Giving the person that posted the warning the benefit of the doubt, I think what they are saying is that "Rationalist does not necessarily mean positive for humanity, nor even no harm for humanity". This holds for all religions and religion-like movements, of which Rationalism, in this sense, is one.
Ehh... US-centric. Better to use significance order: Country, then postal (most countries have postal), then region, city, and street address. Best, however, is to _not_ separate the address into fields. Instead, allow a free text field for the person doing data entry to put in the address in _their_ format and then parse it on the backend. This gets you the most flexibility and allows you to encounter and handle corner cases by using (my favorite test data) public addresses from all over the world. _I_ routinely test my address entry by Googling McDonald's locations and feeding them into my system. Handle an inscrutable address like any other bad data and say, politely, that your system does not understand the data.
All that said, free-form entry is a hard sell. My _customers_ expect field data entry, so I implement field data entry. I just re-order my checks to be more forgiving until the data entry is complete.
I was implementing a customer service address entry using significance order 25 years ago. As I already _knew_ that I had a US-centric customer base (we sold long distance to sorority and fraternity members), entering US ZIP first saved a lot of time and more highly leveraged the US postal address cleaner that we had already purchased for our mass marketing mailers. The people working the call center _loved_ it, as they could focus more on their call turn-over than on data entry.
My boss (and mentor) from 25 years ago told me to think of the problems I was solving with a 3-step path:
1. Get a solution working
2. Make the solution correct
3. Make the solution efficient
Most importantly, he emphasizes that the work must be done in that order. I've taken that everywhere with me.
I think one of the problems is that quite often, due to business pressure to ship, step 3 is simply skipped. Often, software is shipped half-way through step 2 -- software that is at best partially correct.
The pushes the problem down to the user, who might be building a system around the shipped code. This compounds the problem of software bloat, as all the gaps have to be bridged.
As noted above, I was working out of an academic lab developing new equipment. We had current-level commercial equipment at the time to use in comparisons. I matched data to the data dictionary, recovered backups, scripted backups, sent alerts to grad students that their results were done, maintained and expanded the visualization software, consulted and contributed code to a Monte Carlo simulation to demonstrate that data collected was better than random and by how much... Great little projects for a budding software developer. I had to learn just enough Chemistry and Physics beyond what I already knew to be dangerous (and also understand the what and why of what I was doing and be able to ask clarifying questions). It was fun.
I'll admit, my perspective is now 16, almost 17 years out-of-date, but my read of this article is that nothing much has advanced beyond what I was doing in the field back then.
My job? Data plumber and analyst, same as now. I scripted the nuts-and-bolts of matching the mass/time/time data off the instrument being developed by much more qualified PhD candidates and their advisor while I finished up my own degree. They did the heavy lifting. I was paid for by F&A funds to do the boring work. Great job for a student.
The job lead to a failed business venture. Water under the bridge. My last foray in data analysis was Principal Component Analysis of the data, trying to cluster detected proteins for visual analysis. I got the plots working outside of Matlab, and then my position was eliminated.
I have a rag-mag credit I could chase down to support my war story. To be honest, I read the article looking for familiar names and faces.
Writ-large, isn't what the article is referring to the plot of 生きる(Ikiru, https://en.wikipedia.org/wiki/Ikiru)? My suspicion is that the solution to lack of ability for government to enable building in the US will be the same, writ-large, as in the movie. That is, it will happen, but (I'll stop here, least I spoil the movie for you).
For my sins, I work in Education supporting PeopleSoft. That means that I do work in COBOL on occasion. I am not tasked with writing anything new in COBOL, but I so quite a bit of analysis and support. That is: I _read_ COBOL more than I write it.
There are three flavors of COBOL that I deal with: PeopleSoft delivered, Vendor delivered, and University modified. Most of the work I do in COBOL breaks down to reading the code to determine why a given behavior is observed. Only once (in University modified code) have I needed to make an actual edit. The rest of the times I either modify the flow of information into the COBOL code or I modify the resultant after the code has run.
In brief, the story isn't AI as an accelerant. It's someone finally letting loose their internal knowledge to build to spec rather than buy.