Passkeys are a potentially good technology, that is frequently implemented in an insecure and user-hostile way.

Good: a standard way for authentication that can be implemented in common on client and server, such that the user doesn't need to know a secret.

Bad: Most OS and platform vendors breathlessly implemented this standard using their proprietary APIs and making it practically infeasible (read: impossible for typical end-users, therefore they won't, therefore insecure) to attempt syncing your passkeys outside their walled garden.

It is entirely feasible to implement passkeys in a way that users are in control and can freely move between devices and operating systems. But many implementations make that impossible, while still calling their implementation “passkey”.

So, we need to reject any implementation which puts any barrier to the user freely migrating and syncing all their devices regardless of platform.

Of course, that works only when everyone's in the same room. I don't have a good replacement for teams that connect remotely.

It also is framed quite insensitively to those who can't stand each day for multiple minutes at a time. Fortunately, accommodations can be made without much reducing the purpose of the procedure.

Yet another way that the good ideas from Agile got crushed to meaninglessness by Business Idiocy.

The whole point of the “stand up meeting” is, by forcing everyone to stand together, to encourage everyone to keep it brief and to the point, so it benefits everyone without sucking their time.

Screenshotting a text post on the Fediverse, to post an opaque image on the Fediverse.

The post was right there to be shared.

We shouldn’t even be in this situation, where just politely asking someone’s computer to delete files is effective.

Exactly, it's a problem only for those who have knowingly handed their development environment over to obey commands from an untrustworthy source.

If you're the one holding the syringe to your own vein and pushing the plunger, but you didn't think to ask what's inside first? That's no one else's fault.

This is a well targeted sabotage of a system that's causing untold damage. Of course it's going to annoy and surprise the people using the system it's targeted to.

any kind of undocumented subversive behaviour in your thing.

Fortunately, this behaviour is explicitly documented.

Without this, we wouldn't be sure the agent does a good job!

I've read that headline three times now, and it doesn't communicate what the heck the article is about.

I liberated the story for you (it’s Reddit) Thank you.

For those who want the full thread, here is an anonymous interface to it: https://safereddit.com/r/confession/comments/1q1mzej/im_a_developer_for_a_major_food_delivery_app_the/

The author made this story available to Medium members only.

Please either update the post with the URL that gets around this login-wall; or, remove the post because the article is not on the public web.

When I’m using AI for coding, I find myself constantly making little risk assessments about whether to trust the AI, how much to trust it, and how much work I need to put into the verification of the results. And the more experience I get with using AI, the more honed and intuitive these assessments become.

For a system that has such high cost (to the environment, to the vendor, to the end user in the form of subscription), that's a damningly low level of reliability.

If my traditional code editor's code completion feature is even 0.001% unreliable – say it emits a name that just isn't in my code base – that feature is broken and needs to be fixed. If I have to start doubting whether the feature works every time I use it, that's not an acceptable tool to rely on.

Why would we accept far worse reliability in a tool that consumes gargantuan amounts of power, water, political effort, and comes with a high subscription fee?

So, it was gambling, then.