My prediction is that there will be a Cambrian explosion-like event in software practices for 5-10 years (assuming continuous broad affordability availability), because LLMs can afford us a lot of freedom in trying a lot of new things including writing new tooling and changing the process. There's a lot to explore and I guess we'll collectively see what sticks.

Author here. Here is my PoV on that evolution.

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.

I'm currently running on a fork of Helix text editor, which I heavily gutted to replace the block cursor with a beam-style (like one in insert mode, but just all the time). Since the maintainers are drowning in PRs (472 open ATM), I understandably don't expect them to have time for my weird ideas. Then I pile on top whatever PRs I want that I find useful out of these 472, and with a little bit of LLM help I have a very different text editor than the upstream.

That's exactly the same viewpoint I have.

How do you like Helix as a starting point? Currently, I'm having Claude write a little personal text editor with CodeEditTextView as a starting point and now that I saw your comment I suddenly realized I mostly like using a modal editor and only didn't do it here because I'm moving from a webpage (where Vimium style stuff never appealed to me). Good hint that. I wonder if neovim's server mode will be helpful to me.

From UX perspective modal editing is all I care about and I just got used to Helix. And it's very feature complete and relatively stable, so hacking it and maintaining bunch of patches is not a lot of churn in practice.

I do exactly that also, like ten thousand of other emacs users. We can customize our editor with a proper language, no need for forks.

If you read the post till the end, I am open for lots of forms of collaboration. Its just sending chunks of code diffs around is becoming increasingly like sending diffs to resulting binaries. Just inefficient.

Yes. At this point a prompt that produces the desired result is more useful than the resulting code in a PR. Effectively the code starts to have properties of a resulting binaries.

Non-technical users might not be aware of much.

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.

P2P? I have a p2p social network with a public/demo instance hosted at https://rostra.me .

I wish I had your problems. :D . Problems that are really only a mild inconvenience, and can be solved with a single line in hosts file.

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).

This encoding is so long, that I'm more likely to remember the raw address. :D

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

No need to type `::1` anymore, you can instead just type `The new times take now beneath the new time while new times take the new year.`

OK. That's much easier. :D

You can make unique local address subnets with simple addresses.

I use a simple one like `fd10::1/128` and `fd10::2/128` and so on

Technically speaking RFC 4193 says you should use random bits. But I don't care.

These ad companies pay for transfer too.

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