Where I found these "agents" to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up.
How would the thing know what you were thinking and intending, what were the requirements, constraints, pre- and postconditions? How do you work around the risk that you end up with something that looks like useful information - but isn't ?
BTW, when I think about it, this will make Open Source code more relevant, not less. Because such code is often developed and reviewed via text exchange, by people which know how to communicate in writing, and therefore is on average far better documented than typical company code, which in future thanks to LLMs will drown even faster in technical debt than it does already.
That's also why good, experienced developers are so exponentially more valuable on complex systems. They need less coordination than multiple people doing the same thing, and that saves time. Plus really good people are also masters of technical communication which get straight to the points which are really relevant.
I am programming since a looong time, but I somehow never learned to touch-type. In 2020, my org then had mandatory home office and I used a nice FLOSS program called "TIPP10" to learn it - 15 minutes every morning.
It is certainly a little distraction less, no question. But typing speed is not programming speed. The most time spent is wondering what the requirements should say, thinking about how to make something work, or wondering what a piece of code one needs to use is supposed to do. And only after that comes inquiring with people what they were meaning or thinking.
Exactly what I see at work. I have a 'senior' C++ team lead which I have to explain over and over that for concurrent access of variables in device drivers one needs meticulous locking of shared variables. He was helding the view that when one thread is modifying a variable and another one is only reading it, then it's no race condition - even if the code crashes. And he still responds with generated code and suggesting names of members that don't exist.
What is best will depend on your exact needs. Which media formats? Do you need change history? How do you want the text stored? How long will you use it at max? Will it be used by other people? Does it need access over internet, requiring authentication?
Zim is already mentioned, it might be quite good for what you described. Being a desktop apo, it is quicker to access than a local web app. One which can be hosted local but is web-based and quite nice is Gollum. DokuWiki is more heavyweight (and perhaps more difficult to install) but has many features good for organizations.
The pandoc program can export/convert quite a few wiki markup formats to other documents, like LaTeX or PDF.
Because Wikis are often used for long term information storage where "long term" might mean 10 to 30 years, stability of the software and data being stored in readily accessible formats is probably important. As an example, there exists a nice Wiki software called MoinMoinWiki with many good features, but it was written in Python 2 and the developers did not have the time to port it, so it is likely advisable not to use it any more. Some languages have definitely more churn than others (with Common Lisp being on the extremely stable end).
I totally love how LWN.net always tries to cover all sides of a discussion in a balanced and positive view. (And I think they are worth every Euro and cent of donations...)
My question is, what would happen if free and/or open source software had the SOWPL?
For existing projects, that would only be possible if all contributors would agree to re-license their code. And unless there are compelling advantages for every one to do that, this is not going to happen.
Debian is not as easy as Ubuntu to set up, but much easier than in the past. And once set up, it's rock solid and has long term security updates, so if one can get a little help with the installation, I'd recommend it even to novice users.
And Arch is fantastic if somebody wants to learn more about Linux, because of its fantastic wiki.
And I agree that at some point it can become not worth the effort. But that point is pretty clearly after and mainstream statically typed language (Rust, Go, Typescript, Dart, Swift, Python, etc).
I really would like to believe that. And, as I said, I use Rust for larger, more complex programs with high requirements to performance.
But again, the statement in the second cited sentence - what proof does exist that this is true? I get that you can spend time and effort and get better correctness. I also get that better ergononics - like the far better error messages which the Rust compiler has compared to a C++ compiler - can possibly offset or perhaps even outweight the extra effort. And I think this probably increases with a programs size, complexity, and life time.
But to say it is always less effort if you use Rust or Idris, for any kind of program - I think that, even when subtracting the amount of becoming familiar with it, well this is a strong statement, and I'd like to see some evidence for it.
The problem with typing is that it does cost time to apply it - the stronger the typing, the more time. And at some point, the extra time spent to get the typing working will inhibit other things that would improve quality, such as testing, or writing detailed, clear specifications. For example, if stronger typing is really always better and Rust is better than C++ or Go, then why isn't it better to write instead everything in Haskell, which has a stronger type system than Rust? Or F# instead of Java? And why not annotate everything that involves threads in TLA+ even if it is known to be very time-consuming?
Though I agree that there is a counter-argument which is related to the conditions of modern commercial software development: Anything that improves quality does cost a bit of time. In much of commercial software development, there is a lot of time pressure, so there is a strong incentive to cut all these corners and produce the fastest thing that somehow works.
Now, with languages like Rust, the code would not compile and work without the typing being right. So that's kind of a protection or dam against that pressure. You can say: "Boss, alright, we need that as soon as possible - just wait a minute, I need to make it compile" And perhaps you can say: "See, our competitors use Rust and they ship faster".
The Wright brothers actually were big fans and brilliant practitioners of the scientific method, and it is fascinating to read how they worked. They invented laboratory aerodynamics. And they were not iterating fast - given that so many early aviation pioneers had died in crashes, they took their time and made a lot of small experiments, and this allowed them to realize that control is essential for safe powered flight, and they invented the control system which until today is the base for all fixed-wing planes.
In Java, this wouldn't cause a crash or an incorrect behaviour of the runtime. Java guarantees that. One still needs locking to keep grouped changes in sync and ordering of multiple operations consistent, but not like in Go, C, or C++.
Also, it is certainly possible to implement the "shared access xor mutating access" principle that Rust implements, in a dynamically typed language. Most likely this won't come with the performance guarantees of Rust, but, hey, Python is 50 times slower than C and it's widely used.
Why would it be painful?