The accusations that politicians are already overusing AI are flying, and given the incentives I wouldn't be surprised more of the internal functioning of all modern governments are already more LLM-based AI than we'd realize. Or particularly appreciate.

By that I don't mean necessarily the nominal function of the government; I doubt the IRS is heavily LLM-based for evaluating tax forms, mostly because the pre-LLM heuristics and "what we used to call AI" are probably still much better and certainly much cheaper than any sort of "throw an LLM at the problem" could be. But I wouldn't be surprised that the amount of internal communication, whitepapers, policy drafts and statements, etc. by mass is probably already at least 1/3rd LLM-generated.

(Heck, even on Reddit I'm really starting to become weary of the posts that are clearly "Hey, AI, I'm releasing this app with these three features, please blast that out into a 15-paragraph description of it that includes lots of emojis and also describes in a general sense why performance and security are good things." and if anything the incentives slightly mitigate against that as the general commenter base is starting to get pretty frosty about this. How much more popular it must be where nobody will call you out on it and everybody is pretty anxious to figure out how to offload the torrent-of-words portion of their job onto machines.)

One of the major challenges with "Big Bounce" that media coverage of it tends to overlook is that it is not entirely clear how the previous universe, which is presumably high entropy if it's supposed to be like ours, becomes the low entropy feedstock for the next universe. There's still a "And Here There Be Magic" step there.

I'm not saying there's no solution; indeed, this is the sort of thing where the problem is that the profusion of proposed solutions is exactly the thing that shows there's a problem there. I think people tend to intuitively think that "lots and lots of possible solutions" is somehow better than "no solutions at all" but they're actually nearly the same thing.

Rails has been around for time to change the calculus on it too. It came out in 2004. The smallest instances you can get today on AWS would have counted as fairly powerful servers back then (with insanely fast CPUs), and by the second or third smallest you're beyond anything available at the time, and there's still room to run after that.

Even the slowest web frameworks running on modern hardware take some quite substantial load before they're a problem. It's good when choosing a framework to consider if you're doing stuff where that might be a problem, but it's also good not to overestimate the performance needs for your site.

I can tell you've not been involved in defending against an active attack. You, as the defender, do not get to play the game of "well, if I squint and read it that way, that attack wouldn't work". The attackers get to play "well, hey, if it turns out I do this and that and push it through the other thing, I get access". They are the ones who get to flow through any crack they can find. They are the ones who get to do logic chopping like you're trying to do. You don't get to argue "Well gosh, that team shouldn't have left that one permission open on that one system, that's not a best practice, if they'd followed best practices 100% of the time the attackers couldn't have gotten in...". Your job is to pick up the pieces.

"Though, if someone gets that far, couldn't they also install a key logger on the users system?"

There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.

When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.