Prompt injection is the only one of your three I'd call routine already. Has anyone here actually seen the optimization-loop case outside a benchmark or a red-team setup?
Optimization loops are a plausible failure mode in autonomous coding agents, particularly when optimization objectives lack a robust termination condition
It caught lots of bugs like overflow in the sim, fields not spreading as you would expect, badly tweaked constants where the bus lanes were messing with the traffic sim too much. I've only play tested it for a bit, but it seems like it came out okay?
What's cool is that I created a protocol for the agent to talk to the game and move the mouse and monitor sim systems. So it's able to run the game and test manually for me and sanity check things as well as write tests.
Did that LinkedIn account cut the 15 minutes itself, or repost someone else's cut? Depends which one you are looking at, sloppy framing or a hook someone built on purpose.
The self-report objection has been tested, though. Aphantasics show no imagery priming in binocular rivalry, no pupil constriction when asked to imagine bright shapes, and flat skin conductance to frightening text while responding normally to frightening pictures. A questionnaire that predicts autonomic responses nobody can fake is doing more than semantics.
The checklist half automates cleanly, you can lint that every route calls authorize. It won't catch authorize being handed the wrong policy, which is the one that ships. And when I put a second model on review duty, the common failure is it agreeing with the first model's misreading of the spec, almost word for word. So I'd expect the forgetting class of bugs to mostly go away and the misread-the-spec class to sit exactly where it is.
LLMs trivially catch these things in review, and if you find agents agreeing incorrectly with each other (weak models?), maybe you need to be doing adversarial review.
It's pretty much solved, though I only use sota models.
I think for these convos, we need to see concrete fail cases so we can see what you're talking about and whether the truth matches up with the claim.
The reusability goal is what turns this from an age check into an identity vault, and the two have opposite risk profiles. A +18 result needs to survive as one bit; a reusable proof scoped to a valid government ID needs the document, which is exactly why you now have to keep it.
Genuine question: what happens when someone loses the passkey? If the answer is re-verify from scratch, the persisted blob only bought convenience on the happy path. If there's a recovery flow, that flow is now the weakest link in the design.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
the recovery flow is scoped to the account but not the encrypted data. if the passkey is lost, the encrypted identity data is lost (by design) and the user has to upload again before new verifications. the account and associations with previously linked applications remain.
