That would make you, approximately, the best programmer in the world.
edit: in my previous post i meant that the higher the challenge of the program / the lowest possible lines of code to implement it will be the best possible software one can make. So a software rated 10/10 in every aspect possible implemented in just a single line of code is the best possible program. If you write it in more lines of code, it's worse in terms of value, if you decrease the quality but keep the loc low...it's still not optimal since you sacrifice quality, if you decrease the quality but increase the loc that's the worst possible case.
Agree that codegen can flip the effort from creating to validating. Some people believe the "true" intellectual capital created by the software development process is the understanding created inside the team's mind as they build it (not the code itself). Like, understanding of the domain, customers, market, how the software works, how they would build it again if they had the chance, their networks and relationships etc.
Probably it does hurt if codegen impacts that process. It's always been possible to externalise some of that understanding, by writing books, articles etc. I suppose what we are starting to see is that kind of intellectual capital will gradually reside in AI also. For well understood problems (TODO app, space invaders, etc) the model will have the actual understanding and everyone generating those apps for the first time would need to build it up.
I agree that 1 LOC that provides infinite value sounds like the "best possible program", but beyond that I can't see any hard and fast rules about LOC vs value, I think they're almost entirely uncorrelated. Mostly it's about what the lines do, but even then it's hard. What's more valuable: the bible, the script to star wars or a set of 747 technical manuals? Should they have used more or fewer words to achieve their goals?
Even with precise specifications the "best" way to implement large scale software is never clear and depends on many factors. Sometimes more duplication is better, sometimes you need more abstraction to reduce it. A lot depends on what your team (or contributors) are comfortable with and their abstraction ceiling.