@thomasfuchs I basically concur. I should have saved the link to it, but someone did a blog post awhile back that was basically "LLMs work well on your code because your code is shit." I have observed that, notably, they struggle with common LISP (although that may also be a consequence of the training dataset).

But, I would extrapolate to observing that most code is shit because it doesn't actually pay to write deeply concise code. There has always been a tradeoff between "getting it done today" and "getting it done perfectly," and the people who want the machine to do the thing want today. In fact, if you don't know your problem domain perfectly, I'd argue that trying to make your code optimally concise is counterproductive.

For those reasons, we can expect LLMs to be a time-saver to the extent that they can execute on "Take this fuzzy pattern and apply it to the codebase" and I expect they will end up a permanent tool in the toolbox (though not in their current form; a whole datacenter to do a 'soft-grep' is overkill, my prediction is that the open source projects will succeed in condensing the tool down into "works 90% of the time on the most popular languages and fits on one or two graphics cards").

@mark @thomasfuchs

And there's so much repetition in code. For an entity that has access to billions of lines of code most of what needs to be developed can be done with copy and paste.