Also there's a widespread stress of "how will I get by?" among old people that rich people dodge.

And the people who make it a long time have probably learned how to push back against agents pushing them to work too much.

I keep thinking about Willie Nelson.

Amen. I've been coding a big hobby project in Rust since July, after having spent years using Haskell for such things. I chose Rust because the primary DB I wanted to use (TypeDB) only had drivers for Rust and Python at the time. Rust is popular relative to Haskell, so I thought others might be more likely to sign on, and the type system seemed almost as expressive.

But since purity is not encoded in Rust's type system, any function might do any kind of IO -- in particular, read from or write to disk or one of the DBs. That makes the logic much harder to reason about.

(Also, Rust's syntax is so noisy and verbose that it's harder to see what's going on, and less context fits in my head at one time. I'm getting better at paying that cost, but I wish it weren't there.)

I can't say I made the wrong decision, but I often fantasize about moving most of the logic into Haskell and just calling Rust from Haskell when I need to call TypeDB from Rust.

Db access in rust typically needs some sort of handle and a mutex. Limiting access to the handle makes the rest of the code pure with respect to the db. The handle plays a similar role to the IO type.

Actor-like patterns makes this nice. Message-objects can be passed to/from a module with db-access or other io.

How can you prevent code from creating a handle in a new place?

You can limit access to your db credentials. But other code can still launch missiles etc.

Agreed. Some strategies that seem to help exist, though. Write extensive tests before writing the code. They serve as guidance. Commit tests separately from library code, so you can tell the AI didn't change the test. Specify the task with copious examples. Explain why yo so things, not just what to do.

Yeah, this is where I start side-eying people who love vibe coding. Writing lots of tests and documentation and fixing someone else's (read: the LLM's) bad code? That's literally the worst parts of the job.

I also get confused when I see it taken for granted that "vibe coding" removes all the drudgery/chores from programming. When my own experience heavily using Claude Code/etc every day routinely involves a lot of unpleasant clean up of accumulated LLM slop and "WTF" decisions.

I still think it saves me time on net and yes, it typically can handle a lot on its own, but whenever it starts to fuck up the same request repeatedly in different ways, all I can really do is sigh/roll my eyes and then it's on me alone to dig in and figure it out/fix it to keep making progress.

And usually that consists of incredibly ungratifying, unpleasant work I'm very much not happy to be doing.

I definitely have been able to do more side projects for ideas that pop into my head thanks to CC and similar, and that part is super cool! But other times I hit a wall where a project suddenly goes from breezy and fun to me spending hours reading through diffs/chat history trying to untangle a pile of garbage code I barely understand 10% of and have to remind myself I was supposed to be doing this for "fun"/learning, and accomplishing neither while not getting paid for it.

Absolutely. Honestly some days I'm not sure the AI saves me any time at all.

But on the other hand, writing thorough tests before coding the library is good practice with or without an assistant.

Interesting, I haven't tried tests outside of the code base the LLM is working on.

I could see other elements of isolation being useful, but this kind of feels like a lot of extra work and complexity which is part of the issue...

The way I do it is write tests, then commit just the tests. Then when you have any agent running and generating code, before committing/reviewing you can check the diff for any changes to files containing tests. The commit panel in Jetbrains for example will enumerate any changed files, and I can easily take a peek there and see if any testing files were changed in the process. It's not necessarily about having a separate codebase.

Also: detailed planning phase, cross-LLM reviews via subagents, tests, functional QA etc. There at more (and complimentary) ways to ensure the code does what it should then to comb through ever line.

If you're really ambitious you'll use two UUIDs for the ID, because for an app in which at least a billion people have at least 327 million random v4 UUIDs, the probability of a collision will be greater than 1%.

What's the protein density? For ordinary mushrooms it's around 2.5% by weight, vs. around 27% for beef.

Comparing stocks to Flo's is perfectly meaningful. It's often done when comparing, for instance, the price of a house to one's yearly salary.

That makes no sense. House price/salary is used to compare payment periods or affordability. The context is important. Share value and GDP are totally different things and there is no direct relationship.

I often have them append to notes, too, but also often ask them to deduplicate those notes, without which they can become quite redundant. Maybe redundancy doesn't matter to the AI because I've got tokens to burn, but it feels like the right thing to do. Particularly because sometimes I read the notes myself.

The study is based on 100 cells from one 74-year-old man. The follow-up study will involve 150 individuals. I hope there's a very wide age range among them. They describe much, maybe all, of the variation as error, but one could imagine some of the variation actually serving a useful purpose and therefore existing even in young people.

Isn't the effect largely an age + lifestyle effect? Mutations increase as one ages, and things like smoking increase mutations (as the Nature write-up mentions).

That is such a beautiful analogy that now I will read your other comments.

Very occasionally I run into a speed glitch in Emacs but not nearly enough to drive me away, given that nothing else can do all the stuff it does.