Blitzy logo
OverviewUse-casesSecurity
Company
DocsBlogVideos
Pricing
OverviewUse-casesSecurity
Company
DocsBlogVideos
Pricing

To the Moon and Back: Blitzy's Adventure with Apollo 11

Apr 08, 2026 • Carly Levinsohn • 4 min read

To the Moon and Back: Blitzy's Adventure with Apollo 11

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:

Apollo 11 Flowchart

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.

More from the blog

View all
How Blitzy Optimized Our GTM Team

How Blitzy Optimized Our GTM Team

Jun 04, 2026 • Carly Levinsohn • 3 min read

A Quick Blitzy Chat:  3 Codebases’ Takes on Prompting

A Quick Blitzy Chat: 3 Codebases’ Takes on Prompting

May 28, 2026 • Carly Levinsohn • 7 min read

Frequently asked questions

What is Blitzy?

toggle button

Blitzy enables development teams to transform six-month software projects into six-day turnarounds using Blitzy OS, an agentic platform that enables thousands of AI Agents to 'think' and cooperate for hours to bulk build software with precision. The platform builds everything AI can deliver in a precise manner, around 80% of any roadmap or new product, supplemented with a human engineering guide to complete the remaining 20% needed for production. With over 27 patents and counting, Blitzy is actively hiring PhDs and senior developers in Cambridge, MA who have a passion for building AI that leverages 'System 2 Thinking' to solve problems at inference.

Who is Blitzy for?

toggle button

Enterprises that aim to dramatically accelerate their software development velocity, development agencies with enterprise clients, development teams with complex existing products, and individuals looking to accelerate their own velocity on complex builds.

How does Blitzy's technology work?

toggle button

Our patent-pending code ingestion framework maps a curated selection of robust, reliable, and secure open source software libraries that we track by version and update frequently. Combined with our proprietary code generation technology that specializes on enforcing enterprise-class software policies, Blitzy far exceeds the utility of typical chatbots and co-pilots in creating production-ready software at scale.

Is Blitzy a coding co-pilot?

toggle button

Nope. Blitzy surpasses traditional co-pilots with its ability to autonomously generate nearly-complete code repositories, not just snippets. It features a daily-refreshed knowledge base, avoiding the pitfalls of outdated information. Blitzy's proprietary codebase representation system enables deep understanding of generated code, offering highly contextual and relevant suggestions for your entire repository.

What's my role in Blitzy's development process?

toggle button

Your team is responsible for bringing the requirements, and as an approver during the technical specification stage. We ask you to edit/approve the Technical Specification. The document is editable, so you can edit and approve to get exactly what you had in mind.

How does Blitzy decide which tasks to delegate to human developers?

toggle button

Blitzy's multi-agent system is meticulously and rigorously trained to know what it can accomplish, and what needs to be left for the human engineers. This ensures you only receive quality code and have a clear picture of remaining tasks.

Does Blitzy do more than just autonomous code generation?

toggle button

Yes. Blitzy is a comprehensive platform that provides end-to-end development assistance. We support the entire development lifecycle by taking descriptive inputs and generating software requirements documents, technical design, code structure, and generative code within repos for your product.

Is this high quality and secure?

toggle button

Quality and Security matter A LOT to us, and was one of our biggest frustrations with the co-pilots we tried on the market. This was the inspiration to develop a system trained to deliver enterprise quality. We train our agents to operate with enterprise standards with multiple QA agents checking each others work before you ever receive a line of code. Ultimately, we provide high quality code repositories, but your team should QA/QC, including testing security.

What is the typical cost of your solution?

toggle button

Blitzy uses a two-phase pricing model: evaluation followed by deployment. This structure enables enterprises to validate ROI at their preferred scale before committing to organization-wide implementation. The evaluation phase provides three options. Reverse Engineer ($0) offers an initial assessment with complete codebase reverse engineering and understanding up to 100K lines of code, Proof of Concept ($50K for 2-month term) where Blitzy delivers a guided POC to demonstrate value, or Structured Pilot ($250K for 6-month term) which fully deploys Blitzy in your environment with 5M lines onboarding and 1.25M lines generation to prove production readiness. Following successful evaluation, organizations choose between three deployment paths. Commercial ($500K typical investment per year) adopts Blitzy on one team to accelerate a defined initiative, with 20M lines onboarding included and $0.10 per line for additional onboarding, dedicated infrastructure, and SAML-SSO. Enterprise ($5M typical investment per year) rolls Blitzy out across your engineering organization with 50M lines onboarding at $0.10 per line, a Dedicated AI Solutions Consultant, and 2 Forward Deployed Engineers. Transformation ($50M typical investment per year) provides infinite code context, custom deployment, and embedded teams including a Field CTO, Dedicated AI Solutions Consultant, 6 Forward Deployed Engineers, and 2 Forward Deployed Designers for complete digital transformation. All tiers maintain SOC 2 Type II compliance, ISO 27001 Certification, and guarantee no training on your code. Pricing operates on a usage-based model at $0.20 per line generated, aligning costs directly with value delivered.

After submitting my prompt, Blitzy added functionality in my tech spec that I did not expect. What do I do?

toggle button

The system defaults to taking advantage of all technology upgrades when modernizing or upgrading to the latest technology stack. For example, if you specify an upgrade to Java 21, the system will by default implement virtual threads, as it's generally seen as a superior technical approach. If you do not want this, you must simply tell the system to 'make as few changes as possible to achieve the desired request'. Being as specific as possible about what functionality is (and is not) desired helps yield results that will align with expectations.

What do Blitzy agents rely on as a source of truth to represent my existing codebase?

toggle button

Blitzy agents rely on the actual source code of your existing codebase—not the Tech Spec documentation—when performing refactors or extending functionality. However, an accurate Tech Spec significantly aids the system's efficiency in querying the underlying representation of the code. Therefore, investing time to ensure the Tech Spec reflects the core features of the application will yield expectation-aligned results and will save time with last-mile development.

Can Blitzy work with existing products and code bases?

toggle button

Yes! Blitzy excels at working with existing codebases, using them as a foundation to ensure consistent, high-quality development. The platform enables you to add new features to existing products, generate comprehensive documentation, and tackle technical debt by upgrading legacy systems to state-of-the-art technologies or refactoring complex codebases. Our platform deploys dedicated AI agents that map and understand your codebase before generation, ensuring intelligent, contextualized development that aligns with your existing patterns and standards.

What programming languages does Blitzy support?

toggle button

Blitzy's AI platform works with all programming languages.

How should I structure my prompts for Blitzy?

toggle button

Structure and organization are crucial when prompting Blitzy. The most effective prompts follow our prompting template with clear sections for WHY (vision & purpose), WHAT (core requirements), and HOW (technical details, user experience & implementation priorities). Each section should be detailed but concise, focusing on essential information while providing relevant context. Including structured frameworks and concrete examples - like data models, user stories, or feature templates - helps Blitzy deliver more precise and purposeful solutions.

What information does Blitzy need to compile and run my code?

toggle button

During code generation, Blitzy compiles your codebase and performs runtime validation to ensure the generated code works correctly. To enable this, we require: (1) Internal dependencies - any private packages, libraries, or binaries not publicly available that your code needs to build and run, (2) Environment variables and secrets - API keys, credentials, and configuration values required for compilation and runtime (shared securely through our encrypted UI, never exposed to AI agents), and (3) Build instructions - the specific steps or scripts needed to compile your code, typically found in your README or setup documentation. This information allows Blitzy to replicate your development environment and verify that all generated code functions properly before delivery.

How can I exclude certain files or folders from Blitzy's code generation?

toggle button

Create a .blitzyignore file in your repository's root directory to specify which files or paths Blitzy should exclude during tech-spec generation and code generation. This works similarly to .gitignore - simply list the file patterns, directories, or specific files you want Blitzy to skip, using standard gitignore syntax like *.log, /build/, or config/secrets.json. To ensure Blitzy respects these exclusions, mention in both your codebase context prompt and target state prompt that Blitzy should reference the .blitzyignore file and exclude those paths from processing.

Can I cancel my project/job (code gen) once in progress?

toggle button

At this time, jobs are not cancelable. Once you submit, it consumes the assigned quota.

Build enterprise software in days, not months.

Start buildingTalk to an expert
Blitzy

Blitzy

One Kendall Square,

Cambridge,

MA 02139

© 2026 Blitzy. All rights reserved

Product

  • Overview
  • Use-cases
  • Security
  • Pricing

Company

  • About us
  • Careers

Support

  • Help
  • Service status
  • Trust center

Resources

  • Docs
  • Blog
  • Videos

Social

  • YouTube
  • LinkedIn

Legal

  • Terms of use
  • Privacy policy