Alan Turing, John McCarthy e o Delorean da Inteligência Artificial

 

Bellacosa Mainframe em uma homenagem a Alan Turing John McCarthy e os primordios da IA

☕ Um Café no Bellacosa Mainframe

Alan Turing, John McCarthy e o Delorean da Inteligência Artificial

Ou: o professor Brown trouxe uma Máquina de Turing de 1936, John McCarthy apareceu com Lisp de 1958, Igor tentou instalar um LLM num cartão perfurado — e o programador COBOL descobriu que a pergunta “máquinas podem pensar?” é bem mais antiga que o ChatGPT, o Wi-Fi e aquele colega que diz que IA vai substituir todo mundo na segunda-feira

DOC BROWN — ALERTA TEMPORAL!
“Vagner, se você colocar 1,21 gigawatts nesta fita perfurada, podemos voltar a 1936!”

IGOR: “Excelente, doutor! E depois a gente pede para a máquina preencher a SYSOUT!”

DOC BROWN: “Não, Igor. Primeiro precisamos definir o que a máquina sabe. Depois vemos se ela sabe que não sabe.”

PROGRAMADOR COBOL: “Professor, isso dá um S0C7?”

DOC BROWN: “Pior. Dá um problema filosófico.”

Há uma confusão muito comum quando se fala de Inteligência Artificial: parece que ela nasceu quando alguém abriu um chat, escreveu “faça um resumo deste PDF” e recebeu uma resposta tão convincente que resolveu perguntar se a máquina tinha alma, CPF ou direito a férias.

Não nasceu.

A conversa atual sobre IA — modelos de linguagem, agentes, automação, chatbots, geração de imagens, assistentes de código e previsões sobre AGI — tem raízes em perguntas feitas décadas antes de alguém sonhar com um smartphone. Duas figuras ajudam a entender o tamanho da estrada: Alan Turing e John McCarthy.

Turing ajudou a responder uma pergunta fundamental: o que uma máquina pode calcular? McCarthy pegou a próxima: como fazemos uma máquina exibir inteligência?

Não são a mesma pergunta. Mas, sem a primeira, a segunda talvez nem tivesse uma sala, uma placa na porta e um orçamento de pesquisa.

Para quem está começando em COBOL, isso importa mais do que parece. Afinal, COBOL, mainframe, IA, regras de negócio, automação e segurança pertencem ao mesmo universo: o universo em que seres humanos tentam transformar decisões, processos e conhecimento em algo que uma máquina consiga executar sem entrar em ABEND — ou, no mínimo, sem gerar um incidente que faça o gerente aparecer com a expressão de quem acabou de ver o Great Scott do professor Brown.

---

1. Antes de a IA existir, Turing desenhou a sala de máquinas

Em 1936, Alan Turing publicou um trabalho que se tornou uma das fundações da ciência da computação. Nele, apresentou a ideia que hoje chamamos de Máquina de Turing.

Não era um notebook. Não era um mainframe. Não tinha monitor, teclado, mouse, GPU, RGB, copiloto nem assistente perguntando se você deseja salvar alterações. Era uma máquina abstrata, matemática, quase ascética: uma fita potencialmente infinita, uma cabeça que lê e escreve símbolos e um conjunto de regras que determina o próximo passo.

Parece simples porque é simples. E justamente por isso é genial.

Imagine uma fita enorme com células. Cada célula pode conter um símbolo. A máquina lê uma célula, verifica seu estado atual e segue uma instrução do tipo:

“Se eu estiver no estado A e ler 0, escreva 1, mova uma posição à direita e vá para o estado B.”

Essa descrição não parece tão distante de um programa. Em COBOL, você escreve algo como:

IF SALDO-DISPONIVEL >= VALOR-SOLICITADO
    MOVE "APROVADO" TO STATUS-OPERACAO
ELSE
    MOVE "NEGADO" TO STATUS-OPERACAO
END-IF.

A diferença é que COBOL é uma linguagem de alto nível, feita para seres humanos descreverem regras de negócio. A Máquina de Turing é uma espécie de esqueleto teórico: uma forma de demonstrar o que significa executar uma sequência de instruções.

O ponto não é que seu programa de folha de pagamento seja literalmente uma Máquina de Turing com fita de papel. O ponto é que existe uma base conceitual por baixo de todo programa: dados, estados, instruções, memória e transições.

Turing mostrou que uma máquina suficientemente geral poderia simular qualquer outra máquina de cálculo, desde que recebesse a descrição correta do procedimento. Nascia a ideia de máquina universal.

E aqui o professor Brown derruba uma caixa de cartões no chão:

“Marty! Não precisamos construir uma máquina nova para cada problema. Precisamos construir uma máquina geral e trocar o programa!”

Esse raciocínio é a alma do computador moderno. O mesmo computador pode rodar um sistema bancário, calcular a folha, tratar uma imagem médica, executar um jogo, fazer uma planilha ou treinar um modelo de IA. O hardware é uma plataforma; o programa define o comportamento.

Para o programador COBOL iniciante, esta é a primeira lição: não pense em programação apenas como escrever comandos. Pense em descrever um processo de maneira precisa o suficiente para uma máquina executá-lo.

---

2. “Máquinas podem pensar?” — a pergunta que ainda não fechou o chamado

Em 1950, Turing publicou o artigo Computing Machinery and Intelligence. Em vez de tentar resolver logo a palavra “pensar” — uma palavra perigosamente grande, que arrasta consciência, linguagem, criatividade, emoção, filosofia, religião e um boteco inteiro de discussões — ele propôs uma alternativa prática.

Em vez de perguntar:

“Uma máquina pensa?”

Turing sugeriu perguntar algo próximo de:

“Uma máquina consegue conversar de tal modo que um avaliador humano não consiga distingui-la de uma pessoa?”

Essa ideia ficou conhecida como Teste de Turing.

Na versão simplificada, um humano conversa por texto com dois participantes escondidos: uma pessoa e uma máquina. Se não conseguir identificar de modo confiável quem é quem, a máquina demonstrou um tipo importante de comportamento inteligente.

Agora vem a parte que Igor costuma estragar quando lê apenas a manchete:

Passar ou não passar no Teste de Turing não resolve definitivamente a questão da inteligência.

Um sistema pode escrever de forma fluida, imitar emoções, reproduzir estilos e manter uma conversa impressionante. Isso prova que ele se comporta, naquele contexto, de maneira parecida com um humano? Talvez. Prova que ele entende o mundo do mesmo modo que você entende? Não necessariamente.

Um papagaio pode repetir uma frase sem entender economia. Um sistema pode produzir um parágrafo excelente sobre Db2 e, duas linhas depois, inventar uma opção de JCL que nunca existiu com a confiança de um gerente apresentando slide em reunião de diretoria.

Os modelos atuais são fantásticos em linguagem. Eles resumem, traduzem, escrevem código, classificam informações, explicam conceitos e ajudam a explorar ideias. Mas fluência não é garantia de verdade; texto bonito não é auditoria; resposta segura não é evidência.

Este é um ensinamento valioso para quem trabalha com sistemas corporativos:

• valide regras;

• valide fontes;

• mantenha trilha de auditoria;

• não deixe um modelo decidir sozinho algo sensível sem controles;

• trate a IA como um componente de software, não como um oráculo.

Em outras palavras: se uma IA disser que o lote terminou bem, ainda abra o SDSF.

---

3. Bletchley Park: inteligência não é só resolver charadas, é construir método

Durante a Segunda Guerra Mundial, Turing trabalhou em Bletchley Park, no esforço britânico de criptoanálise contra comunicações alemãs codificadas, incluindo mensagens protegidas pela Enigma. Ele não foi um “gênio solitário que venceu a guerra com uma máquina”, como alguns filmes e manchetes resumem. Fez parte de uma rede enorme de matemáticos, linguistas, operadores, engenheiros e criptanalistas.

Mas sua contribuição foi decisiva. O trabalho envolvia lógica, probabilidade, máquinas eletromecânicas, hipóteses, busca de padrões e disciplina operacional. Nada muito diferente, em espírito, do que hoje se chama de análise de dados, engenharia de sistemas e segurança cibernética.

Há uma ponte direta aqui para o analista de segurança e para o programador de sistemas críticos: inteligência útil não é adivinhação. É método para reduzir incerteza.

Quando você recebe um log, por exemplo, não basta olhar uma linha e concluir que houve ataque. Você precisa de contexto:

• qual usuário executou a ação?

• de onde veio a conexão?

• qual era o horário esperado?

• houve falhas de autenticação antes?

• o volume de operações fugiu do padrão?

• qual ativo foi acessado?

• existe impacto real?

A máquina pode ajudar a encontrar padrões. O humano precisa formular hipóteses, validar evidências e tomar decisões responsáveis.

Turing também nos lembra de algo trágico: genialidade técnica não protege ninguém da crueldade social. Ele foi perseguido pelo Estado britânico por ser homossexual e morreu em 1954, aos 41 anos. Quando celebramos sua obra, não devemos transformar sua vida em uma curiosidade decorativa de biografia. Devemos lembrar que ciência, tecnologia e instituições são feitas por pessoas — e podem falhar moralmente mesmo quando avançam tecnicamente.

Uma IA poderosa construída por uma organização sem ética não vira sábia. Vira apenas uma máquina mais eficiente para escalar decisões ruins.

---

4. John McCarthy: o homem que deu nome ao monstro

Se Turing ajudou a estabelecer os fundamentos da computação e colocou a pergunta na mesa, John McCarthy ajudou a dar nome ao campo que tentaria respondê-la.

Em 1955, ao escrever a proposta para o Dartmouth Summer Research Project on Artificial Intelligence — realizado no verão de 1956 — McCarthy usou a expressão Artificial Intelligence. O termo pegou, embora “inteligência de máquina” talvez fosse menos carregado de ficção científica.

A proposta era ousada: reunir pesquisadores para investigar a hipótese de que aspectos da aprendizagem e da inteligência poderiam ser descritos com precisão suficiente para serem simulados por uma máquina.

Repare na ambição. Não era “vamos fazer uma calculadora mais rápida”. Era:

“Vamos entender partes da inteligência de forma suficientemente clara para construí-las.”

Isso inclui aprendizado, linguagem, abstração, raciocínio, percepção, planejamento e senso comum. Sessenta e tantos anos depois, boa parte dessas palavras continua na pauta. Algumas avançaram absurdamente; outras continuam com aquele status clássico de projeto: “dependência externa aguardando definição”.

McCarthy apostava muito em IA simbólica: usar fatos, regras e relações explícitas para o computador raciocinar. Algo parecido com:

SE cliente possui limite
E valor solicitado é menor que limite
E não há bloqueio de fraude
ENTÃO aprovar operação.

Para um programador COBOL, isso soa familiar. Sistemas empresariais vivem de regras: alçadas, cálculos, validações, exceções, status, processos de aprovação e rastreabilidade.

A diferença é que a IA simbólica queria ir além de um conjunto fixo de IFs. Ela queria representar conhecimento sobre o mundo e tirar conclusões novas a partir dele.

O sonho era elegante. O mundo, porém, é cheio de exceções.

Você pode escrever uma regra simples:

Pássaros voam.

Mas pinguins não voam. Aves feridas podem não voar. Um pássaro dentro de uma gaiola pode saber voar e não estar voando. E se Igor colocar um frango congelado na mesa e perguntar se ele é um pássaro, o sistema precisa de mais café e menos certeza.

Esse tipo de problema — lidar com conhecimento incompleto, exceções e contexto — foi um dos grandes desafios da IA clássica. McCarthy trabalhou com raciocínio não monotônico, isto é, formas de raciocínio em que uma conclusão pode precisar ser revista quando surge uma informação nova.

Parece abstrato, mas você faz isso todo dia.

“A transação parece legítima.”
“Espere: o IP é novo, o valor é atípico e houve quinze tentativas de senha.”
“Atualize a conclusão.”

Em segurança, em auditoria e em operações, mudar de opinião diante de evidências novas não é fraqueza. É inteligência.

---

5. Lisp: a linguagem que ensinou a IA a mexer em ideias

Em 1958, McCarthy criou Lisp, abreviação de List Processing. A linguagem ganhou forma pública em seu famoso artigo de 1960 e se tornou uma das linguagens mais influentes da história da IA.

Lisp tratava listas e expressões simbólicas como elementos naturais do programa. Isso era muito poderoso para manipular estruturas de conhecimento, árvores, regras, fórmulas e linguagem.

Um exemplo muito simplificado de Lisp pode parecer assim:

(if (fraude-suspeita transacao)
    (bloquear transacao)
    (aprovar transacao))

Não é COBOL, claro. Mas a intenção deve lhe soar familiar: testar uma condição e tomar um caminho.

A diferença cultural é interessante. COBOL foi desenhado para tornar regras de negócio legíveis e duráveis. Lisp nasceu em um ambiente que queria representar símbolos, relações e transformações conceituais. Um é o funcionário experiente que conhece todas as contas do fechamento mensal; o outro é o professor maluco do laboratório que pergunta se uma expressão pode modificar outra expressão e se isso nos aproxima da mente.

Os dois têm lugar no mundo.

Aliás, Lisp não está morto. Ideias que ele popularizou — funções como valores, recursão, coleta automática de memória, manipulação de listas e metaprogramação — influenciaram muitas linguagens posteriores. A história da computação é cheia de “tecnologias antigas” que, na verdade, eram ideias adiantadas demais para o hardware e o mercado de sua época.

Mainframe também conhece essa piada. Quando alguém diz que COBOL é velho, o programador experiente responde:

“Velho é o sistema que ainda movimenta dinheiro, processa seguro, paga salário e não cai quando o hype troca de nome.”

---

6. A aposta de 2039: previsão, palpite ou bilhete para o Delorean?

Em uma entrevista de 1989, McCarthy falou sobre o tempo necessário para programas se tornarem tão inteligentes quanto seres humanos. Ele reconheceu que poderia levar duzentos ou quinhentos anos, dependendo dos avanços conceituais necessários. Mas disse que se inclinaria a apostar em algo como cinquenta anos — acrescentando, com humor seco, que era extremamente improvável que estivesse vivo para ver.

1989 + 50 nos leva aproximadamente a 2039.

McCarthy morreu em 2011. Ele acertou, de forma triste e literal, que não viveria para testemunhar a resposta. Mas é importante não transformar isso em profecia com data marcada no calendário.

2039 não é uma garantia de “AGI em produção”. Não haverá necessariamente um painel no Data Center dizendo:

AGI-2039 — STATUS: DISPONÍVEL
PRESS <ENTER> PARA ATIVAR CONSCIÊNCIA

A própria expressão “inteligência humana” é difícil de medir. Um sistema pode ser melhor que uma pessoa em xadrez, tradução, cálculo, reconhecimento de imagens e geração de código, mas falhar em tarefas banais que exigem contexto, bom senso, memória confiável ou compreensão física do mundo.

Foi isso que aconteceu no xadrez. Em 1968, o mestre internacional escocês David Levy apostou que nenhum computador o venceria em dez anos. Em 1978, o programa CHESS 4.7 perdeu por 2 a 1 — uma derrota humana, mas uma aproximação notável.

Décadas depois, computadores venceriam campeões mundiais. Isso não significou que eles haviam resolvido a inteligência geral. Significou que resolveram — brilhantemente — um domínio formal, com regras claras e objetivo definido.

A lição é ouro:

Ser excelente em uma tarefa não torna automaticamente um sistema inteligente em tudo.

Um modelo que escreve COBOL pode ajudar muito. Ainda assim, ele pode não conhecer as regras específicas do seu banco, não saber que um campo contém informação sensível, não entender uma convenção interna, não ter acesso ao contexto de produção e não perceber que aquela “melhoria” quebra um processo regulatório.

Por isso, IA corporativa madura precisa de humano no circuito, testes, limites de acesso, logs, aprovação e recuperação.

Igor, naturalmente, acha que basta dar UPDATE na tabela de pagamentos e perguntar para o robô “faz um PIX aí”. Não seja Igor.

---

7. LLMs, IA simbólica e o grande encontro no bar

A IA que domina a conversa atual é fortemente baseada em aprendizado de máquina: grandes modelos neurais treinados com enormes volumes de texto, código, imagens e outros dados. Eles aprendem padrões estatísticos e conseguem gerar respostas surpreendentemente úteis.

Esse caminho é diferente da visão mais simbólica de McCarthy. Em vez de alguém escrever explicitamente todas as regras, o modelo aprende regularidades a partir de exemplos.

Há vantagens enormes:

• adaptação a linguagem natural;

• capacidade de lidar com variedade de textos;

• geração de rascunhos e código;

• sumarização;

• classificação;

• tradução;

• apoio ao atendimento;

• descoberta de padrões.

Mas há riscos igualmente reais:

• alucinação: inventar fatos ou referências;

• vieses presentes nos dados;

• falta de explicabilidade;

• vazamento de informações;

• prompt injection;

• automação de decisões sem revisão;

• confiança excessiva do usuário.

A tendência mais interessante não é escolher uma religião — “só redes neurais” ou “só regras simbólicas”. É combinar abordagens.

Um sistema empresarial pode usar um LLM para entender a solicitação em português, uma base de conhecimento validada para buscar políticas corretas, regras explícitas para decisões obrigatórias e um humano para aprovar ações de alto impacto.

Pense assim:

Pessoa faz pergunta
        ↓
LLM entende a linguagem
        ↓
RAG busca documentos autorizados
        ↓
Regras de negócio validam condições
        ↓
Humano aprova decisão sensível
        ↓
Log registra tudo

Isso está muito mais perto de uma arquitetura responsável do que soltar um modelo numa rede corporativa e torcer para ele ter juízo.

Máquinas não têm juízo moral por padrão. Elas têm permissões, dados, instruções, limitações e consequências.

---

8. Um roteiro para o programador COBOL entrar na conversa da IA sem virar passageiro do tempo

Você não precisa abandonar COBOL, virar cientista de dados em uma semana ou comprar uma camiseta escrito “AGI IS COMING” para participar desse futuro.

Comece de modo prático.

Passo 1 — Entenda o processo antes de automatizá-lo

Escolha uma rotina de negócio conhecida: validação de cadastro, classificação de chamados, triagem de documentos, explicação de mensagens de erro ou consulta de procedimento.

Pergunte:

• qual é a entrada?

• qual é a saída?

• quais regras são obrigatórias?

• quais exceções existem?

• que dados são sensíveis?

• quem é responsável pela decisão?

• como registrar auditoria?

Se você não consegue explicar o processo, não está pronto para entregar o processo a uma IA.

Passo 2 — Separe linguagem de decisão

Um LLM pode ser ótimo para receber uma pergunta como:

“Por que meu pagamento foi bloqueado?”

Mas a decisão real de bloqueio deve continuar apoiada por regras, dados transacionais e controles.

A IA pode traduzir o tecnês. O motor de regras decide. O analista responde pelo caso. Essa separação evita que um texto bonito vire uma decisão perigosa.

Passo 3 — Use a IA como par de programação, não como piloto automático

Peça para ela:

• explicar um programa COBOL;

• sugerir casos de teste;

• comentar uma PROCEDURE DIVISION;

• gerar documentação inicial;

• converter uma regra de negócio em pseudocódigo;

• ajudar a encontrar campos usados em uma rotina;

• produzir uma primeira versão de teste unitário.

Mas revise tudo. Principalmente nomes de campos, arquivos VSAM, commits, SQL, regras de arredondamento, formatos de data e operações financeiras.

A IA pode ser um ótimo estagiário que trabalha rápido. Você continua sendo o responsável pela mudança em produção.

Passo 4 — Segurança não é rodapé

Nunca envie código proprietário, dados de clientes, credenciais, dumps, arquivos de produção ou detalhes operacionais para ferramentas públicas sem autorização.

Pergunte sempre:

• onde o dado será processado?

• ele será retido?

• quem pode acessá-lo?

• há contrato e política corporativa?

• o conteúdo pode virar treinamento?

• existe mascaramento?

• há trilhas de auditoria?

Turing trabalhou com segredo criptográfico. McCarthy pensava em representação de conhecimento. Em 2026, os dois provavelmente olhariam para um CSV de clientes colado num chatbot público e pediriam para desligar o Delorean.

---

Epílogo — A pergunta ainda está na fita

Alan Turing nos deu a linguagem conceitual para pensar máquinas que executam procedimentos gerais. Ele nos deixou uma pergunta que resiste a cada nova geração tecnológica: “máquinas podem pensar?”

John McCarthy pegou essa inquietação e deu a ela um nome, um campo de pesquisa, uma agenda e ferramentas para tentar respondê-la. Criou Lisp, ajudou a moldar a IA simbólica e, em 1989, arriscou um palpite que nos aponta para 2039 — não como destino garantido, mas como um marcador fascinante no mapa.

Hoje, temos sistemas capazes de conversar, programar, traduzir, enxergar, resumir e sugerir. Alguns parecem mágicos até o momento em que erram algo óbvio. Isso não diminui sua importância; apenas nos obriga a sair do hype e entrar na engenharia.

Talvez a pergunta não seja mais apenas “a máquina pensa?”.

Talvez seja:

“Ela entende? Ela pode agir? Ela pode errar? Quem confere? Quem responde pelo dano? E por que Igor recebeu acesso de administrador?”

O programador COBOL tem uma vantagem preciosa nesta era. Já conhece sistemas longos, críticos, regulados, cheios de exceções e onde um pequeno erro pode fazer uma conta muito grande deixar de fechar. Esse olhar vale ouro quando a IA sai do laboratório e entra no banco, no governo, na saúde, na segurança e no mainframe.

No fim, Turing construiu a estrada. McCarthy colocou a placa: Inteligência Artificial. E nós, passageiros do Delorean de 2026, estamos dirigindo rumo a 2039 com uma mão no volante, outra no manual de segurança e o professor Brown gritando do banco de trás:

“Para onde vamos, não precisamos de estradas… mas vamos precisar de logs, testes, backup e um plano de rollback!”