Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beliefs that are true for regular software but false when applied to AI

boydkane.com

Post reply on HN
Print view View original

91–100 of 461 posts

Re: Beliefs that are true for regular software but false when applied to AI

#91

Post by darth_avocado »

vladms wrote: post #77
darth_avocado wrote: post #10

Earlier quoted context omitted.

The reality is that the CEO/executive class already has developed a dislike for us and is trying to use us as “batteries” like in the Matrix.

Do you know personally some CEO-s? I know a couple and they generally seem less empathic than the general population, so I don't think that like/dislike even applies. On the other hand, trying to do something "new" is lots of headaches, so emotions are not always a plus. I could make a parallel to doctors: you don't want a doctor to start crying in a middle of an operation because he feels bad for you, but you can't…

I would say that the parallel is not at all accurate because the relationship between a doctor and a patient undergoing surgery is not the same as the one you and I have with CEOs. And a lot of good doctors have emotions and they use them to influence patient outcomes positively.

Re: Beliefs that are true for regular software but false when applied to AI

#92

Post by 5- »

meonkeys wrote: post #79
freediver wrote: post #22

Lovely blog, RSS please.

There's... something at https://boydkane.com/index.xml I guessed the URL based on the Quartz docs. It seems to work but only has a few items from https://boydkane.com/essays/

the author (either of the blog or its software) would do well to consult https://www.petefreitag.com/blog/rss-autodiscovery/

Re: Beliefs that are true for regular software but false when applied to AI

#93

Post by generic92034 »

wrs wrote: post #36

My current method for trying to break through this misconception is informing people that nobody knows how AI works. Literally. Nobody knows. (Note that knowing how to make something is not the same as knowing how it works. Take humans as an obvious example.)

Nobody knows (full scope and on every level) how human brains work. Still bosses rely on their employees' brains all the time.

Re: Beliefs that are true for regular software but false when applied to AI

#94

Post by binarymax »

kstrauser wrote: post #65
kazinator wrote: post #2

> AIs will get more reliable over time, like old software is more reliable than new software. :) Was that a humam Freudian slip, or artificial one? Yes, old software is often more reliable than new.

Holy survivorship bias, Batman. If you think modern software is unreliable, let me introduce you to our friend, Rational Rose.

You know, I had spent a good amount of years not having even a single thought about rational rose, and now that’s all over.

Re: Beliefs that are true for regular software but false when applied to AI

#95

Post by naasking »

coliveira wrote: post #38
drsupergud wrote: post #11

> bugs are usually caused by problems in the data used to train an AI This also is a misunderstanding. The LLM can be fine, the training and data can be fine, but because the LLMs we use are non-deterministic (at least in regard to their being intentional attempts at entropy to avoid always failing certain scenarios) current algorithms are inherently by-design not going to always answer every question correctly that…

This is not necessarily a problem. Any programming or mathematical question has several correct answers. The problem with LLMs is that they don't have a process to guarantee that a solution is correct. They will give a solution that seems correct under their heuristic reasoning, but they arrived at that result in a non-logical way. That's why LLMs generate so many bugs in software and in anything related to logical t…

> The problem with LLMs is that they don't have a process to guarantee that a solution is correct

Neither do we.

> They will give a solution that seems correct under their heuristic reasoning, but they arrived at that result in a non-logical way.

As do we, and so you can correctly reframe the issue as "there's a gap between the quality of AI heuristics and the quality of human heuristics". That the gap is still shrinking though.

Re: Beliefs that are true for regular software but false when applied to AI

#96

Post by naasking »

vladms wrote: post #84
coliveira wrote: post #38

Earlier quoted context omitted.

This is not necessarily a problem. Any programming or mathematical question has several correct answers. The problem with LLMs is that they don't have a process to guarantee that a solution is correct. They will give a solution that seems correct under their heuristic reasoning, but they arrived at that result in a non-logical way. That's why LLMs generate so many bugs in software and in anything related to logical t…

> Any programming or mathematical question has several correct answers. Huh? If I need to sort the list of integer number of 3,1,2 in ascending order the only correct answer is 1,2,3. And there are multiple programming and mathematical questions with only one correct answer. If you want to say "some programming and mathematical questions have several correct answers" that might hold.

I think more charitably, they meant either that 1. There is often more than one way to arrive at any given answer, or 2. Many questions are ambiguous and so may have many different answers.

Re: Beliefs that are true for regular software but false when applied to AI

#97

Post by cjbgkagh »

binarymax wrote: post #94
kstrauser wrote: post #65

Earlier quoted context omitted.

Holy survivorship bias, Batman. If you think modern software is unreliable, let me introduce you to our friend, Rational Rose.

You know, I had spent a good amount of years not having even a single thought about rational rose, and now that’s all over.

How much of that do you think would be attributable to IBM or Rational Software?

Re: Beliefs that are true for regular software but false when applied to AI

#98

Post by omnicognate »

meonkeys wrote: post #46
nlawalker wrote: post #28

Where did "can't you just turn it off?" in the title come from? It doesn't appear anywhere in the actual title or the article, and I don't think it really aligns with its main assertions.

It shows up at https://boydkane.com under the link "Why your boss isn't worried about advanced AI". Must be some kind of sub-heading, but not part of the actual article / blog post. Presumably it's a phrase you might hear from a boss who sees AI as similar to (and as benign/known/deterministic as) most other software, per TFA

It's a poor choice of phrase if the purpose is to illustrate a false equivalence. It applies to AI both as much (you can kill a process or stop a machine just the same regardless of whether it's running an LLM) and as little (you can't "turn off" Facebook any more than you can "turn off" ChatGPT) as it does to any other kind of software.

Re: Beliefs that are true for regular software but false when applied to AI

#100

Post by freetime2 »

LeifCarrotson wrote: post #53
giancarlostoro wrote: post #25

Earlier quoted context omitted.

Age of Code does not automatically equal quality of code, ever. Good code is maintained by good developers. A lot of bad code is pushed out by management, and other situations, or just bad devs. This is a can of worms you're talking your way into.

You're using different words - the top comment only mentioned the reliability of the software, which is only tangentially related to the quality, goodness, or badness of the code used to write it. Old software is typically more reliable, not because the developers were better or the software engineering targeted a higher reliability metric, but because it's been tested in the real world for years. Even more so if you…

Yup, I have worked on several legacy codebases, and a pretty common occurence is that a new team member will join and think they may have discovered a bug in the code. Sometimes they are even quite adamant that the code is complete garbage and could never have worked properly. Usually the conversation goes something like: "This code is heavily used in production, and hasn't been touched in 10 years. If it's broken, then why haven't we had any complaints from users?"

And more often than not the issue is a local configuration issue, bad test data, a misunderstanding of what the code is supposed to do, not being aware of some alternate execution path or other pre/post processing that is running, some known issue that we've decided not to fix for some reason, etc. (And of course sometimes we do actually discover a completely new bug, but it's rare).

To be clear, there are certainly code quality issues present that make modifications to the code costly and risky. But the code itself is quite reliable, as most bugs have been found and fixed over the years. And a lot of the messy bits in the code are actually important usability enhancements that get bolted on after the fact in response to real-world user feedback.

Post reply on HN