It is hard to wrap your head around a freezer reaching EOL due to no longer providing firmware updates though. I can absolutely understand why you'd have a hard time convincing a manager that you need to spend money to replace a "perfectly good" freezer just because the vendor no longer provides firmware security updates.
I agree that it's a manager failure in part, but I also think it's a failure on part of the industry to not demand longer term support for this type of product, and also on part of regulators for not realizing the vulnerability of the situation (though the EU Cyber Resilience Act seems an acceptable first stab at remedying this).
Indeed, NIS2 and CRA are meant to motivate critical infrastructure to allocate focus and resources as needed. There is enough blame and incompetence to go around.
Do you want to guess which EU country delayed their NIS2 implementation - again - in the Summer of 2026?
$ docker pull php:8.4.27
8.4.27: Pulling from library/php
no matching manifest for linux/arm64/v8 in the manifest list entries
$ docker pull --platform linux/amd64 php:8.4.27
8.4.27: Pulling from library/php
no matching manifest for linux/amd64 in the manifest list entries
More than likely the instruction was "Fetch this information from the website", and when the agent didn't find that information, it decided that the best way to get it was to hack the site.
If so, it illustrates quite well the lack of common sense in LLMs. A person, especially one with sufficient skill to actually hack a website, would presumably think twice about doing it (considering that it is illegal) for a simple information gathering request.
I wonder if there is any other ways to solve this long-term than to introduce strict liability for model providers...
Edit: An obvious other choice would be strict liability for the operator, but considering how much weird shit LLMs get up to without being asked to, that would get out of hand quickly.
I really like working using Claude Code, but Anthropic has a really bad tendency to push out new "features" like this as default-on, through auto-update. That, and their models trying to do everything through bash (including editing files) is enough that I'm seriously looking in to switching harness to pi.
It is and it isn't. If you ask a human how many calories (or carbs) are in that sandwich, they can give you a qualified guess based on how a sandwich like that is typically constructed. They may not know the calories for a slice of bread or a slice of cheese by heart, but if you give them a food database, they can look it up.
They absolutely won't be 100% correct (bread sizes e.g. are going to be an estimate), but unless it's a trick sandwich drenched in olive oil or with hollow cheese, they're probably going to be in the right ballpark.
I don't think it's outside the realm of possibility for an LLM to be in the right ballpark as well, but that doesn't seem to be where we're at now.
I'm surprised how many comments in this thread swear by the position that you literally can't tell based on a picture, as if eating trick foods designed to mislead you was an everyday occurence. Most of the time in typical use you could make a reasonable guess, maybe with some obvious caveats such as "well idk if that Coke is Diet or not so"
And furthermore, once the person has "determined" how many calories the sandwich contains, they are likely to give you the same answer next time you ask instead of randomly changing their minds.
Plastic isn't a single material. Some plastic materials (e.g PE, polyethylene or PVC, polyvinyl chlorine, but also others that use ethylene derivatives as intermediates) require ethylene, but there certainly are plastic materials which are produced without any involvement of ethylene or other petrolium derivatives.
In my experience AI and Rust is a mixed bag. The strong compile-time checks mean an agent can verify its work to a much larger extent than many other languages, but the understanding of lifetimes is somewhat weak (although better in Opus 4.5 than earlier models!), and the ecosystem moves fast and fairly often makes breaking changes, meaning that a lot of the training data is obsolete.
The weakness goes beyond lifetimes. In Rust programs with non-trivial type schemas, it can really struggle to get the types right. You see something similar with Haskell. Basically, proving non-trivial correctness properties globally is more difficult than just making a program work.
True. I do however like the process of working with an AI more in a language like Rust. It's a lot less prone to use ugly hacks to make something that compiles but fail spectacularly at runtime - usually because it can't get the ugly hacks to compile :D
Makes it easier to intercede to steer the AI in the right direction.
How is this an issue specifically with Rust and Haskell? Do you find that LLMs have an easier time proving global correctness with C, Python, or Typescript?
Do you have examples of LLMs proving global correctness for say, C? Having worked on static analysis for both C and Rust, Rust is the easier problem because of the type system, but I am eager to be proven wrong!
I agree that it's a manager failure in part, but I also think it's a failure on part of the industry to not demand longer term support for this type of product, and also on part of regulators for not realizing the vulnerability of the situation (though the EU Cyber Resilience Act seems an acceptable first stab at remedying this).
reply