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

191–200 of 461 posts

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

#191

Post by tehjoker »

cantrevealname wrote: post #176
Gigachad wrote: post #155

Earlier quoted context omitted.

In real life it won’t be that the computer prevents you from turning it off. It’ll be that the computer is guarded by cultists who think its god, and unstoppable market forces that require it to keep running.

When AI ends up running everything essential to survival and society, it’ll be preposterous to even suggest pulling the plug just because it does something bad. Can you imagine the chaos of completely turning off GPS or Gmail today ? Now imagine pulling the plug on something in the near future that controls all electric power distribution, banking communications, and Internet routing.

This is the case with capitalism today. I don't like where he took the philosophy, but Nick Land did have an insight that all the worst things we believe about AI (e.g. paperclip optimizing etc) are capitalism in a nutshell.

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

#192

Post by yibg »

noir_lord wrote: post #75
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.

Agreed. Or debuggers that would take out the entire OS. Or a bad driver crashing everything multiple times a week. Or a misbehaving process not handing control back to the OS. I grew up in the era of 8 and 16 bit micros and early PCs, they where hilariously less stable than modern machines while doing far less, there wasn’t some halcyon age of near perfect software, it’s always been a case of things been good enough…

Or just http without the s. We take it for granted now, but not even that long ago http was the standard.

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

#193

Post by antod »

pcdevils wrote: post #8
xutopia wrote: post #4

The most likely danger with AI is concentrated power, not that sentient AI will develop a dislike for us and use us as "batteries" like in the Matrix.

For one thing, we'd make shit batteries.

Sounds about right, most of us already are. But why would the AI need our shit? Surely it wants electricity?

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

#194

Post by teeray »

freetime2 wrote: post #122

For a real world example of the challenges of harnessing LLMs, look at Apple. Over a year ago they had a big product launch focused on "Apple Intelligence" that was supposed to make heavy use of LLMs for agentic workflows. But all we've really gotten since then are a couple of minor tools for making emojis, summarizing notifications, and proof reading. And they even had to roll back the notification summaries for a w…

> minor tools for making emojis, summarizing notifications, and proof reading.

The notification / email summaries are so unbelievably useless too: it’s hardly more work to skim the notification / email that I do anyway.

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

#195

Post by worldsayshi »

mrkmarron wrote: post #180
AdieuToLogic wrote: post #162

I found this statement particularly relevant: While it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given. This possibility is compounded exponentially when MCP[0] is used. 0 - https://github.com/modelcontextprotocol

[flagged]

It sounds completely crazy that anyone would give an LLM access to a payment or order API without manual confirmation and "dumb" visualization. Does anyone actually do this?

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

#196

Post by stiglitz »

malfist wrote: post #85
noir_lord wrote: post #75

Earlier quoted context omitted.

Agreed. Or debuggers that would take out the entire OS. Or a bad driver crashing everything multiple times a week. Or a misbehaving process not handing control back to the OS. I grew up in the era of 8 and 16 bit micros and early PCs, they where hilariously less stable than modern machines while doing far less, there wasn’t some halcyon age of near perfect software, it’s always been a case of things been good enough…

Remember BSODs? Used to be a regular occurrence, now they're so infrequent they're gone from windows 11

As a Windows driver developer: LOL

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

#198

Post by cindyllm »

CuriouslyC wrote: post #186
noir_lord wrote: post #78

Earlier quoted context omitted.

IIRC the original idea was that the machines used our brain capacity as a distributed array but then they decided batteries was easier to understand while been sillier, just burn the carbon they are feeding us, it’s more efficient.

If I could write the matrix reverted, Neo would discover that the last people put themselves in the pods because the world was so fucked up, and the machines had been caretakers that were trying to protect them from themselves. That revision would make the first movie perfect.

[dead]

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

#200

Post by kube-system »

giancarlostoro wrote: post #175
kube-system wrote: post #67

Earlier quoted context omitted.

The author didn't mean that an older commit date on a file makes code better. The author is talking about the maturity of a project. Likewise, as AI technologies become more mature we will have more tools to use them in a safer and more reliable way.

I've seen too many old projects that are not by any means better no matter how much they get updates because management define priorities. I'm not alone in saying I've been in a few projects where the backlog is rather large. When your development is driven by marketing people trying to pump up sales, all the "non critical" bugs begin to stack up.

Absolutely. Which is why the author clearly meant "old code" as in mature. Not "old code" as in "created a long time ago".
Post reply on HN