1 year ago Claude Code was relatively new, and a first polished tool that really fitted my CLI-centeric dev-views. I used Aider before, but Claude Code was just much better. The autocomplete AI coders did not seem useful, and didn't have good integrations with Helix text editor. However even the frontier models were relatively bad in practice. Useful but not trustworthy at all. Being wrong/stupid 5-10% of the time compounds quickly.

6 months ago agents became really robust at just writing code they were told to write. Around that time I started really leaning into LLM-assisted coding, which require some skill, experience and adapting own workflows and tooling. And it takes time and effort.

Right now frontier models are really productive and robust. Sure it's still a fancy-autocomplete under the hood, so one needs to plan around that, but it's more common for Slopus finds bugs in my old human-written code, than I find bugs in its new code, especially that one can now easily write and maintain tons of tests which otherwise would never get done. LLMs don't have context and good judgment, so it still takes a lot of designing and steering the agent to write the right thing, but that's OK. And as the productivity bottleneck shifted very heavily from writing code to all other thing around it, it makes it very apparent that it's not that the clanker now that needs to get better, but the process around it.

E.g. most peoples don't really think or ask that their tap water be free of cholera and other harmful substances, and yet we might want to make sure that continues to be the case. So it's not strong argument worth arguing about.

The real argument is - how much a compromise a replaceable vs non-replacable battery is. And I suspect the biggest part of non-replaceable batteries is actually superficial vanity considerations (gee, is it 7mm or 6.5mm), and planed obsolescence making more money. But the technical aspects are still a valid debate.

My biggest and possibly only problem preventing me from going IPV6-only is that Github doesn't support it, and there's just too much darn software I need to needs Github. (Yes, I know NAT64 exist - it's just extra complexity for something that is not even my problem in the first place).

And I don't think I ever typed manually any IPv6 address other than `::1`.

Install AdNauseam if you have unmetered connection and let it download as much data from them as it can.

Well, a lot of C/Odin/Zig people will point out that Rust's stdlib encourages heap allocations. For actually best performance you typically want to store your data in some data-oriented data model, avoid allocations and so on, which is not exactly against idiomatic Rust, but more than just a typical straighforward Rust just throwing allocations around.

There's no point in messing with custom hardware, etc. We could host bunch of redundant p2p access points for everyone, and use p2p portable software for everything.

E.g. I'm building a P2P/F2F Social Media protocol that is very close to syndication platform. https://app.radicle.xyz/nodes/radicle.dpc.pw/rad:zzK566qFsZn... . I'm not saying that it's exactly the same thing as author is looking for, but the technical bits and even functionality are very close.