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

We found an undocumented bug in the Apollo 11 guidance computer code

juxt.pro

Post reply on HN
Print view View original

61–70 of 213 posts

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#61

Post by Aurornis »

throwaway27448 wrote: post #51
jwpapi wrote: post #24

Has someone verified this was an actual bug? One of AI’s strengths is definitely exploration, f.e. in finding bugs, but it still has a high false positive rate. Depending on context that matters or it wont. Also one has to be aware that there are a lot of bugs that AI won’t find but humans would I don’t have the expertise to verify this bug actually happened, but I’m curious.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

> It's not even clear if AI was used to find the bug

The intro says “We used Claude and Allium”. Allium looks like a tool they’ve built for Claude.

So the article is about how they used their AI tooling and workflow to find the bug.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#62

Post by deepsun »

ChicagoBoy11 wrote: post #58

For anyone who liked this, I highly suggest you take a look at the CuriousMarc youtube channel, where he chronicles lots of efforts to preserve and understand several parts of the Apollo AGC, with a team of really technically competent and passionate collaborators. One of the more interesting things they have been working on, is a potential re-interpretation of the infamous 1202 alarm. It is, as of current writing, p…

And that's why it's harder (or easier?) to make the same landing again -- we taking way less chances. Today we know of way more failure modes than back then.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#63

Post by brookst »

Gigachad wrote: post #57
rudhdb773b wrote: post #40

Earlier quoted context omitted.

Not to single out your comment, but it feels like it's gotten to the point where HN could use a rule against complaining about AI generated content. It seems like almost every discussion has at least someone complaining about "AI slop" in either the original post or the comments.

HN has gotten to the point where it’s not even worth clicking the link because of course it’s ai slop. There is some real content in the haystack, but we almost need some kind of curator to find and display it rather than a vote system where most people vote on the title alone.

If you’re looking for a place that surfaces only human-written content regardless of whether it’s interesting, rather than interesting content regardless of how it was written, HN is not the place.

There might be a market for your alternative though. Should be easy enough to build with Claude Code.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#64

Post by xmcqdpt2 »

embedding-shape wrote: post #35
xmcqdpt2 wrote: post #13

Earlier quoted context omitted.

Then pangram isn't very good, because that article is full of Claude-isms.

> because that article is full of Claude-isms Not sure how I feel about the whole "LLMs learned from human texts, so now the people who helped write human texts are suddenly accused of plagiarizing LLMs" thing yet, but seems backwards so far and like a low quality criticism.

I'm sure some human writers would write:

> The specification forces this question on every path through the IMU mode-switching code. A reviewer examining BADEND would see correct, complete cleanup for every resource BADEND was designed to handle.

> The specification approaches from the other direction: starting from LGYRO and asking whether any paths fail to clear it.

> *Tests verify the code as written; a behavioural specification asks what the code is for.*

However this is a blog post about using Claude for XYZ, from an AI company whose tagline is

"AI-assisted engineering that unlocks your organization's potential"

Do you really think they spent the time required to actually write a good article by hand? My guess is that they are unlocking their own organizations potential by having Claude writes the posts.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#66

Post by jll29 »

throwaway27448 wrote: post #51
jwpapi wrote: post #24

Has someone verified this was an actual bug? One of AI’s strengths is definitely exploration, f.e. in finding bugs, but it still has a high false positive rate. Depending on context that matters or it wont. Also one has to be aware that there are a lot of bugs that AI won’t find but humans would I don’t have the expertise to verify this bug actually happened, but I’m curious.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

> It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means.

Could the "AI native language" they used be Apache Drools? The "when" syntax reminded me of it...

https://kie.apache.org/docs/10.0.x/drools/drools/language-re...

(Apache Drools is an open source rule language and interpreter to declaratively formulate and execute rule-based specifications; it easily integrates with Java code.)

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#67

Post by Qwuke »

throwaway27448 wrote: post #51
jwpapi wrote: post #24

Has someone verified this was an actual bug? One of AI’s strengths is definitely exploration, f.e. in finding bugs, but it still has a high false positive rate. Depending on context that matters or it wont. Also one has to be aware that there are a lot of bugs that AI won’t find but humans would I don’t have the expertise to verify this bug actually happened, but I’m curious.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

>It's not even clear if AI was used to find the bug

It's not even clear you read the article

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#68

Post by caminante »

throwaway27448 wrote: post #51
jwpapi wrote: post #24

Has someone verified this was an actual bug? One of AI’s strengths is definitely exploration, f.e. in finding bugs, but it still has a high false positive rate. Depending on context that matters or it wont. Also one has to be aware that there are a lot of bugs that AI won’t find but humans would I don’t have the expertise to verify this bug actually happened, but I’m curious.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

How did you pick out AI native and miss the rest of the SAME sentence?

> We found this defect by distilling a behavioural specification of the IMU subsystem using Allium, an AI-native behavioural specification language.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#69

Post by bookofjoe »

mpalmer wrote: post #34
josephg wrote: post #2

Super interesting. I wish this article wasn’t written by an LLM though. It feels soulless and plastic.

I've seen way, way worse. Either someone LLM-polished something they already wrote, or they did their own manual editing pass. The short sentence construction is the most suspicious, but I actually don't see anything glaring. It normally jumps out and hits me in the face.

>Hemingway's 4 Fast Rules For Effective Writing

1. Use Short Sentences

https://www.wordsthatsing.com.au/post/hemingway-rules

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#70

Post by Aurornis »

rudhdb773b wrote: post #40
josephg wrote: post #2

Super interesting. I wish this article wasn’t written by an LLM though. It feels soulless and plastic.

Not to single out your comment, but it feels like it's gotten to the point where HN could use a rule against complaining about AI generated content. It seems like almost every discussion has at least someone complaining about "AI slop" in either the original post or the comments.

I disagree. I like to read articles and explore Show HN posts, but in the past 6 months I’ve wasted a lot of time following HN links that looked interesting but turned out to be AI slop. Several Show HN posts lately have taken me to repos that were AI generated plagiarisms of other projects, presented on HN as their own original ideas.

Seeing comments warning about the AI content of a link is helpful to let others know what they’re getting into when they click the link.

For this article the accusations are not about slop (which will waste your time) but about tell-tell signs of AI tone. The content is interesting but you know someone has been doing heavy AI polishing, which gives articles a laborious tone and has a tendency to produce a lot of words around a smaller amount of content (in other words, you’re reading an AI expansion of someone’s smaller prompt, which contained the original info you’re interested in)

Being able to share this information is important when discussing links. I find it much more helpful than the comments that appear criticizing color schemes, font choices, or that the page doesn’t work with JavaScript disabled.

Post reply on HN