O código resiliente que levou o homem à Lua

Colaboração: Rubens Queiroz de Almeida

Data de Publicação: 21 de abril de 2026

Quando a missão Apollo foi concebida, havia um consenso silencioso dentro da engenharia: o hardware era o que realmente importava. Circuitos, módulos, redundância física, isso era considerado engenharia de verdade. O software, por outro lado, era visto quase como um acessório, algo que “vinha depois”.

Essa visão estava prestes a ser desmontada, não por teoria, mas por necessidade.

Este é o segundo artigo da série sobre o programa Apollo e o software que tornou possível levar o homem à Lua. E no centro dessa transformação está Margaret Hamilton, líder da equipe responsável pelo software de voo do Apollo Guidance Computer, desenvolvido no MIT Instrumentation Laboratory.

Para entender a importância do que ela fez, é preciso compreender o contexto técnico da época. O Apollo Guidance Computer operava com aproximadamente 4 KB de RAM e cerca de 36 KB de memória fixa. Não existiam sistemas operacionais como conhecemos hoje, não havia proteção de memória, não existiam linguagens de alto nível maduras para esse tipo de aplicação crítica. O software era escrito majoritariamente em Assembly, diretamente próximo ao hardware, e precisava lidar em tempo real com navegação, controle de atitude, integração de sensores e interação com os astronautas por meio da interface DSKY.

Isso significava uma coisa: qualquer erro poderia significar o fim da missão. Foi nesse cenário que Margaret Hamilton introduziu algo que hoje parece óbvio, mas que na época era radical: o software precisava ser tratado como um sistema crítico, sujeito a falhas imprevisíveis, e portanto deveria ser projetado para resistir a elas.

Um dos conceitos centrais que sua equipe desenvolveu foi o de asynchronous executive, uma forma primitiva de sistema operacional com escalonamento por prioridades. O computador precisava executar múltiplas tarefas simultaneamente: cálculo de trajetória, leitura de sensores, comandos do astronauta, e decidir, em frações de segundo, o que era mais importante.

Mas o ponto mais importante não era executar tudo. Era saber o que descartar. Essa decisão arquitetural foi crucial anos depois, durante o pouso da Apollo 11.

Minutos antes da alunissagem, o computador começou a emitir os famosos alarmes 1202 e 1201. O sistema estava sendo sobrecarregado por dados do radar de acoplamento, que estava ligado indevidamente e consumia ciclos de processamento.

Em um sistema convencional da época, isso poderia causar travamento total, mas não naquele software. Graças ao modelo de prioridades implementado pela equipe de Margaret, o sistema começou a descartar tarefas menos críticas automaticamente e preservar apenas aquilo que era essencial: controle do motor de descida e cálculos de navegação. O computador basicamente disse: “não consigo fazer tudo, então vou fazer apenas o que importa”. Essa decisão salvou a missão.

E aqui está o ponto que separa programação de engenharia. Margaret não escreveu código apenas para condições ideais. Ela escreveu código assumindo que o sistema iria falhar — sensores poderiam gerar dados inesperados, humanos poderiam cometer erros, condições não previstas poderiam surgir.

E isso nos leva a um episódio menos conhecido, mas igualmente revelador. Durante os testes, sua filha pequena teve acesso a um simulador e pressionou uma tecla que levou o sistema a um estado inconsistente. Margaret percebeu que aquilo poderia acontecer em uma missão real e propôs adicionar verificações e mecanismos de recuperação.

A resposta que recebeu foi direta: “um astronauta nunca faria isso”. Mas ela insistiu. E essa insistência define engenharia de verdade.

Hoje, quando falamos em tolerância a falhas, sistemas resilientes, validação de entrada, tratamento de exceções, estamos, muitas vezes sem perceber, ecoando decisões tomadas ali, nos anos 60.

O termo “engenharia de software”, que Margaret Hamilton ajudou a popularizar foi uma declaração de princípios. Era necessário elevar o desenvolvimento de software ao mesmo nível de rigor das demais engenharias, porque as consequências eram reais.

A diferença é que hoje temos mais memória, mais processamento, mais ferramentas. Mas isso não nos torna automaticamente melhores engenheiros. Em muitos casos, apenas mascara problemas que, em ambientes mais restritos, seriam imediatamente expostos.

Talvez seja por isso que essa história ainda importa tanto. Ela nos lembra que escrever código não é apenas fazer algo funcionar. É antecipar o inesperado. É projetar para o erro. É assumir que, em algum momento, o sistema será levado ao limite e precisa continuar operando mesmo assim.

No próximo artigo, vamos mergulhar em um dos aspectos mais fascinantes de todo o projeto Apollo: uma forma de memória em que o software não era armazenado, ele era literalmente tecido, fio por fio, em hardware físico.