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.
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.