Worse, I'm someone who's been reviewing code for a long time. And it's not much different now than it was before.
[1] In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS 2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always makes my back just crinkle up at the thought of the whole thing.
And in any case, if the code you had experience with (and produced?) before AIs was stack overflow answers pasted together, it's not surprising that you don't see any worsening.
Btw, if your idea of LLMs is of something doing "mathematical approximation", you have some reading to do; and I won't say what I consider pretentious BS.
I believe that 2 programs that execute the same are of equal value, no matter the intentions of the person writing the code (or lack thereof). If you read the article, you'd probably know what I was referring to:
> But at least we know that each line, as bad as it can be, was added by a human for a reason.
That's what immediately preceded the bit I quoted, and the entire point of my critique is that this author is treating human intention in coding as intrinsically valuable.
And rather than snark, I'd love if you actually explained why me calling LLMs "mathematical approximations" of their training data is inaccurate? They're literally weighted vector graphs of their training data.