+1 to this. And undue reliance on LLM's is the antithesis of being able to read and understand code, for the vast majority of LLM users. LLM's aren't designed to provide correct answers, they are designed to provide plausible answers. Wherein lies the trap.

Bottom line IMO is that the LLM will help the good / experienced developer get things done faster, for a certain subset of problems. LLM's will hold back the inexperienced / novice developer if not actually turn them into a liability.

Our group has been experimenting with LLM's (I refuse to call it AI because it's no such thing) on a reasonably large and extremely complicated code base. What we're finding is that while the LLM is often right, when it's wrong, it's plausibly wrong. That's problem #1: undue dependence on the LLM weakens the group's sense of "that's not the right answer", leading to bug churn.

Problem #2 is that a newer developer relying on the LLM's for code writing or debugging, misses out on the chance to develop that sense of how it all works. Left unchecked, you get a bunch of guys who don't actually know at a deep level how the system operates. That is not going to end well. (See #1, if nobody has that sense of "that's not right", well ...)

The third finding is that the quality of results depends very strongly on the quality of the LLM prompts. This goes back to the classic "Ask a Foolish Question" conclusion: to ask a proper question, one has to already know at least part of the answer. The only way to get there is to have at least some decent understanding of the code base, which one is not going to get by relying on the LLM's for all one's work. ("Ask a Foolish Question" is an excellent and classic Robert Sheckley short, if you haven't read it, kindly do so.)

Careful use of the LLM by experienced developers who already know the system, at least at a high level if not details of every area, and who can prompt the LLM in the right direction, seems to be an advance. We see more bug fixes; without LLM we might fix (say) 3 bugs in the time that using the LLM can fix 10, even if 3 of those "fixes" are wrong and have to be nak'ed or reverted. Reliance of less experienced developers on having LLM's fix bugs for them is the slippery slope to the nether regions.

As long as I can turn it off, I don't give a rat's ass what stupid, annoying, and bandwidth-eating "features" they put into Chrome.

I did. Did you? and anyone looking for "UPF" isn't likely to land on "Nova classification", not that the latter will tell them anything useful.

Well, exactly. I am not trying to defend crap food, but really, what are we talking about? Pancakes? Homemade grilled cheese (defining, for the moment, "american cheese" as cheese)? Breakfast cereals? Hot breakfast oatmeal? "TV" dinners? (of which there are a vast range, from obviously shite to plausibly good.)

One would hope that there's a gap between, say, bagged pork rinds vs no-frills baked pretzels. Just saying ":UPF bad, not-UPF good" is unavailing, especially if there's no consumer useful definition of a UPF.

I've seen any number of articles recently bewailing the evils of UPF's, but nothing that says exactly WHAT counts as an ultra-processed food. Wheaties? Fully-cooked sausages (e.g. GIlbert's)? Hot dogs? Pretzels? or just what exactly? There's no point in telling people that X is bad if you don't properly define what X is.

Altman and Amodie are either morons, crazy, or (most likely) doing the Big Lie thing. There's not the slightest bit of actual intelligence anywhere near today's LLM's, and I don't see it happening in my grandchildrens' lifetime.

They are Language Models, not intelligent "agents".

Back in the late 80's and 90's, I did a lot of porting among the various Unixes, mostly Solaris, AIX, HP-UX, DG, and a couple others. The HP-SUX port was always the most troublesome. The PA-RISC hardware was nice enough, but not HP-UX. It seemed like every time we turned around there was some new quirk or incompatibility. I'm glad it's gone.

Or you are working on a code base that isn't amenable to LLM assistance.

I don't know what sort of development you are doing that an LLM can create "massive" amounts of code that is anywhere near correct, but I wish you luck with it. I prefer to write my own race conditions and lock ordering bugs. I don't need something else to write them for me.

Just 41 years later than predicted.

Trust Mark Zuckerberg? That's a huge NO, and it goes rapidly downhill as one reads the rest of the title.

Ridiculous.

I'd go in a second. It won't happen, unfortunately.

rate -> rare

What a load of bullshit.

Fluoridation happened because statistics (you know, those actual records, not lies) showed that adding fluoride to water helped much more than it hurd.

Fluoride is not a common industrial waste product. Fluorine is relatively rate (compared to the other halogens). Water fluoridation is not cheap, compared to just flushing the dross down the drain or piling it up as slag. Pretending that it's a scam is a scam.

And Utah could become the first US state to subject kids to massive dental issues, while enriching dentists.

I predate fluoride in the water, and I'm sure my parents' bank account reflects it. Multiple teeth pulled thanks
to cavities regardless of how much I brushed or flossed.

If I were a dental student today, I'd move to Utah, because if this passes, it's going to be a fscking Gold Mine.