It's especially a crazy assumption to make relative to the costs of employing a human. The costs of paying an entry level employee are unlikely to go down at all, and even if those costs do decline, there's a floor they can't drop below (minimum wage at the extreme end), whereas companies are free to optimize agentic costs as close to zero as possible.

So you are assuming that a cost which is extremely susceptible to optimization but which no one has yet seriously attempted to minimize will remain perpetually above a cost which is much less susceptible to optimization, is already subject to enormous efforts to minimize, and has a legally mandated floor. That seems like a bad bet.

It used to be unacceptable for companies to lay people off purely to improve their margins. It's a sign of how dark the times have become that now CEOs don't even question the acceptability of layoffs that aren't driven by financial distress. The idea that they owe any loyalty to their employees has disappeared entirely. And boy you couldn't have invented a more fitting name for an entitled prick of a CEO reveling in this neo-aristocracy: Prince.

I hope everyone who still works at Cloudflare takes note and starts looking for an exit, because it's clear their boss is just waiting for the first possible chance to cut them and they cannot rely on any glint of humanity from him. Longer term, I think these types of layoffs will prove counterproductive for exactly that reason. It is poisonous to company culture, and all but sure to drive away talent.

Also I have had to deal with multiple breaking bugs from Cloudlfare and their absolutely atrocious customer service over the past few months, so I pulled all my personal and professional sites. They are shitting out vibe coded crap and not providing even minimal customer service anymore, even for an account spending six figures with them annually. Which might not be a huge number by CF standards, but surely should be enough to offer at least some human customer service to handle breaking bugs. Instead, all I got was a chatbot that regurgitated their FAQ and then gave me an email address that was no longer in use and a phone number that was disconnected. It was bafflingly unprofessional. So clearly whatever changes they have made are not working, and Prince is just too thick to recognize he is set to tank the company.

Also we are chasing a lagging indicator by focusing exclusively on the homeless population. The vast majority of people who end up homeless because of addiction would have benefited from some far earlier, far milder form of intervention, or from the absence of something that actively drove them into addiction, e.g. some quack pushing oxycontin on them because Purdue Pharma promoted it as non-addictive. Or job loss because of offshoring pushing them into economic despair that then drives addiction, which they are unable to recover from because of the lack of affordable or accessible retraining or educational opportunities.

In many cases over the last 20-30 years, it was the combination of both job loss and careless opioid prescription that pushed people into an unrecoverable spiral, especially in the rust belt, where the opioid crisis hit the hardest. We may not have fixed the job loss side of the problem, but at least doctors aren't pushing pills the same way they were 10-20 years ago after Purdue's corporate downfall, so the number of people driven into addiction-mediated homelessness by that disaster should at least start tapering off soon. But if we don't help people before their lives fall apart with a continuum of support options that are accessible before they are in deep crisis, and are accessible to people who are beginning to spiral but don't yet appear to be in deep crisis, it will cost far more and be far more challenging to help them recover once they are on the street.

I mean, why not? If it has learned fundamental chemistry principles and has ingested all the NIH studies on pain management, connecting the dots to fentanyl isn't out of the realm of possibility. Reading romance novels shows it how to produce sexualized writing. Ingesting history teaches the LLM how to make war. Learning anatomy teaches it how to kill.

Which I think also undercuts your first point that withholding "forbidden" materials is the only way to produce a safe LLM. Most questionable outputs can be derived from perfectly unobjectionable training material. So there is no way to produce a pure LLM that is safe, the problem necessarily requires bolting on a separate classifier to filter out objectionable content.

[1] except perhaps read-only credentials to help diagnose problems, but even then I would only issue it an extremely short-lived token in case it leaks it somehow

There's not a lot of UI surface area that a user can touch that can even theoretically affect the NS detection process because that process happens in CF entirely "under the hood" as it were. You more or less just have to wait for CF to detect the DNS changes. That said, I tried everything I could think of to try to trigger their detector to reset, including deleting and recreating the site from scratch in CF. After another few days of combing through CF docs and forums, and after changing and reverting every setting I possibly could, I concluded there was no workaround available to me as a user and tried to reach CF as I described above.

Having done this many times before, I am quite certain that I set the nameservers correctly. I even had two other very experienced engineers review what I had done to make sure I wasn't falling victim to some mental blindspot that prevented me from recognizing what the problem was. I think every SWE has had the experience of spending an enormous amount of time debugging a problem only to realize they mistyped a magic string somewhere, but for whatever reason their brain just straight up refused to recognize the typo, but unfortunately that was not the case here. The other engineers saw what I saw and also were unable to fix the problem.

I was subsequently able to set DNS up on Vercel without any trouble at all. Bottom line, the issue was almost certainly a bug in Cloudflare's code. That indicates a code quality problem to me, which, in combination with the reckless incompetence that it takes to try to automate customer support with a chatbot that doesn't even have accurate information about their own processes and basic contact information, never mind a reasonable escape hatch to actual human-provided support in unusual cases (even for a paying customer), has led me simply not to trust them to deliver a reasonable quality product anymore.

They didn't even maintain any mechanism for reporting bugs to them, which is just insanity because it means there is no way to inform them even in extreme cases like a critical security bug. I get that they want to cut costs by reducing the employees needed to deal with customer service complaints, but it costs practically nothing to have a little feedback form somewhere, especially now that an LLM can handle most user feedback processing. Or failing that, a functioning support email address or phone number. But they can't even clear that incredibly low bar.

All of these issues could have been avoided with a very limited application of ordinary common sense and foresight. Whoever programmed their chatbot did not take the time to set up a decent RAG system with up-to-date information about their support processes and how to contact them, even though that is an obvious requirement for a tech support chatbot. They should also have recognized the business risks posed by exposing their customers to a system which lacks any escape hatches for outlier cases requiring actual human support, which risks alienating customers like me by forcing us to jump through Kafkaesque bureaucratic hoops just to get simple problems addressed, and--even worse--making it impossible to resolve such problems after jumping through all their hoops. The team implementing this chatbot didn't even think to include a contact form as a last resort method for reporting problems to them when the chatbot gets in over its head.

Most people hate this kind of LLM-provided customer support without any human escalation options, because the bots often end up uselessly looping through some debugging steps that simply do not work for the customer's specific issue for whatever reason, which feels like slamming your head against a wall repeatedly. It's a truly infuriating user experience and is practically guaranteed to destroy the business's public goodwill and reputation.

All of which means they are gutting their customer service department following some process that lacks access to these very basic insights, which screams mismanagement to me.

I'm not exactly a huge customer, but between my personal and business sites, I plowed $45k into CF last year, and will spend not another penny on them this year, or ever again. Maybe that's not huge spend in the grand scheme of the tech industry, but at a minimum that amount of money should entitle me to some human-provided support. My annual spend alone could provide the budget for multiple offshored CSRs. If I am spending enough money to buy a car, the least they can do is let me send them an email when I have a problem instead of just throwing me to the wolves.

Ultimately, they have a much weaker moat now than at any point in the past, because LLMs make it so much easier to build out critical functionality in-house that previously would have been worth paying someone else to manage via a SaaS. And while I may not be a big enough customer for them to worry about in and of myself, I am also not the only person affected by these business practices. Every affected person increases the reputational harms suffered by Cloudflare, with another alienated customer like me bashing CF in posts like this or in conversations with their friends and colleagues in the industry. Those harms should be very concerning to CF's management because it is extremely difficult to recover lost goodwill.

I immediately pulled all my sites off of Cloudflare and I will never use that godawful nightmare of a company for anything ever again. If they can't even host a generic help bot without screwing it up that badly, why would I ever use them for anything at all, never mind an AI platform?

First, the issues you describe affect only unclassified public-facing web services, not internal DoD internet services used for actual military operations. DoD has its own CA, the public keys for which are not installed on any OS by default, but anyone can find and install the certs from DISA easily enough. Meaning, the affected sites and services are almost entirely ones not used by members of the military for operational purposes. That approach works for internal DoD sites and services where you can expect people to jump through a couple extra hoops for security, but is not acceptable for the general public who aren't going to figure out how to install custom certs on their machine to deal with untrusted cert errors in their browser. That means most DoD web infra is built around their custom PKI, which makes it inappropriate for hosting public sites. Thus anyone operating a public DoD site is in a weird position where they deviate from DoD general standards but also aren't able to follow commercial standard best practices without getting approval for an exception like the one you linked to. Bureaucratically, that can be a real nightmare to navigate, even for experienced DoD website operators, because you are way off the happy path for DoD web security standards.

Second, many DoD sites need to support mTLS for CAC (DoD-issued smartcards) authentication. That requires the site to use the aforementioned non-standard DoD CA certs to validate the client cert from the CAC, which in turn requires that the server's TLS cert be issued by a CA in the same trust chain, which means the entire site will not work for anyone who hasn't jumped through the hoops to install the DoD CA certs. Meaning, any public-facing site has to be entirely segregated from the standard DoD PKI system. For now, that means using commercial certs, which in turn requires a vendor that meets DoD supply chain security requirements.

Third, most of these sites and services run on highly customized, isolated DoD networks that are physically isolated from the internet. There's NIPR (unclassified FOUO), SIPR (classified secret), and JWICS (classified top secret). NIPR can connect to the regular internet, but does so through a limited number of isolated nodes, and SIPR/JWICS are entirely isolated from the public internet. DoD cloud services are often not able to use standard commercial products as a result of the compatibility problems this isolation causes. That puts a heavy burden on the engineers working these problems, because they can't just use whatever standard commercial solutions exist.

Fourth, the DoD has only shifted away from traditional old school on-prem Windows Server hosting for website to cloud-hosting over the past few years. That has required tons of upskilling and retraining for DoD SREs, which has not been happening consistently across the entire enterprise. It also has made it much harder to keep up with the standards in the private sector as support for on-prem has faded, while the assumptions about cloud environments built into many private sector solutions don't hold true for DoD.

Fifth, even with the move to cloud services, the working conditions can be so extraordinarily burdensome and the DoD-specific restrictions so unusual, obscure, poorly documented, and difficult to debug that it dramatically slows down all software development. e.g., engineers may have to log into a jump box via a VDI to then use Jenkins to run a Groovy script to use Terraform to deploy containers to a highly customized version of AWS.

Ultimately, the sites this affects are ones which are lower priority for DoD because they are not operationally relevant, and setting up PKI that can easily service both their internal mTLS requirements and compatibility with commercial standards for public-facing sites and services is not totally straightforward. That said, it is an inexcusable shitshow. Having run CAC-authenticated websites, I can tell you it's insane how much dev time is wasting trying to deal with obscure CAC-related problems, which are extremely difficult to deal with for a variety of technical and bureaucratic reasons.

In extreme cases, that can manifest as autoimmune disease, when overly strong inflammation or other immune responses end up attacking not just foreign pathogens but the person's body itself. As another poster said, inflammation is a blunt instrument. It's a knob that can only be turned up or down, across the entire body. If you turn it down too far, you risk infectious illness. And if you turn it up too far, you risk damage to your organs.

Interestingly, there was a substantial increase in the incidence of autoimmune diseases in Europe in the generations following the Black Death, probably because people with excessively strong immune responses were more likely to survive exposure to plague bacteria. Celiacs or MS will kill someone much, much more slowly than bubonic plague will, so a disproportionate number of people with those or similar autoimmune disorders were able to survive to pass on their genes.