Where do I point to when I want to know this? On a large and mostly LLM-generated codebase, I might dig through the code myself to find what needs to be changed where, but I would probably prefer to ask an LLM to do this.

Now if I had access to all previous prompts that were used in generating the codebase, it might very well be the case that I would prefer to work by changing those prompts and generating the whole thing again. In that case, the LLMs would basically turn into a compiler and the prompts would indeed become the new "source code". This is clearly not (yet?) a common approach to software development, but I wonder if it may become. Or should.

If one uses LLMs to generate the code, and others need LLMs to read the code, isn't this awkwardly close to someone publishing only compiled binaries and others then having to reverse-engineer these binaries in order to know where and how to patch them? Maybe the handicap is less grave, as the difference in strength of LLMs understanding code vs writing them isn't as huge as of decompilers decompiling vs compilers compiling code - but I think this difference still exists. It's still an advantage to have knowledge of the "secret" prompts that were used in generating the code.

I recently had to fight slop responses for months to get a simple bug report through on a public services website. Couple of years ago, I'd have received a "thank you" mail after a day, and the bug would've been fixed by the end of the week.

If I were to create an office suite that cares for interoperability, it would be based on markdown and CSS, viewable in the terminal, one could `grep` and `sed` and `git diff` through it, LLMs could read and write it natively, ... But I'm afraid it'll take another 40 years until we're there.