111 karma · joined October 15, 2025
Perfect example of a non-sequitur. Irrespective of whether or not the statement is true, it has no bearing on the veracity of the original claim: that in the current market, the majority of workers simply do not have this leverage.
The problem, as I see it, with prolific use of AI to generate code is that it goes in the exact opposite direction. More and more code is bolted on top of existing code, more and more edge-cases, patch-ups, workarounds, etc. accumulate, the codebase grows and grows. In the end, no matter how good you are at understanding "code from questionable sources", you're still a human being. The AI can generate new code at rates several orders of magnitude faster than you can injest and understand it, and when your meat brain becomes exhausted, the machine does not tire. From a business perspective, your employer will weigh their options: they can wait for you to interpret the code and generate good code (whether by hand or by machine + human review).. Or they can just keep pulling the lever on the slot machine until it works well enough to sell. And for the business exec just looking for the fastest path to paydirt, I'm afraid the latter option is going to look way more appealing.
There's entire categories of entertainment media that use "unfortunate things happening to strangers" for comedic effect.
It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.
Courts aren't lacking in budget to hire more people. They're lacking in people available to hire, with the specific expertise that they need to fill any gaps. The legal profession, at least in the US, consistently has some of the lowest unemployment rates across the board. Unlike over here in the tech sector, the scarcity is in available talent, rather than available jobs.
1. You set up an aws bucket with some name (any name whatsoever).
2. You have code that reads and/or writes data to the bucket.
3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.
4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.
5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.
You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.
The fact that safari refuses to support modern features and is forced on ios devices makes it even worse.