O que aprendi programando antes da Internet

Às vezes, quando vejo a facilidade com que hoje criamos uma aplicação, fico lembrando da minha primeira experiência com sistemas online. Era outra época. Pré-Internet, pré-Web, pré-cloud, pré-APIs, pré-microsserviços, pré-containers e, obviamente, muito antes da inteligência artificial generativa↳IA generativa81 conteúdosIA Generativa: 5 alternativas para começar a usar em 2025AI · jan 2025Gartner Revela o Futuro da IA GenerativaAI · jul 2024IA Generativa: Pesquisa global aponta Brasil como segundo país mais otimista com a tecnologiaAI · mar 2024Ver tudo em AI →. Meu primeiro contato mais sério com sistemas online foi com CICS em mainframe IBM, sob DOS/VS, desenvolvendo em COBOL. O CICS (Customer Information Control System) era e é o ambiente transacional da IBM para processamento de aplicações online de alta escala e alta disponibilidade, responsável por sustentar há décadas operações críticas de setores como bancos, seguros, varejo e governo em mainframes IBM.

E quem trabalhou naquele ambiente provavelmente vai entender o que estou dizendo: cada decisão de programação tinha um peso diferente. Não porque os programadores daquela época fossem melhores. É que o ambiente impunha restrições que hoje conseguimos esconder atrás de várias camadas de abstração.

Memória era um recurso precioso. Processamento era caro. Armazenamento e I/O precisavam ser tratados com cuidado. O acesso aos dados tinha impacto direto no desempenho. E a arquitetura da aplicação era fortemente condicionada pelas características do ambiente.

Havia também uma diferença fundamental: estávamos conectados, mas não à Internet. Os sistemas corporativos daquela época utilizavam arquiteturas próprias de comunicação. No universo IBM, SNA (Systems Network Architecture) definia a arquitetura de comunicação, enquanto VTAM (Virtual Telecommunications Access Method) fornecia os serviços de comunicação e gerenciamento de acesso no ambiente de mainframe. Terminais como o 3270 faziam parte desse ecossistema. Era uma infraestrutura sofisticada para sua época, mas muito diferente do mundo que surgiria depois com TCP/IP, HTTP, Web e APIs.

Programar para CICS exigia pensar de maneira diferente. Uma aplicação online não era simplesmente um programa executando continuamente e esperando o próximo comando do usuário. O CICS gerenciava transações e recursos compartilhados, e o desenho da aplicação precisava considerar cuidadosamente ciclo de vida das transações, estado da interação, concorrência, acesso a arquivos e bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, recuperação de falhas e integridade dos dados.

Em muitas aplicações, utilizava-se o modelo pseudo-conversacional: uma interação era processada e o programa não precisava permanecer ativo apenas esperando a próxima ação do usuário. O estado necessário para continuar a interação precisava ser preservado de alguma forma, conforme a arquitetura adotada. Isso obrigava o desenvolvedor a pensar não apenas no código, mas no comportamento do sistema.

E havia uma dificuldade que hoje considero particularmente interessante: depurar era muito mais difícil. Não tínhamos a experiência integrada que hoje associamos a IDEs modernas, debugging interativo, stack traces amigáveis, logs centralizados, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →, tracing e ambientes que podemos reproduzir em minutos.

Existiam ferramentas e técnicas de diagnóstico, evidentemente. Mas investigar um problema frequentemente significava juntar evidências de diferentes lugares e reconstruir o caminho percorrido pela transação.

Um problema em produção podia exigir entender o programa, a transação, os arquivos acessados, os códigos de retorno, a sequência de chamadas e o comportamento dos recursos compartilhados. Encontrar o erro muitas vezes era menos “colocar um breakpoint” e mais reconstruir o que havia acontecido.

E havia outra característica daquele mundo: desperdiçar recursos tinha consequências muito mais visíveis. Uma leitura desnecessária de arquivo, uma rotina ineficiente, um acesso excessivo a I/O ou uma utilização inadequada dos recursos podia afetar não apenas aquela execução, mas um ambiente compartilhado por muitas aplicações e usuários.

Por isso, desempenho não era necessariamente algo que seria “otimizado depois”. Fazia parte do projeto. As restrições técnicas e econômicas tornavam muito mais difícil esconder determinadas decisões ruins.

O ciclo de desenvolvimento também era diferente. Compilação, testes, acesso aos ambientes e implantação exigiam planejamento e dependiam de infraestrutura compartilhada.

Não tínhamos a conveniência atual de criar rapidamente um ambiente isolado, executar milhares de testes automaticamente e fazer deploy em segundos.

Isso ajudou a formar em muitos profissionais uma disciplina que considero extremamente valiosa: software não é apenas código. É arquitetura, dados, estado, concorrência, desempenho, recuperação de falhas e, principalmente, compreensão do ambiente onde aquele software vai existir.

E aqui está uma coisa interessante. Quando falamos de mainframe hoje, às vezes parece que estamos falando de tecnologia de um passado distante. Não estamos.

O CICS continua sendo utilizado em ambientes IBM Z modernos. E não se trata simplesmente de preservar tecnologia antiga. O CICS atual incorpora mecanismos de integração e convivência com tecnologias contemporâneas, enquanto continua atendendo aplicações transacionais críticas. Ou seja: aquele mundo não desapareceu. Ele evoluiu.

E é justamente por isso que fico um pouco desconfiado quando vejo o entusiasmo atual com ferramentas de IA capazes de produzir centenas ou milhares de linhas de código em poucos minutos. Não porque eu queira voltar ao mundo do CICS. Muito pelo contrário. Valeu experiência e aprendizado. Mas, eram outros tempos.

A evolução tecnológica foi extraordinária e eliminou inúmeras restrições desnecessárias. Mas as limitações daquele ambiente tinham um efeito colateral interessante: obrigavam o desenvolvedor a pensar antes de transformar uma ideia em código.

Hoje podemos gerar código quase instantaneamente.  Isso é fantástico. Mas será que estamos ficando melhores em construir software ou apenas melhores em produzir código? Naquela época, muitas das limitações vinham da máquina. Hoje, grande parte delas precisa vir da própria engenharia: arquitetura, testes, observabilidade, segurança, governança e conhecimento do domínio.

Estamos livres de muitas das restrições que nos obrigavam a pensar cuidadosamente sobre o código. O risco é confundir essa liberdade com engenharia.

Olhando para trás, percebo que a tecnologia mudou radicalmente. Mas os problemas fundamentais da engenharia de software, como complexidade, estado, dados, dependências, concorrência, falhas e manutenção, continuam essencialmente os mesmos.

Naquela época, a máquina nos obrigava a respeitar esses problemas. Hoje, precisamos ter a disciplina para respeitá-los por conta própria.