The thing to look for is how they go about solving a problem. That's the key. Coding is easy. Figuring out what the problem is and how to go about solving it, that's the hard part. Especially given that the problem the user says they need solved is often not the problem they actually have.

Grade homework on completion and be done with it. Then schedule in-class quizzes and exams, where students are expected to show their work as well as the results and do it hand-written. That makes it hard to access chatbots, and even if students do the drudgery of transcribing the chatbot's output will discourage them (if they were willing to do that much work, they wouldn't be trying to skip the work using a chatbot). They may skate by on the homework, but the exam scores will show whether they actually learned the material or not.

They wouldn't be talking about this stuff if they weren't trying to scare people into giving them regulatory capture.

Instead, the people running the AI need to be charged for any crime it commits and go to federal prison. Then these random little "rogue AI" incidents would stop instantly.

Volume over time. Git is designed to allow offline work, so each working copy has it's own repository you commit to. With a monorepo that's a lot of history that isn't being used by any one agent working in only part of the code. So they uninvented Git, removing the "enable off-line work without a connection to a master repository" requirement. Which put them back at the requirements that spawned Subversion. And proceeded to re-implement Subversion. Badly.

I mean, come on. The freezers are on the Internet, no firewalls, fully accessible to anyone with a browser. Their "security" consists of rotating the admin password daily... to the current date. There are guppies out there that could gain access to these. The root cause here is willful negligence by the retailer's IT department.

The way you deal with Flock and their cameras is that you tell them you are terminating your contract with them and will be remitting payment for the remainder of the contract term. They have 30 days to remove the cameras from your property or arrange for removal. If the cameras aren't removed, you will remove them and store them at Flock's expense until Flock comes to pick them up or makes arrangements for pick-up.

Then you send them their money and, if the cameras are still there after 30 days, take 'em down and put them in storage. The cameras may belong to Flock, but it's still your property they're mounted on and Flock no longer has any right to have their stuff on your property. Don't argue with them, don't get into a debate with them, just do as you said you'd do. Sure they could take you to court, but seeing as they've received all the money they'd've been entitled to and their property is sitting there nice and undamaged waiting for them to come get it the court's going to ask why their case shouldn't be dismissed for failure to state a claim.

No, if you read it says that read performance is pretty much equal to uncompressed DRAM so you don't have to take a latency penalty.

Those "very special" use cases are actually fairly common. I routinely deal with data structures in software I write that are read-mostly: large data tables that are accessed in the inner loop (so need fast access) but whose data is updated infrequently (anywhere from minutes to days between changes, and often the changes are in batches so many changes can be applied in one operation). Being able to put them in compressed memory would free up a lot of normal memory for things that do actively change, which would speed up the application noticeably.

I don't think CRAM is a solution to the current memory price crunch, but it's certainly an interesting idea. The Redis cache software, for example, would probably benefit highly from higher capacity. And of course the same techniques can be adapted to flash/SSD drives where the memory itself isn't necessarily the speed bottleneck.

Save that a single human putting in actual effort can't turn out several dozen PRs a day, every day. That throttles the PR volume to a manageable level for the maintainers.

The answer is a simple "No.". Don't allow them. The vast majority will fail to meet reasonable criteria for acceptance, which is enough of a reason to reject them. For the rest, even if they're acceptable in terms of quality, the sheer cost of reviewing every pull request in detail and sorting the minority of acceptable requests from the swamp of slop will itself damage the project, diverting maintainer time away from feature work and fixing bugs, badly enough that it's not worth it. I think this sums it up nicely:

Why should I spend my time reading something you didn't care enough about to spend time writing?

No, they're already training it with its own dogfood. They don't need contractors for that, because they can do that themselves. They're just also paying people to add human data.

People seem to only have memory that goes back two years.

We went to war with Iraq due to faulty intel. No AI was involved at all, at least not in the modern sense of the term. Just a human expert hallucinating a bioweapons lab from a blurry photo.

Russia almost nuked us due to a faulty machine sending a false positive about a nuclear attack. Definitely not AI.

OpenAI's failures prove that the corporations are the only ones that can be trusted!

I'm not sure what you mean when you imply that AI doesn't understand storytelling. It's not *great* at it, but if you formalize the process (outlines, character profiles, world details, external notes, and so on) you can get something coherent if you use a decent AI.

If artificial superintelligence is a thing, we're going to need it to defend against it.

Honestly, I don't see this law passing anyway.