With my kids I drew the grumpy line at Minecraft's new Autojump setting tho ... They had to learn with that disabled.

Anyway I think GP has a point worth considering. I have had a related hope in the context of journalism / chain of trust that was mentioned above: if anyone can produce a Faux News Channel tailored to their own quirks on demand, and can see everyone else doing the same, will it become common knowledge that Stuff Can Be Fake, and motivate people to explicitly decide about trust beyond "Trust Screens"?

I wrote an answer there that produced these diagrams from fairly few lines of code.

The question there referred to same now-broken link mentioned above so the origin still unknown.

With this I can pinpoint the exact first bug I created, and debugged. The year was 1991 +/- 1, the place was Canberra Australia. For unknown reasons that changed my life forever, my Dad got on board with this "computer" thing and bought an "Osborne" 486 PC. That year I went to the school fete and, for AUD 0.20, picked up a used copy of this book, leafed through the pages, settled on Hammurabi, and after some struggle and discussions with friends, managed to run Q-Basic and typed this program into it. And it sort of worked, but something was wrong, and after much experimentation I found that on line 11 (only today, with this post can, I finally state the true line number) I had written "LET P=P+1" instead of the correct "LET P=P+I". After a fair bit (days) of trial and error and 10-year-old reasoning, I figured that out, and so it began.

This is how I wrote unit tests when I worked on Mathematica: try out every edge cases of the function in a notebook, and then use a tool to extract all the input/output cells and convert them to tests. I didn't know the term reify for this practice, I like it!

Previously there was a tension between easy-to-write (helper functions to group together oft-repeated lines of code, etc) vs easy to read (where often modest repetition is fine and is clearer). I felt this tension a lot in tests where the future reader is very happy with explicit lines of code setting things up, whereas the test author is bored and writes layers of helper functions to speed their work up.

But for LLMs, it seems readability of code pretty much equals its writability?

To make code more authorable by LLM, we approximately just need to make it more readable in the traditional sense (code comments, actual abstractions not just code-saving helper functions, etc).

I don't think that's fair. Rather, IPython, and later Jupyter, explicitly (successfully) sought to create a Mathematica-like notebook experience for Python.