The stack of code stood taller than she did. In that iconic 1969 photograph, Margaret Hamilton poses next to the printed listings of the Apollo flight software, over 400 people’s worth of work compressed into paper that reached her shoulders. She didn’t write it all by hand, despite what the internet’s favorite myth claims. But she led the team that built it, and more importantly, she built the principles that made it work.
Hamilton passed away on September 30 at age 90. Her death has reignited a conversation that’s more urgent than ever: how do you build software that doesn’t fail when failure means death? That question dominated her career. It’s the same question haunting every AI engineer shipping autonomous systems today, even if they don’t know her name.
Here’s the uncomfortable truth: we’ve spent sixty years advancing the tools of software engineering while quietly neglecting its foundations. And the AI era is making that neglect very, very expensive.
The 1202 Error That Proved Hamilton Right
The Apollo 11 landing almost didn’t happen. With three minutes until touchdown, the lunar module’s computer started screaming 1202 alarms. The guidance computer was overloaded, a hardware switch had failed, flooding the system with garbage data. For the untrained ear, those alarms sounded like the mission’s death knell.
But Hamilton and her team had engineered for exactly this scenario. Their priority-driven software architecture could detect the overload, shut down non-essential background tasks, and keep the critical landing functions running. Houston made the call: continue the landing. The rest is history.
Team member Don Eyles later described the system’s behavior: the software wasn’t just detecting a hardware fault, it was compensating for it, restarting tasks and prioritizing what mattered. The error detection and recovery mechanisms worked exactly as designed.
What’s remarkable isn’t that the software was bug-free. It’s that Hamilton assumed it wouldn’t be. She built for uncertainty. She built for the unexpected. She built for the failure modes nobody had imagined yet.
That’s the mindset that’s vanishing from modern software development.
“Defensive Programming” Was Radical. Now It’s an Afterthought.
The story that best captures Hamilton’s philosophy involves her four-year-old daughter, Lauren. While playing with a command module simulator at MIT, Lauren accidentally triggered a pre-launch program called P01 mid-flight, crashing the simulator entirely.
Hamilton identified the flaw and proposed a fix. Management overruled her: trained astronauts would never make that mistake. You can guess what happened during Apollo 8. Jim Lovell accidentally launched P01 during flight, wiping out the navigation data. Hamilton’s team had to scramble to recover the mission.
The lesson she extracted wasn’t “trust the astronauts.” It was “design for the possibility that humans will make mistakes, even when they shouldn’t.” She called this defensive programming, building software that anticipates and corrects errors on its own.
Today, that concept survives in narrow pockets: safety-critical systems in aviation, medical devices, autonomous vehicles. Meanwhile, the average tech company treats error handling as an afterthought, a JIRA ticket filed under “production hardening” that never quite makes it into the sprint.
The irony is that we now have systems that make Apollo’s complexity look like a calculator. Large language models generate code probabilistically, there’s no deterministic guarantee that any given output is correct. And yet, when was the last time you saw an AI system designed with the assumption that it will fail? That it will produce wrong answers? That it will need graceful recovery mechanisms?
As one analysis puts it, AI coding agents have a “structural vacuum” where correctness lives. They generate output that looks plausible but needs an external reference to validate it. Sound familiar? It’s the same problem Hamilton faced, except she had 400 engineers and a mission control team as the external reference, and today’s developers have a code review process that’s often just as broken as the code itself.
The Discipline She Had to Invent
Here’s what most people don’t realize: Hamilton didn’t just write reliable software. She had to invent the entire discipline of making software reliable. When she coined “software engineering” in the 1960s, her colleagues treated it as a joke. In her words, “it was considered to be quite amusing. It was an ongoing joke for a long time.”
Think about that. She was leading a team of hundreds building the most complex software system in human history, and the field was so unformed that she couldn’t even describe her job without being mocked. Software was a “black box”, a mystery. Management gave her team “total freedom and trust” because nobody knew enough to interfere.
That freedom produced something extraordinary: asynchronous software, priority scheduling, end-to-end testing, man-in-the-loop decision capability. As the technologist who later nominated her for NASA’s Exceptional Space Act Award put it, “Her concepts became the foundation for ultra-reliable software design.”
The term she fought to legitimize is now under assault from a different direction. The rapid rise of AI coding agents has some executives asking a familiar question: do we still need software engineers? The answer from recent research is a resounding yes, but for reasons that would make Hamilton smile.
Data from a study of 2,755 open-source repositories shows something counterintuitive: after AI tooling introduction, aggregate line-of-code output rose 17.7%, but experienced developers saw a 19% decline in original code output. They spent that time doing code review and rework instead. The tools generated more code, but the humans had to work harder to keep it from breaking things.
The DORA 2025 State of AI report tells an even starker story: teams with mature engineering foundations convert AI into throughput. Teams without them find AI “accelerating instability rather than productivity.”
That’s the structural vacuum made visible. AI doesn’t eliminate the need for software engineering rigor, it amplifies it. The discipline Hamilton created isn’t obsolete. It’s the only thing standing between us and systems that fail in ways we can’t predict, at scale we can’t manage.
What Apollo Teaches Us About AI Today
The Apollo Guidance Computer ran with roughly 64KB of memory. NASA trusted it with human lives. The stakes for AI systems are arguably higher: they’re embedded in healthcare decisions, financial infrastructure, energy grids, and increasingly autonomous vehicles. We’re handing them decisions that affect millions of lives, often without the rigor Hamilton insisted upon.
Three principles from her work map directly onto AI development:
- Design for failure, not just for success. Hamilton’s team assumed software would encounter unexpected states. Modern AI systems need the same assumption baked in from day one, not bolted on after a production incident.
- Prioritize ruthlessly. The Apollo software could shut down lower-priority tasks under load. AI systems operating in real-time environments need the same capability. What gets sacrificed when the model is uncertain? What’s truly critical?
- Build the reference into the system. Hamilton’s protocols connected the onboard computer to mission control, humans who could make judgment calls the software couldn’t. Today’s AI systems need analogous guardrails: human oversight, specification artifacts, and evaluation frameworks that provide the correctness reference AI itself lacks.
There’s a deeper lesson too, one that gets lost in the technical weeds. Hamilton’s daughter triggered the P01 error because she was playing with the simulator. A four-year-old found a flaw that trained astronauts supposedly couldn’t. Hamilton didn’t dismiss the edge case, she designed for it.
Modern software development often treats edge cases the same way Hamilton’s managers did: with confident dismissal. “That won’t happen in production.” “Users won’t do that.” “The model was trained on that scenario.” The apocalyptic stack traces in every developer’s inbox say otherwise. The failure mode isn’t a lack of intelligence, it’s a lack of humility about what software can encounter in the wild.
The “Almost Right, But Not Quite” Problem
Bertrand Meyer, writing in Communications of the ACM, described what he calls the “hallucination loop”: an AI tool produces a plausible suggestion that sends a developer down a path that doesn’t close. The AI productivity paradox isn’t a paradox at all, it’s the gap between generating code and verifying code widening in real time.
The numbers back this up. The Stack Overflow 2025 Developer Survey, spanning nearly 49,000 developers across 177 countries, found that 84% adopt AI tools, yet 46% distrust the accuracy of AI output, up from 31% the previous year. And 66% cite “almost right, but not quite” as their top frustration with AI solutions.
That’s the human cost of the structural vacuum. The output looks correct. It compiles. It passes the basic tests. But “looks correct” isn’t the same as “is correct”, and in the absence of rigorous verification processes, that gap becomes production incidents, system outages, and slowly accumulating technical debt.
The challenge of new AI tools becoming the next legacy system isn’t hypothetical, it’s happening right now in every organization that adopted coding assistants without updating their engineering practices to match. You can’t bolt AI onto a broken process and expect reliability to emerge from the chaos.
Hamilton’s Real Legacy: The Discipline Itself
When Hamilton received the Presidential Medal of Freedom in 2016, Barack Obama’s citation captured the essence: “She defined new forms of software engineering and helped launch an industry that would forever change human history.”
But her most important contribution wasn’t the code, it was the practice of engineering reliable software. She spent the rest of her career building on that foundation, founding companies to develop error prevention and fault tolerance methodologies. Her later work on the Universal Systems Language (USL) was an attempt to systematize everything she’d learned: a modeling language designed around the principle that you prevent errors by catching them at the specification stage, not after deployment.
In 2015, the Apollo 11 source code was uploaded to GitHub. It’s worth browsing. There’s a famous line in it: “BURN, BABY, BURN” when the descent engine ignites. But there’s also, in the earliest versions, an annotation complaining about a delay: “Wait… too late… POO POO.” The software that landed humans on the Moon had jokes in it. It was built by people who knew they were pioneering something new and found joy in it.
That humanity, the willingness to treat software as a craft that could always be improved, always be made more reliable, always learning from failure, is the legacy that matters most for the AI era.
The Verdict: Hamilton’s Principles Are Non-Negotiable
Six decades after Hamilton helped create software engineering, the discipline faces its biggest test. AI isn’t making her principles obsolete, it’s making them essential. The research on software engineering in the age of coding agents concludes: “A generation of developers trained only in prompting, without methodological knowledge, domain elicitation skill, or architectural judgment, will reproduce at scale the failure modes this paper describes.”
That’s the warning. We can choose to listen, or we can rediscover the hard way that reliability is something you engineer in from the start, not something you pray for after deployment.
Hamilton’s approach was built on a belief that seems almost naive today: that software could be trusted with the most important moments in human history. She proved it once. The question for our generation is whether we can prove it again, with systems far more complex, far less predictable, and just as consequential.
She never walked on the moon. But she built the software that got humanity there, and in doing so, built the foundation for everything that came after, including the AI systems we’re building today. The least we can do is honor that legacy by remembering why it matters.
After all, as she said herself: “Looking back, we were the luckiest people in the world, there was no choice but to be pioneers, no time to be beginners.” Our AI era has the same urgency. We just don’t have her to guide us through it anymore.