[pixl97]

>without even trying to understand it or think critically about what it does and where it might break.

You are living in a past, but one much farther back than you expect.

People were copying code from SO since it became popular.

People are including node modules blindly before AI.

Most developers suck, terribly. Maybe being on HN is a type of filter that shows you're just a little bit better than the average, but the number of developers on HN is small versus the total number of developers.

Edit: I was copying code out of magazines to get games running without understanding anything about it when I was young.

[aix1]

First of all, that's a very different sort of thing compared to blindly taking reams of code from an LLM. The amounts of code in a given SO answer or a magazine article are tiny and the code has undergone review of one sort or another. Similarly, if I take QR decomposition code from Numerical Recipes, that's quite likely to be better quality than what I -- or most folks -- can code up in a comparable amount of time. It's also an opportunity to learn by studying the code and the method.

Secondly, I am not talking about some abstract SWEs in a vacuum. This is happening to real people I work with, whom I know to be very capable. The lure of switching off the brain and just clicking "Accept" to some LLM suggestion seems too strong to resist. :(

[pixl97]

Really what you're saying is it is an issue of quantity.

> if I take QR decomposition code from Numerical Recipes,

I'm going to assume the vast majority of code written does not look anything like this, but is dumb little chunks of glue for other important chunks, that are quite often imported from other libraries.

As someone that is not a SWE looking from the outside, I think there is a disconnect between what a SWE is told they are getting paid for and what a SWE is actually getting paid for by (many/most) businesses.

You are under the assumption you are getting paid for writing code. But for the vast majority of business that is just the icky bits getting ground up in the sausage factory that nobody wants to know about. Management above you only cares about what gets wrapped in casings and is ready to sell to the customer (either internal or external). They do not care if the product is technically good as long as they can sell it. For each individual person in the company becoming a better programmer is hard to measure and rarely rewarded by the company they work for. Turning out tons of lines of code and applications that have at least some semblance of working is far more likely to get you a pay raise.

[aix1]

I think we're talking past each other a little bit.

You're talking in the aggregate and making some good points.

I am talking about what concretely I am seeing on the ground. It's become a little too easy to churn out junk that looks plausible enough to pass the initial sniff test but that ultimately results in negative productivity. Someone has to go back and not only redo the initial work but also deal with all the knock-on effects. It's unclear to me that these effects are offset by productivity gains elsewhere. This can also result in highly problematic incentive structures: the initial launch ticks some box, whoever did it gets rewarded and then someone else is left to pick up the pieces. Higher overall cost to the orgnisation and worse experience for the customers than doing it well in the first place.

Not totally clear how to fix this other than by shifting towards longer-term incentive structures (which have their own drawbacks).

None of this is completely new, but has become 10X easier thanks to the current generation of tooling.

This is in addition to my concerns around what this is doing to our junior developers' skills.

Maybe the tooling will soon get good enough that nobody has to ever write any code except for enjoyment, but it's not clear to me that this is the trajectory we're on.