Wherever we have enough redundancy that we have to tell a tool to write out more code for us within certain parameters, is somewhere we have yet to create the r

Wherever we have enough redundancy that we have to tell a tool to write out more code for us within certain parameters, is somewhere we have yet to create the right high-level abstractions. This remains a problem even after LLMs do some of the work for us. The whole point of making more expressive languages and APIs is that we should be able to solve large problems with only the required amount of specificity in each instance, leaving only the code that is the right level of detail for someone to be able to read, understand, and maintain in future. In the ideal extreme, it shouldn't be any more difficult or tedious to write the code to solve a problem as it would to give the LLM a description of the solution -- if the description was precise and unambiguous then code of similar length should have been able to encode the same. There are many ways that modern programming continues to fall short of this, and that's a problem we should still be working on instead of giving up on. Even if writing and maintaining code are completely obsoleted by LLMs, we're still going to have to demand humans in the loop on review and testing before we risk life and limb deploying that code. Code still has to be understandable by humans, so it still has to be written with appropriate abstractions to make review accurate and tractable. We still have the same incentives to want expressive languages and APIs. If we give up on that and bank on LLM generation instead, we'll stop making progress on expressiveness and be stuck with a stale snapshot of today's programming language evolution, that LLMs are limited to writing and humans are limited to reading forever. Without direct disincentive for writing and maintaining that redundant volume of code, the inevitable review will suffer the most.