When you can identify the nature of the traffic (quickly in realtime, based on simple deterministic rules), you can protect the resources: you can rate/concurrency -limit the AI scrapers in the name of saving resources for the real humans, effectively putting the scrapers in a lower priority band (which is how it generally worked for search engine scrapers before!).

The problem is they're using resiproxies to disperse and whitewash their traffic, making it extremely difficult to tell their requests apart from the legitimate human requests. They're basically lying to us about the origin, and thus denying us the ability to put them in a lower priority band than humans.

They may scrape us at, say, 25K reqs/second, but it's coming from 50K random residential eyeball IPs at an average rate of only 0.5 reqs/second/IP, and then they're intentionally lying with the UA and headers and other fingerprint details as best they can to "blend in" with the humans so that we can't differentiate.

Let's do an analogy: Imagine if there was a neighborhood grocery store you and all your neighbors rely on for food. It's cheap because they keep their margins low, and more importantly the next store down the road is like 50 miles further away. That store 50 miles down the road also charges double the price. Now they've decided to play arbitrage: they load up 100 employees in the back of an air conditioned semi, clothe them to look like local shoppers, park it 3 blocks from your neighborhood store hidden inside a fenced property, and have them all go in and buy out all the inventory in the store over the course of a couple hours. The store just looks like it's having a great sales day at first. All these customers waiting in line, each getting just a few things at a time. But two hours later, the store shelves are empty, the semi is loaded up, and they're headed 50 miles back to double the price and sell it to someone else. You go in to buy some veggies to cook dinner and there's nothing to buy.

We've been playing this game with AI scrapers and resiproxies for way too long, and someone needs to hold them accountable for their fraud.

* General-purpose Semis for commercial hauling. Yes, there's some EV Semis on the road today - pilot projects, or specific routes on specific schedules. But there's a lot of general purpose semi-hauling that happens every day on odd/long routes without sufficient chargers in the right places, and they need much bigger chargers. And then there's the specialty semis that carry large/wide loads. I see them almost every day in my area, carrying large chunks of power substations, heavy manufacturing equipment, blades for wind turbines, etc.

* Fire trucks, Ambulances, Tow trucks, Police cars - For various similar reasons, it's tricky with some of these, although in well-constrained cases and with extra vehicles on tap as backup (when the other one is low on charge in an emergency), maybe can kinda work, eventually.

* "Personal" trucks that see heavy towing/hauling use (think: hauling a livestock trailer or farm equipment or heavy materials (or maybe an EV race car!), possibly long distances on a regular basis). The battery range really suffers when you put all the extra weight and drag on by towing, and people aren't willing to turn what was a 5 hour diesel trip into a 9 hour trip with supercharger stops (more time in the heat with animals, more time on the road in general, and do you have to disconnect the trailer just to reach the charge cable?)

* Backup generator ICE engines - home, datacenter, industrial use, etc. The problem here is mostly runtime and peak watts of output vs cost. You can use a battery-based solution for most of these cases, but it currently costs prohibitively more for the same performance specs. When they're being used in austere environments, sometimes there's no electric grid to even charge from, so slap on a massive solar array cost, too.

* All military use of ICE engines in general (transport, generators, etc) - Not insignificant in scope and scale, and obviously they're not going to run EVs or find chargers on battlefields.

These cases will diminish over time, especially as we continue to make advances in charging and especially battery technology, but it will probably take a few decades because there's science challenges, not just engineering ones. The military case might never go away.

This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure. So many open-core models rely on this falsehood to rationalize their decisions. It should be possible to run large-scale important Internet things on Open Source code, too, for a variety of reasons.

Clippy would like to help you correct this statement.

https://en.wikipedia.org/wiki/Office_Assistant

It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?

Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.

If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.

And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).

Increasing the precision of enforcement makes a lot more sense for direct-harm laws. You won't find anyone seriously arguing that full 100% enforcement of murder laws is a bad idea. It's the preemptive laws, which were often lazily enforced, especially when no real harm resulted from the action, where this all gets complicated. Maybe this is the distinction to focus on.

For some of the free-er licenses this might mostly be just a lack-of-attribution issue, but in the case of some stronger licenses like GPL/AGPL, I'd argue that training a commercial AI codegen tool (which is then used to generate commercial closed-source code) on licensed code is against the spirit of the license, even if it's not against the letter of the license (probably mostly because the license authors didn't predict this future we live in).

* Let the pan cool (if I'm lazy or it's late, possibly this is overnight and then I do the rest in the morning).

* Scrape out any easy solid waste (burnt food bits, etc) with a wood spatula edge and throw the waste in the trash.

* Toss a healthy amount of salt into the pan and scrub the pan using the salt, with your hands/fingers. The salt is a great abrasive, like sand, but I don't want sand ground into my cookware, while salt is fine for food.

* Rinse out the dirty-salt-mess with plain water from the sink.

* Occasionally, if stuck-on things are particularly stubborn, repeat some of the above steps as necessary until the pan surface is smooth and clean.

* Wipe off most of the remaining wetness with a paper towel (the towel will probably look pretty dirty, that's ok).

* Throw the pan back on the cooktop, pour a few tbsp of cheap olive oil in the middle, and turn the burner on as high as it goes. Wait a few minutes for the oil to thin, spread, and smoke. Once it's smoking pretty well, shut off the fire and leave the pan to cool again.

* Later when it's cooled off again (possibly overnight or hours later, whatever), gently wipe off any excess liquid oil with a paper towel and store the pan back in the cabinet, ready for next use.

Based on this kind of thinking, my personal rules are: never spend more than 0.1% of take-home pay per time-period buying tickets, and only buy big-prize lotto tickets that have potentially-life-changing payouts.