Then how do you log in? Not all sites let you keep password logins after.

Then passkeys are a guarantee of account loss, if there is no reasonable way of recovery.

Yes, that is what everyone keeps complaining about and the people who insist passkeys are the best continue to loudly and totally ignore.

The repeated response to "I lost the passkey, what now?" is apathy. It is your fault, you should have done better, eat it loser.

Because companies built passkeys for their own needs, not for users. In a managed device setting, there is a response: You go to IT and get provisioned new credentials. These companies don't care that you get fucked because they just don't care about your needs at all.

Your passkeys should go in your password manager.

Just like breaking crypto in the age of cloud is more about cost than time, this will lead to legal attacks based on the same principle. The biggest wallet wins.

> The biggest wallet wins

This was already always the case. If anything, making this more accessible will reduce the barrier to entry for whether or not it's worth your time to take on a case. Instead of 50 lawyers spending 100s of hours on a case, you can have 1 or 2 lawyers + Astra working on it and if there's a case you can add more real lawyers.

There are other possibilities:

1) Lawyers are not as naive as software engineers and will fight being replaces by new laws.

2) If they are replaced, OpenAI will take a cut commensurate with the amount in dispute (OAI, please credit me for the idea in the IPO brochure).

Many lawyers are owners/partners compared with software engineers who are more like cogs in the machine. They also bill hourly/contingency per case compared to engineers who are salaried. If a partner in a firm thinks they can take on more cases because of AI assistance then they will because that's just more money in their pockets.

That's already the case in law because you could just hire the best or most lawyers.

Yes, there's been a massive explosion in pro-se litigation. Courts will adjust accordingly, many already have.

That’s how the legal system in the US has always worked though

With regard to certain legal questions this has always been the case. AT&T Fought the US Government for 20 years and eventually won because the government gave up. Without some kind of national anti-SLAPP law we're all one irritated oligarch away from having our lives financially ruined.

I am curious what level of trust established law firms treat LLMs with.

They’re not stable except at L4 and L5, and they all assume oke body to be massless. Arguably they are 2-body orbits for that reason. Not sure but suspect that this atlas contains non-massless bodies.

I have my skills in my dotfiles repo, then symlink them to my home directory and/or projects where I want to use them. Project specific ones go into the project.

I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.

Isn’t that what the agents.md in your project is for?

It's possible I invented skills before they were common. I've always had some instructions in agents.md that are something like "when working with typescript, read prompts/conventions.ts.md, when working with our fooBar module, read prompts/foobar.md"

I'm not sure if this differs greatly from skills. Maybe my wording makes these "skills" less likely to be read at the correct times, but I haven't seen an issue.

I try to keep agents/Claude.md as tiny as possible. With high level "truths" that don't change. Stack used, invariants, file structure, and some scripts.

Skills are more for things you do often. I run mutation tests, type check,linting,etc. I _could_ just prompt and copy/paste the same prompt each time I need to, or I can just run /tests.

I also have skills for specialized tasks I need every once in a while, like a ux skill, a text skill optimized for xyz, etc.

Most guidance I’ve read, and experienced success with, is keeping a lean agents.md file and building out a tree of docs or skills that an agent can navigate via progressive disclosure.

Depends on how much information and details you have. The agents.md always goes into context. Detailed testing or process information might be excessive, when agent is working on UI. Skills are pulled when needed.

I handle the context problem by splitting the details to dozens of small md files. Agents.md acts as a router that directs the llm to correct documentation file/folder according to the task at hand.

This documentation is its own git repo, and the agents.md file has an explicit instruction to update the docs when it has learned something general that can be useful in future sessions. I then occasionally review and prune those docs.

That's exactly what skills do.

The description in the front-matter (at the top of the skill markdown file) is the only thing in the context and used by the agent to determine when to read in the rest of the skill file.

yes, it is. it's almost exactly the same thing.

skills are just an agents.md broken up into chunks so you can manage and share them separately. unfortunately there's no real good workflow for managing or sharing them separately, so most people end up treating them exactly the same way they do agents.md.

Skills are evaluated by short description whether to read them into context.

Skills itself may be lengthy so...

Cool idea! I think it would look better as a function than an alias, but that doesn’t matter much.

I’d be curious to use them on larger data sets. Log files, for instance. High volume, might be low value per line but not much cost per token if you already have a gpu to interpret them using a LLM.

No way spark is faster at 100 GB!

Apple airtags last maybe a year on a CR2032, from experience.

I mean, airtags are doing radio stuff at a regular cadence. I've noticed they update once every 15 minutes, so they are turning the radio on to do whatever BLE triangulation they need to do 96 times per day. That's milliamps over at least a few milliseconds to wake the radio, do whatever triangulation is needed. It's amazing that they last that long considering what they are doing. I think they are using Nordic NRF54 internally so it's testament to the power efficiency those chips are capable of.

Airtags don't do any triangulation. They just send out a BLE beacon periodically to any iPhone within earshot, and also spend some time listening for new instructions that almost never happen.

They have no idea where they are or what their airtag/BLE neighbors, if present, are doing. They don't grok GNSS or wifi. There's nothing for them to triangulate or trilaterate or tri-anything when they're just sitting there.

So yes: They are indeed pretty tidy about energy consumption. They accomplish this in large part by being very simple in normal operation and leaving the heavier lifting to the world of iPhones with relatively enormous batteries that get recharged ~every day.

Energy loss from air resistance typically is quadratic, not exponential, with regard to velocity. So it’s worth much less than you’re arguing. And the arm has to rotate from what I can understand, so the end rotational velocity - and hence, rotational energy - would be the same?

Isn't drag either linear (proportional to velocity) or quadratic (proportional to velocity squared) depending on the scenario? But yes quadratic for things at this scale?

Drag is linear with velocity under Stokes' Law which assumes laminar flow and a very very low Reynolds number, and does not apply to ballistic projectiles flying through air.

Aerodynamic drag on the kinds of things that are involved in trebuchets is always quadratic with velocity.

Any idea how adding a flywheel to the system would change it? Could we store more energy in the arm?