Yeah the Mormons in Utah are of a much more vapid culture than those from out of state, I can say from experience. All of the out-of-stater Mormons I've met that were here for BYU and such, they all said they can't stand the people here. Don't blame them one bit.

Proprietary stochastic compilers. Hooray.

They're finally applying their 2A strategy to the 1A.

I wouldn't say it's random. But I do like referring to them as statistical code generators.

The assumption used to be that you respected the library enough and believed it was well reviewed and architected by the maintainer(s). But now even that's unreliable because libraries are being slopified at an unreviewable pace too.

> The assumption used to be that you respected the library enough and believed it was well reviewed and architected by the maintainer

I don't know many serious software engineers who'd take that approach, the convention was always to actually open up the code, evaluate the quality, see if they seem to know what they're doing, then chose the libraries you know works and could be adjusted to fit whatever you wanted it. At least for professional development inside companies, not a single library would be included unless you at least reviewed that the top-level dependency you pull in actually had code worth pulling in in the first place.

And this approach just as well today as it used to, you literally have to spend like 3-5 minutes browsing the code, evaluate the abstractions they've built and then say "Yes, looks good enough to try to use" or "Clearly these people just hacked this together as fast as they could".

> The assumption used to be that you respected the library enough and believed it was well reviewed and architected by the maintainer(s).

Let us be honest, for your average dev, the assumption was that the number of github stars, npm/nuget downloads was a god proxy for quality.

It's weird that you think humans weren't slopifying code until LLM's came along. At least now they are implementing tests and CI and far more documentation, updating API versions, etc. OOMs above the amount they did before.

I'd also wager that far more % of code gets more coverage of review, via prompting AI to do it, than it did before.

Most PR's pass as long as they A. pass checks, B. dont introduce regressions, C. fix a bug or implement a feature. People talk about this era of humans reviewing code with nostalgia... but that never existed at scale.

There's a lot to appreciate about the middle ages. It wasn't all bad.

> To be clear, I am not claiming that all human work will be automated away soon. Just that a huge portion of it will be.

You don't even need to be a believer in the technology to be concerned. All that matters is that the people with all the money perceive some positive outcome for their wallets from all this investment and AI hype. That is where they'll put their money. Whether or not it ends bad or good. The economy has been reshaped around a hope. Either the hope is false and the economy tanks, or the hope is realized and jobs disappear. Lose-lose.

> YMMV but I think if you use the tool as a more expressive Google search it can be a great companion.

I get the most mileage out of this as well. It's the middle ground option. Everyone's either saying AI is useless, or saying how it's so good that writing code is an obsolete task already. Personally, I'm learning a ton with AI as a research tool, and implementing my code by hand with that knowledge. It also naturally solves the "you can't review 20,000 lines of code a day to even properly understand that it's correct" problem as a side effect too. But I am still building things much faster.

> I am glad that we are finally moving towards a world where we can utilize code as a tool rather than constantly trying to think how to make it into a product.

Maybe that's just you. Code as a tool rather than just a product has always existed.