To the Moon and Back: Blitzy's Adventure with Apollo 11
Apr 08, 2026 • Carly Levinsohn • 4 min read

At 3:10 CDT on July 20th, 1969, 3,000 feet above the moon's surface, and 45 seconds of fuel left, "Buzz" Aldrin and Neil Armstrong hear alarms shrieking in their ears.
The problem? NASA guidance officer Steve Bales and computer specialist Jack Garman with an alarm crib code sheet in hand, identified the issue immediately... Executive overflows (1201 and 1202 error codes) in the Apollo General Computer (AGC) were caused by a radar switch in the wrong position.
A critical example of error handling, the AGC rebooted and recovered, executing its own task management to safely transport the astronauts to the moon.
Margaret Hamilton, a computer scientist at the MIT Instrumentation Laboratory, led the team who developed all the onboard flight software and this critical edge case that saved the mission. Instead of a computer "crash", she programmed the computer to understand when it was overloaded and prioritize essential landing tasks.
By 3:17 PM CDT, Armstrong announced, "Houston, Tranquility Base. The Eagle has landed."
Why Apollo 11?
Apollo 11, the first moon landing in 1969, was a scientific and historical achievement.
In light of the current Artemis II mission, Blitzy tempted us to take a walk through history by revisiting the stories and programs from Apollo 11.
The source code illuminates important insights about computing as a whole. According to a book about Apollo 11 and the mission's technical fluency called Moonbit, the moon landing's source code can be viewed like a historical artifact reflecting the start of modern software engineering principles and architectural decisions. Although the code lives in NASA archives and was recently transcribed to GitHub, the lessons are at risk of being lost in time, given that being able to read the document is easier said than done.
Apollo 11 source code was written in its own unique language: AGC assembly with bytecode. In order for engineers to "read" the software history, developers have to learn the syntax and then interpret approximately 40,000 lines of code.
The theme in our previous Open Source Enhancement Initiative projects and Apollo 11 is a commitment to freeing high-impact applications from technical debt. Dismantling that burden requires understanding what is encoded first. Archaic codebases like Apollo 11 house institutional knowledge and lessons akin to a history book of an engineering team's applied software engineering principles. Rather than leveraging the platform to migrate code, how could Blitzy become an archaeologist for old software systems to excavate architectural, technical and analytical decisions that drove the Apollo 11 space mission?
Blitzy's Engineering Analysis
I prompted Blitzy to document and analyze every technical decision made in Apollo 11 source code without modifying the original programs. The scope of technical decisions included but was not limited to: architecture, error handling, naming conventions, and documentation. The appendix even contained an error code key with an exhaustive decision log for non-trivial engineering choices.
Blitzy generated a sophisticated and thorough understanding of Apollo 11. Below are a few of the highlights in the platform's engineering analysis.
Memory and resource constraints were the primary consideration in every decision. Blitzy correctly reasoned that Apollo 11 development was highly concerned with delivering functionality within limited space. The entire project encompasses navigation, guidance, autopilot, crew display, and the flight computer, all of which was executed in 36,864 words of fixed (core-rope) ROM and 2,048 words of erasable RAM.
Real-time scheduling and priority architecture was a key component of managing concurrent tasks on a 2 MHz single-core processor with no hardware memory protection. In addition to explaining how job scheduling worked in the moon landing, Blitzy successfully identified the exact lines of code that triggered the 1201 and 1202 error codes in Apollo 11, supplying 3 supporting flowcharts to explain the program's workflows.
Take a look at one of the three diagrams below:

Blitzy analyzed the AGC's "naming culture that served as mnemonic aid, severity indicator, and institutional knowledge — often simultaneously." Inline documentation and terms span: cultural and literary references for different routines, sardonic humor, Latin and literary allusions for maintainer warnings, and much more.
I want to call attention to a few of my favorites:
- MR.KLEAN — Describes the cleanup routine that terminates restart groups.
- NOLI SE TANGERE ("Do not touch") — A Latin phrase used as a maintainer warning to tell developers to not modify the ignition tables.
- BURN BABY BURN — The name of the Master Ignition Routine that handles APS/DPS engine ignition for a few programs. This famous name comes from a 1960s DJ Magnificent Montague.
- CURTAINS — Refers to the phrase "It's curtains for you". Signifies a fatal hardware error in the alarm routine.
If you are interested in viewing Blitzy's engineering analysis report, the document is available for your reading pleasure here.
Implications for the Enterprise
While leveraging Blitzy to read Apollo 11 source code like a book is enjoyable, the implications for what this project signifies is much more interesting. Blitzy has demonstrated through previous blogs in the Open Source Enhancement Initiative that infinite code context can unlock incredible compute power for building new functionality, driving migrations and accelerating development cycles.
Beyond massive software development capability, Blitzy can also function as a codebase historian, documenter, and analyzer to prevent the loss of intellectual property. The platform astutely observed how the naming conventions in Apollo 11 were unique and "institutional knowledge". Blitzy ingested AGC source code, decoded the minute programmatic approaches and decisions with great precision, and generated a clearly documented report explaining the archaic (and unique) conventions.
When software outlives engineers' tenure, how could Blitzy preserve the institutional knowledge inherent to your codebase and protect your company's greatest asset?
Want to stay up to date with the cutting edge of autonomous software development? Subscribe to our newsletter here.

