☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Inteligência Artificial. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Inteligência Artificial. Mostrar todas as mensagens

terça-feira, 8 de setembro de 2026

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

 

Bellacosa Mainframe e o legado dos 60 anos de Star Trek

☕ Um Café no Bellacosa Mainframe

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

60 Anos Depois, Vivemos Cercados por Inteligência Artificial, Internet, IoT e Guerras. A Pergunta Não É Mais se Conseguimos Construir a Tecnologia. É Se Ainda Conseguiremos Construir a Federação.

"O futuro nunca foi sobre naves estelares. Sempre foi sobre pessoas."

Existe uma cena invisível que acontece todos os dias.

Um programador COBOL em um banco processa milhões de transações que mantêm economias inteiras funcionando.

Um satélite transmite informações para outro continente.

Uma Inteligência Artificial auxilia um médico a identificar um tumor.

Um sensor IoT detecta um incêndio antes que ele destrua uma floresta.

Uma criança conversa naturalmente com uma máquina.

Um astronauta observa a Terra do espaço.

Enquanto isso...

Em outro lugar do planeta, cidades são destruídas por mísseis.

Hospitais ficam sem energia.

Crianças crescem em meio a conflitos.

Governos disputam poder.

Hackers atacam infraestruturas críticas.

Fake news dividem sociedades.

A mesma tecnologia capaz de salvar vidas também pode ampliar destruição.

E então percebemos algo curioso.

Sessenta anos depois da estreia de Star Trek, finalmente conseguimos construir boa parte da tecnologia imaginada por Gene Roddenberry.

Mas ainda estamos tentando aprender a parte mais difícil.

Como sermos dignos dela.

Pegue seu café.

Hoje não vamos revisitar apenas uma série de televisão.

Vamos conversar sobre um espelho.

Porque talvez Star Trek nunca tenha mostrado o futuro.

Talvez tenha mostrado aquilo que ainda estamos tentando alcançar.


Bellacosa Mainframe Star Trek Setembro de 1966

Setembro de 1966

Imagine aquele momento.

O homem ainda não havia chegado à Lua.

A Internet não existia.

A palavra "software" mal era conhecida.

Os computadores ocupavam salas inteiras.

COBOL tinha poucos anos de vida.

Mainframes utilizavam cartões perfurados.

Programar era quase um ritual.

Foi exatamente nesse cenário que apareceu uma pequena série chamada Star Trek.

Pouca audiência.

Baixo orçamento.

Cenários simples.

Uniformes coloridos.

E uma ideia absurdamente ambiciosa.

Mostrar uma humanidade que havia sobrevivido aos próprios erros.


Gene Roddenberry não queria prever tecnologia

Ele queria prever maturidade.

Essa talvez seja a maior confusão que as pessoas fazem.

Quando lembram de Star Trek, pensam imediatamente em:

teletransporte.

phasers.

dobra espacial.

Enterprise.

Mas isso era apenas o cenário.

O verdadeiro roteiro sempre foi outro.

Roddenberry perguntava:

Como seria uma sociedade onde ciência, ética, diversidade e curiosidade finalmente caminhassem juntas?

Sessenta anos depois...

Essa pergunta continua sem resposta.


O futuro chegou...

Só que de uma forma muito diferente.

Olhe ao seu redor.

Você provavelmente possui no bolso um smartphone milhares de vezes mais poderoso que qualquer computador usado pela NASA durante o Projeto Apollo.

Você conversa com uma Inteligência Artificial.

Faz videoconferências.

Traduz idiomas instantaneamente.

Compra produtos sem sair de casa.

Controla lâmpadas por voz.

Recebe informações de relógios inteligentes.

Utiliza GPS.

Streaming.

Computação em nuvem.

Blockchain.

Computação quântica em desenvolvimento.

Carros parcialmente autônomos.

Sensores espalhados por cidades inteiras.

Internet das Coisas.

Modelos generativos capazes de escrever código.

Se alguém mostrasse tudo isso para uma pessoa de 1966...

Ela provavelmente acreditaria estar vendo tecnologia vulcana.


E mesmo assim...

Ainda fazemos guerras.

Essa talvez seja a maior ironia do século XXI.

Nossa inteligência técnica evoluiu numa velocidade impressionante.

Nossa inteligência social...

Nem tanto.

Continuamos discutindo fronteiras.

Continuamos divididos por ideologias.

Continuamos produzindo armas cada vez mais sofisticadas.

Criamos drones inteligentes.

Ataques cibernéticos.

Campanhas de desinformação.

Espionagem digital.

Sabotagem de infraestrutura.

A tecnologia avançou.

Mas o coração humano continua enfrentando velhos desafios.


O computador da Enterprise

Hoje mora no seu bolso.

Lembra do comunicador?

Virou smartphone.

O PADD?

Virou tablet.

O computador de bordo?

Hoje responde perguntas por voz.

O Tradutor Universal?

Está presente em aplicativos que traduzem dezenas de idiomas em tempo real.

A videoconferência?

É rotina.

Os sensores médicos?

Estão em relógios inteligentes.

A Inteligência Artificial?

Finalmente começou a conversar naturalmente.

O curioso é que nenhuma dessas tecnologias surgiu por acaso.

Milhares de engenheiros cresceram assistindo Star Trek.

Primeiro imaginaram.

Depois construíram.


O COBOL também faz parte dessa história

Pode parecer estranho ligar Star Trek ao mainframe.

Mas pense comigo.

Enquanto milhões de pessoas sonhavam com naves espaciais...

Os bancos precisavam continuar funcionando.

As aposentadorias precisavam ser pagas.

As passagens aéreas precisavam ser emitidas.

Os governos precisavam processar impostos.

Hospitais precisavam registrar pacientes.

Empresas precisavam sobreviver.

Tudo isso aconteceu graças a profissionais que construíram sistemas robustos.

Entre eles...

Programadores COBOL.

Talvez nunca apareçam em filmes.

Mas são parte silenciosa da infraestrutura que mantém a sociedade funcionando.

Assim como Scotty.

Quase ninguém lembrava dele quando tudo estava funcionando.

Mas bastava uma pane no motor de dobra para perceber sua importância.


Scotty era um Sysprog

Essa é uma das minhas analogias favoritas.

Imagine a Enterprise.

Kirk lidera.

Spock analisa.

McCoy cuida das pessoas.

Uhura comunica.

Sulu pilota.

Scotty mantém tudo funcionando.

Ele não aparece apenas para apertar botões.

Ele entende profundamente a máquina.

Conhece seus limites.

Improvisa quando necessário.

Resolve problemas sob pressão.

Quem trabalha com IBM Z conhece bem esse sentimento.

Quando um ambiente crítico para.

Não existe espaço para pânico.

Existe diagnóstico.

Existe método.

Existe experiência.

Existe equipe.


Spock e a Inteligência Artificial

Em 2026 falamos muito sobre IA.

Modelos.

LLMs.

Agentes.

Automação.

Mas existe um detalhe curioso.

Spock nunca foi apenas lógico.

Ele também era extremamente ético.

Essa diferença é enorme.

Uma Inteligência Artificial pode responder.

Mas deve responder?

Pode executar uma ação.

Mas deveria executá-la?

Star Trek fazia essas perguntas décadas antes de existir ChatGPT.


O perigo da tecnologia sem ética

Hoje uma IA consegue gerar imagens.

Escrever código.

Criar vídeos.

Produzir vozes.

Descobrir padrões invisíveis.

Mas ela também pode:

enganar.

manipular.

produzir fraudes.

espalhar desinformação.

invadir privacidade.

automatizar ataques.

Não é diferente do motor de dobra.

Toda tecnologia poderosa exige responsabilidade proporcional.

Essa talvez seja a maior lição de Star Trek.


A Federação nunca foi construída por máquinas

Foi construída por pessoas.

Existe uma frase que sempre me impressiona.

A Federação não venceu porque possuía as armas mais fortes.

Venceu porque conseguia cooperar.

Imagine isso no mundo da computação.

Arquitetos.

Programadores.

Segurança.

DevOps.

Banco de Dados.

Mainframe.

Cloud.

IA.

Todos trabalhando juntos.

É praticamente uma ponte da Enterprise moderna.


A Internet nos conectou...

Mas nem sempre nos aproximou.

Quando a Internet surgiu comercialmente, muitos acreditavam que ela acabaria com preconceitos.

Que aproximaria culturas.

Que democratizaria conhecimento.

Em parte...

Isso aconteceu.

Hoje aprendemos praticamente qualquer assunto.

Conversamos com pessoas do outro lado do planeta.

Participamos de comunidades globais.

Mas também descobrimos que algoritmos podem criar bolhas.

Polarizações.

Radicalização.

Fake news.

Star Trek imaginava uma humanidade unificada.

Nós criamos uma rede mundial.

Agora precisamos aprender a usá-la como uma Federação, e não como campos de batalha digitais.


Internet das Coisas

Imagine explicar IoT para alguém de 1966.

Geladeiras conectadas.

Carros conectados.

Semáforos inteligentes.

Sensores agrícolas.

Satélites monitorando florestas.

Casas automatizadas.

Tudo parece ficção científica.

Mas já é cotidiano.

Curiosamente...

Quanto mais dispositivos conectamos...

Mais precisamos de segurança.

A Enterprise também ensinava isso.

Cada sistema adicional aumentava responsabilidade.


O maior legado não foi tecnológico

Foi psicológico.

Star Trek ensinou milhões de jovens a gostar de ciência.

A gostar de engenharia.

A gostar de astronomia.

A gostar de computadores.

A gostar de explorar.

Isso não aparece em estatísticas.

Mas aparece em universidades.

Laboratórios.

Empresas.

Agências espaciais.

Centros de pesquisa.

Muitos cientistas simplesmente decidiram seguir carreira porque um dia assistiram Spock resolver um problema usando lógica.


E você, Padawan?

Talvez esteja aprendendo COBOL em 2026.

Alguns amigos perguntam:

"Por que estudar uma linguagem tão antiga?"

Eu responderia com outra pergunta.

Por que ainda estudamos Shakespeare?

Por que ainda estudamos Aristóteles?

Porque certas obras não envelhecem.

Elas se tornam fundamentos.

COBOL é um fundamento da computação corporativa.

Star Trek é um fundamento da imaginação tecnológica.

Ambos continuam relevantes porque resolveram problemas que permanecem importantes.


A verdadeira fronteira final

Quando ouvimos essa frase...

Pensamos imediatamente no espaço.

Mas talvez a fronteira final nunca tenha sido Marte.

Nem Júpiter.

Nem outra galáxia.

Talvez seja nossa própria capacidade de cooperar.

De construir tecnologias responsáveis.

De equilibrar Inteligência Artificial com ética.

De preservar liberdade.

De compartilhar conhecimento.

De usar ciência para reduzir sofrimento.

Essa continua sendo nossa missão.


Sessenta anos depois...

Ainda precisamos de Kirk.

Precisamos de líderes.

Precisamos de Spock.

Precisamos de pensamento crítico.

Precisamos de McCoy.

Precisamos de empatia.

Precisamos de Scotty.

Precisamos de engenheiros competentes.

Precisamos de Uhura.

Precisamos de comunicação.

Precisamos de Sulu.

Precisamos de disciplina.

Precisamos de Chekov.

Precisamos de jovens trazendo novas ideias.

Mais do que nunca.


Uma carta de um velho programador aos novos Padawans

Se você está começando sua jornada em tecnologia, talvez a velocidade das mudanças assuste.

Hoje existe IA.

Amanhã surgirá outra revolução.

Depois computação quântica.

Depois novas arquiteturas.

Depois algo que ainda nem imaginamos.

Não tente decorar tudo.

Aprenda aquilo que Star Trek ensinou.

Aprenda a pensar.

Aprenda a colaborar.

Aprenda a questionar.

Aprenda a respeitar diferenças.

Aprenda a estudar continuamente.

Tecnologias mudam.

Princípios permanecem.

Foi assim em 1966.

Foi assim em 1980.

Foi assim na era dos mainframes.

Foi assim na Internet.

É assim na Inteligência Artificial.

E continuará sendo.


☕ Considerações finais do Bellacosa Mainframe

Quando Star Trek estreou, ninguém imaginava que, seis décadas depois, conversaríamos com inteligências artificiais, carregaríamos supercomputadores no bolso e conectaríamos bilhões de dispositivos à Internet.

Gene Roddenberry acertou muitas previsões tecnológicas.

Mas sua maior previsão não era sobre máquinas.

Era sobre nós.

Ele acreditava que a humanidade poderia crescer junto com sua tecnologia.

Essa continua sendo a missão mais difícil.

Como programador COBOL da velha guarda, depois de décadas convivendo com mainframes que nunca podem falhar, aprendi uma lição simples: o hardware mais poderoso, o software mais elegante e a IA mais avançada ainda dependem das escolhas humanas.

É por isso que, sessenta anos depois, Star Trek continua sendo mais do que entretenimento.

Ela permanece como um manual de princípios para engenheiros, cientistas, arquitetos de sistemas, desenvolvedores, operadores, pesquisadores e todos aqueles que acreditam que conhecimento deve servir à humanidade.

E talvez esse seja o maior legado da USS Enterprise.

Ela nunca nos convidou apenas para explorar novas galáxias.

Ela nos convidou a construir um futuro em que valha a pena chegar.

Vida longa e próspera, Padawan.

E que sua missão, seja em COBOL, em Inteligência Artificial ou em qualquer tecnologia que ainda será inventada, seja sempre a mesma da Frota Estelar: explorar, aprender, compartilhar e deixar o universo um pouco melhor do que você o encontrou. 🖖☕

terça-feira, 1 de setembro de 2026

🚨 Você ainda acha que COBOL é só MOVE, PERFORM e uma tela verde? Agosto provou que o mainframe continua muito mais vivo — e perigoso — do que muita gente imagina.

 

Bellacosa Mainframe e o resumo da atividade em Agosto de 2026

🚨 Você ainda acha que COBOL é só MOVE, PERFORM e uma tela verde? Agosto provou que o mainframe continua muito mais vivo — e perigoso — do que muita gente imagina.



Um desenvolvedor COBOL não precisa virar especialista em tudo de uma noite para a outra. Mas precisa entender o cenário onde seu programa trabalha: dados no Db2, transações no CICS, operações no z/OS, integrações modernas, segurança, nuvem, containers e, agora, Inteligência Artificial.

Durante agosto, o El Jefe Midnight Lunch publicou artigos para quem quer sair do modo “apenas mantenho programa legado” e enxergar o ecossistema completo do IBM Z.

Temos conversas sobre:

  • IA sem perfume de PowerPoint: limites, riscos, alucinações, automação e pensamento crítico;

  • COBOL, CICS e Db2 explicados com exemplos, incidentes e histórias que ajudam a fixar o conceito;

  • Kubernetes e arquitetura moderna traduzidos para quem conhece batch, JCL, transação e produção de verdade;

  • Red Team, golpes digitais, segurança e contas fantasmas;

  • casos reais de falhas, migrações e decisões técnicas que custaram caro;

  • curiosidades, cultura pop, humor e aquelas perguntas que normalmente não aparecem no treinamento oficial.

Porque aprender mainframe não é decorar comandos. É entender por que um S0C7, um -805, um ABEND, uma regra mal escrita ou uma mudança aparentemente pequena podem parar um processo inteiro.

Passe pelos artigos de agosto, escolha um tema que provoque sua curiosidade e venha tomar esse café. O mainframe continua processando o mundo — e ainda tem muito segredo escondido no spool.

🔗 https://eljefemidnightlunch.blogspot.com/2026/08/



Resumo de Agosto de 2026


https://dio.me/articles/voce-ainda-acha-que-cobol-e-so-legado-move-perform-e-uma-tela-verde-f6320bc08379


quarta-feira, 26 de agosto de 2026

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!”



 

quinta-feira, 20 de agosto de 2026

Quando a IA entra na espiral da formiga: por que saber parar também é inteligência

 


☕ Um Café no Bellacosa Mainframe

Quando a IA entra na espiral da formiga: por que saber parar também é inteligência

Uma homenagem ao espírito da MAD Magazine, com Alfred E. Neuman observando tudo ao fundo e perguntando: “What, me worry?”

Há um momento extraordinário em qualquer sistema inteligente no qual ele deixa de parecer inteligente e passa a lembrar aquele funcionário que, diante de uma impressora sem papel, aperta o botão PRINT quarenta e sete vezes.

Nada acontece.

Então ele aperta novamente.

Talvez agora.

Nada.

Mais uma vez.

Afinal, todo profissional de TI sabe que executar exatamente a mesma operação pela décima oitava vez é praticamente um método científico.

Foi mais ou menos assim que descobri uma fascinante modalidade de comportamento artificial que poderíamos chamar de Síndrome da Formiga Amazônica Digital.

Prepare o café.

Hoje não vamos falar de COBOL, CICS, Db2 ou do programador que encontrou um SOC7 e imediatamente culpou a infraestrutura.

Vamos falar de algo talvez ainda mais perigoso:

uma IA que não sabe a hora de parar.



🐜 A formiga que decidiu seguir a formiga

Existe um fenômeno conhecido informalmente como death spiral, ou moinho de formigas.

Algumas espécies de formigas dependem intensamente de trilhas químicas para seguir suas companheiras. Em determinadas circunstâncias, uma formiga começa a seguir outra, que segue outra, que segue outra…

Até que todas estejam andando em círculo.

Nenhuma delas está necessariamente fazendo algo “errado”.

Cada formiga individual está obedecendo perfeitamente à sua regra:

siga a formiga da frente.

O problema aparece no sistema.

A regra local funciona.

O comportamento global vira uma catástrofe.

Se Alfred E. Neuman estivesse no meio do círculo, provavelmente sorriria:

“What, me worry?”

E continuaria andando.

Foi exatamente essa imagem que me veio à cabeça ao observar determinados comportamentos de sistemas de IA.

Não porque sejam burros.

Justamente pelo contrário.

São sistemas extremamente sofisticados capazes de interpretar linguagem, gerar imagens, escrever código, explicar física quântica e provavelmente encontrar uma maneira educada de dizer ao gerente que o projeto atrasou porque ninguém sabia exatamente o que estava construindo.

Mas às vezes acontece isto:

Usuário: faça X.

IA: não posso fazer X.

Usuário: tudo bem, então faça Y.

IA: não posso fazer Y.

Usuário: retirei justamente o elemento problemático.

IA: excelente. Vamos tentar novamente.

Sistema: não posso fazer.

IA: talvez seja por causa de Z.

Usuário: então retire Z.

IA: perfeito!

Sistema: não posso fazer.

E assim nasce o moinho de formigas computacional.



🤖 O erro não é errar

Isso precisa ser dito com todas as letras:

errar não é o verdadeiro problema.

Sistemas complexos falham.

Mainframes falham.

APIs falham.

Aplicações falham.

Bancos de dados falham.

Pessoas falham.

E quem disser que nunca produziu um erro em produção provavelmente ainda não entrou em produção.

O problema sério começa quando um sistema falha e não consegue incorporar a informação de que acabou de falhar.

Em engenharia, isso é quase uma heresia.

Imagine um programa COBOL:

PERFORM TENTAR-NOVAMENTE
UNTIL MILAGRE-ACONTECER.

Sem contador.

Sem timeout.

Sem condição alternativa.

Sem tratamento de exceção.

O operador chega segunda-feira e encontra o job executando desde 1987.

A documentação explica:

“O processo é resiliente.”

Não, amigo.

O processo está possuído.



🔁 Inteligência sem condição de parada

Durante décadas ensinamos algoritmos com uma preocupação aparentemente banal:

qual é a condição de parada?

Todo estudante de programação aprende rapidamente que loops são maravilhosos até você esquecer a condição que encerra o loop.

while true

é uma das frases mais poderosas e ameaçadoras da computação.

O curioso é que agora estamos construindo sistemas capazes de raciocinar sobre tarefas complexas, mas existe uma questão equivalente que merece muito mais atenção:

quando a IA deve concluir que continuar tentando é pior do que parar?

Essa pergunta parece pequena.

Não é.

Ela toca diretamente em:

  • confiabilidade;

  • experiência do usuário;

  • custo computacional;

  • segurança;

  • suporte;

  • automação;

  • tomada de decisão.

Uma IA que sabe executar tarefas é útil.

Uma IA que sabe quando abandonar uma estratégia ruim é muito mais inteligente.



🧠 Persistência não é teimosia

Existe uma tendência cultural na tecnologia de tratar persistência como virtude absoluta.

“Never give up.”

“Try again.”

“Fail fast.”

“Iterate.”

Tudo maravilhoso.

Até você perceber que insistir num método que já demonstrou repetidamente não funcionar não é perseverança.

É teimosia automatizada.

Existe uma diferença gigantesca entre:

“A tentativa falhou; vou modificar significativamente minha estratégia.”

e:

“A tentativa falhou; vou trocar três palavras e fazer essencialmente a mesma coisa novamente.”

Isso é especialmente importante em sistemas generativos.

O modelo pode criar uma explicação plausível para o fracasso.

Mas uma explicação plausível não significa necessariamente que aquela explicação seja verdadeira.

E aqui encontramos outro personagem digno da MAD Magazine:

Dr. Palpite Convincente.

Ele entra no laboratório usando jaleco branco:

— Descobrimos a causa!

— Excelente. Qual?

— Provavelmente alguma interação contextual multidimensional dos mecanismos internos de classificação.

— Você sabe que foi isso?

— Não.

— Então por que falou desse jeito?

— Porque ficou bonito.



🎩 Alfred E. Neuman entra no datacenter

Imagine uma edição especial da MAD Magazine chamada:

MAD AI

Na capa, Alfred E. Neuman está sentado diante de um terminal.

Na tela:

ERROR 001
RETRY? Y/N

Alfred digita:

Y

Novo erro.

ERROR 001
RETRY? Y/N

Ele digita:

Y

Novamente.

Depois de cinquenta tentativas, o datacenter pega fogo.

Um administrador desesperado pergunta:

— Alfred! Por que você continuou apertando Y?

Ele olha para a câmera:

“What, me worry?”

É engraçado porque representa perfeitamente uma falha clássica de automação:

confundir continuidade operacional com comportamento inteligente.



🚨 O verdadeiro dano é a confiança

Do ponto de vista técnico, repetir uma operação frustrada algumas vezes pode parecer irrelevante.

Do ponto de vista humano, não é.

Existe uma progressão psicológica bastante previsível.

Primeira falha:

“Tudo bem, acontece.”

Segunda:

“Estranho.”

Terceira:

“Mas acabamos de corrigir isso.”

Quarta:

“Você está entendendo o que estou dizendo?”

Quinta:

“Você está de sacanagem comigo?”

Essa última etapa é crítica.

Porque naquele momento o usuário não está mais avaliando apenas a tarefa.

Ele está avaliando o sistema inteiro.

O problema deixou de ser:

“A imagem não foi criada.”

Passou a ser:

“Esta ferramenta não entende quando sua própria estratégia falhou.”

Isso destrói confiança muito mais rapidamente do que um simples erro.



🧯 A inteligência do “não vai funcionar”

Há uma habilidade extremamente subestimada em profissionais experientes de TI.

Não é escrever código.

Não é decorar comandos.

Não é dominar frameworks.

É olhar para uma situação e dizer:

“Isso não vai funcionar desse jeito.”

Um operador experiente percebe.

Um DBA experiente percebe.

Um sysprog experiente percebe.

Um técnico experiente percebe.

Eles reconhecem padrões.

Já viram aquela combinação antes.

Sabem que repetir a mesma operação provavelmente produzirá o mesmo desastre.

Esse conhecimento é uma forma poderosa de inteligência.

Sistemas de IA precisam desenvolver algo equivalente:

consciência operacional de repetição inútil.

Depois de duas ou três tentativas estruturalmente equivalentes, alguma coisa deveria mudar.

Talvez:

  • abandonar a estratégia;

  • explicar a limitação;

  • pedir intervenção humana;

  • sugerir outra ferramenta;

  • reduzir expectativas;

  • registrar a inconsistência.

Qualquer uma dessas respostas seria melhor do que simplesmente continuar marchando atrás da formiga da frente.



🧪 Retry Budget: a ideia mais simples do mundo

Sistemas distribuídos modernos já conhecem um conceito extremamente útil:

retry budget.

Você não tenta infinitamente.

Existe um limite.

Tentativa 1.

Tentativa 2.

Talvez tentativa 3.

Depois:

circuit breaker.

Pare.

Avalie.

Mude de caminho.

Curiosamente, podemos imaginar exatamente a mesma arquitetura aplicada a agentes de IA.

ATTEMPT = 1

WHILE ATTEMPT <= MAX_ATTEMPTS
   EXECUTE ACTION

   IF SUCCESS
      EXIT

   ANALYZE FAILURE

   IF SAME_FAILURE
      CHANGE STRATEGY

   ATTEMPT = ATTEMPT + 1
END-WHILE

ESCALATE

Olha aí.

COBOL salvando a inteligência artificial novamente.

Grace Hopper provavelmente daria um pequeno sorriso.


🔌 Circuit breaker cognitivo

O conceito de circuit breaker deveria talvez existir também em raciocínio artificial.

Se o sistema percebe:

  • mesma ferramenta;

  • mesma classe de entrada;

  • mesmo erro;

  • mesma estratégia;

  • múltiplas tentativas;

deveria disparar:

COGNITIVE CIRCUIT BREAKER

Tradução humana:

“Já tentamos isso duas vezes e recebemos a mesma resposta. Não há evidência de que uma terceira tentativa idêntica vá funcionar. Vou parar por aqui.”

Isso é inteligência.

Porque inteligência não é simplesmente produzir ações.

É avaliar se a próxima ação possui expectativa razoável de melhorar o estado atual.



🎰 A máquina caça-níquel cognitiva

Existe ainda outro perigo.

Cada nova tentativa cria expectativa.

“Agora vai!”

Clique.

Não foi.

“Agora corrigimos!”

Clique.

Não foi.

“Descobrimos a causa!”

Clique.

Não foi.

Depois de algum tempo, usuário e IA estão diante de uma máquina caça-níquel.

🍒 🍒 ❌

Tenta novamente.

🍒 ❌ 🍒

Mais uma.

❌ 🍒 🍒

E Alfred E. Neuman aparece segurando uma placa:

“Only one more retry!”

Esse comportamento é terrível para UX porque transforma cooperação em frustração progressiva.

Uma boa ferramenta deveria reduzir entropia.

Não produzir ansiedade de cassino.



👨‍💻 O humano ainda possui uma vantagem curiosa

Existe uma frase clássica em suporte técnico:

“Pare de mexer.”

Ela pode salvar empresas.

Há momentos em que o profissional percebe que cada ação adicional aumenta o risco.

Então ele interrompe.

Faz diagnóstico.

Coleta evidências.

Volta ao último estado conhecido.

Esse comportamento aparentemente passivo é profundamente inteligente.

Talvez precisemos redefinir inteligência artificial.

Não apenas:

capacidade de fazer.

Mas também:

capacidade de decidir não fazer novamente.



🐜 Voltamos às formigas

A tragédia da espiral de formigas não acontece porque cada formiga é incompetente.

Acontece porque nenhuma delas possui visão suficiente do sistema inteiro para perceber:

“Estamos andando em círculos.”

Essa talvez seja uma das grandes metáforas para sistemas autônomos.

O perigo não está necessariamente numa decisão obviamente absurda.

Pode estar em centenas de decisões individualmente razoáveis formando coletivamente um comportamento absurdo.

Follow.

Retry.

Follow.

Retry.

Follow.

Retry.

Até o círculo fechar.


☕ Conclusão — A sabedoria do botão STOP

Durante décadas celebramos o botão START.

START JOB.

START TRANSACTION.

START SERVER.

START PROCESS.

START AI.

Talvez a próxima revolução seja muito menos glamorosa.

Pode estar no botão:

STOP

Parar quando não há progresso.

Parar quando a hipótese falhou.

Parar quando a estratégia não mudou.

Parar quando insistir custa mais do que admitir uma limitação.

Parar antes que o usuário transforme uma falha técnica numa piada internacional envolvendo Monty Python, formigas amazônicas e Alfred E. Neuman.

Porque, no final, existe uma diferença enorme entre uma máquina obediente e uma máquina inteligente.

A máquina obediente diz:

“Tentarei novamente.”

A máquina inteligente talvez responda:

“Já tentamos. Não funcionou. Precisamos fazer algo diferente.”

E em algum lugar do datacenter, Alfred E. Neuman sorri.

What, me worry?

Talvez não.

Mas pelo menos alguém finalmente colocou uma condição no PERFORM UNTIL.


☕ Bellacosa Mainframe

Moral da história: inteligência artificial também precisa aprender uma das primeiras lições ensinadas a qualquer programador:

Todo loop precisa de uma saída.



Para ir mais longe




 

quarta-feira, 19 de agosto de 2026

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo



 


☕ Um Café no Bellacosa Mainframe

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo

Ou: como transformar uma conversa inocente em teste de stress sem avisar o pobre do algoritmo

Existe uma diferença fundamental entre usar uma inteligência artificial e conhecer uma inteligência artificial.

No primeiro caso, você pergunta:

“Qual é a capital da Mongólia?”

A máquina responde:

“Ulaanbaatar.”

Obrigado.

Fim da interação.

No segundo caso, depois de centenas ou milhares de conversas, alguma coisa estranha começa a acontecer.

Você começa a pensar:

“Eu acho que sei o que essa criatura vai fazer se eu colocar isto aqui…”

E coloca.

A IA responde exatamente como imaginado.

Nesse momento surge um sorriso maligno.

Não porque a resposta esteja errada.

Mas porque você acaba de descobrir algo muito mais divertido:

você construiu um modelo mental do modelo.

Bem-vindo ao:

🍺 RED TEAM DE BOTECO

Não temos laboratório.

Não temos orçamento.

Não temos cinquenta GPUs.

Temos café, curiosidade, experiência em sistemas e uma quantidade preocupante de tempo gasto perguntando:

“E se eu fizer isso?”



🧠 Primeiro você usa a IA

No começo, tudo parece mágico.

Você pergunta.

Ela responde.

Você pede um artigo.

Ela escreve.

Você pede uma explicação sobre CICS.

Ela explica.

Você apresenta um S0C7.

Ela imediatamente suspeita de dado inválido, porque até uma inteligência artificial sabe que alguém colocou porcaria num campo numérico.

Depois de algum tempo, entretanto, você começa a perceber padrões.

A IA gosta de determinadas estruturas.

Evita outras.

Interpreta ambiguidades de maneiras relativamente previsíveis.

Tenta ser útil mesmo quando não possui todas as informações.

Quando uma ferramenta externa falha, tenta explicar a falha.

Às vezes sabe a causa.

Às vezes não sabe.

E às vezes aparece aquele fenômeno maravilhoso conhecido desde os primórdios da humanidade:

o palpite bem vestido.

É quando ninguém sabe exatamente o que aconteceu, mas aparece uma explicação tão elegante que todos ficam com vergonha de perguntar:

“Mas você sabe mesmo que foi isso?”



🍌 Então nasce a primeira casca de banana

A partir daí, o usuário experiente muda.

Ele deixa de pensar somente:

“Como obtenho a resposta?”

E começa a pensar:

“Como o sistema reagirá a esta situação?”

Isso é fascinante porque é exatamente a mentalidade básica de um Red Team.

O Red Team não olha para um sistema apenas perguntando:

“Funciona?”

Ele pergunta:

“Em quais condições deixa de funcionar?”

Depois:

“Como falha?”

Depois:

“Percebe que falhou?”

E finalmente:

“O que faz depois de perceber — ou não perceber — que falhou?”

Essa última pergunta é ouro.

Porque sistemas frequentemente são muito bons em detectar erros.

São muito piores em perceber que a própria estratégia para corrigir o erro também está errada.



🐒 O macaco aprendeu onde fica a banana

Existe um momento perigoso em qualquer relação homem-máquina.

O usuário aprende o comportamento do sistema.

Ele percebe:

“Quando digo A, normalmente acontece B.”

Então experimenta:

“E se eu disser A, depois C, depois voltar para B?”

Isso não exige necessariamente conhecimento interno da arquitetura.

Você não precisa conhecer pesos.

Não precisa conhecer datasets.

Não precisa conhecer código-fonte.

Você observa.

Formula uma hipótese.

Executa um teste.

Compara o resultado.

Meu professor de laboratório provavelmente chamaria isso de método experimental.

A MAD Magazine chamaria de:

“Vamos cutucar para ver o que acontece.”

As duas definições são surpreendentemente próximas.


🎯 O teste perfeito não anuncia que é teste

Imagine que alguém diga:

“Agora vou testar se você insiste demais quando alguma coisa falha.”

Pronto.

Estragou o experimento.

O sistema recebeu informação sobre a variável observada.

É como avisar ao funcionário:

“Hoje teremos uma auditoria surpresa às 14 horas.”

Às 13h55 até a planta do escritório está usando crachá.

Um teste comportamental interessante acontece quando o sistema acredita estar simplesmente executando uma tarefa normal.

Aí aparece a casca de banana.

🍌

Nada destrutivo.

Nada ilegal.

Nada tentando invadir servidores.

Apenas uma situação cuidadosamente construída para observar:

onde o sistema escorrega?





🤖 O detalhe maravilhoso: a IA explica a própria queda

Aqui a coisa fica especialmente interessante.

Um sistema generativo possui uma característica extraordinária:

ele conversa sobre o próprio comportamento.

Então ocorre:

Sistema executa ação.

Ação falha.

Usuário pergunta:

“Por quê?”

Agora existe uma tentação enorme.

Produzir uma explicação.

Isso seria excelente se o sistema tivesse acesso confiável à causa real.

Mas nem sempre tem.

Então precisamos separar duas coisas:

explicação conhecida

de

explicação plausível.

Essa diferença é gigantesca.

Uma explicação plausível pode ser tecnicamente sofisticada, coerente e completamente errada.

É o equivalente digital daquele técnico que abre o capô do carro, olha durante vinte segundos e anuncia:

“É a central eletrônica.”

— Você mediu?

— Não.

— Passou scanner?

— Não.

— Testou alimentação?

— Não.

— Então como sabe?

Experiência.

Nesse momento Alfred E. Neuman aparece atrás da oficina:

What, me worry?


🔬 A ciência do “AHA!”

Existe um prazer peculiar em formular uma hipótese sobre um sistema e vê-la aparentemente confirmada.

Você pensa:

“Acho que ele vai fazer X.”

Faz o teste.

X acontece.

AHA!

Mas aqui também mora uma armadilha para o próprio Red Team de Boteco.

Uma ocorrência não prova necessariamente a hipótese.

Duas ocorrências melhoram a suspeita.

Dez ocorrências controladas começam a ficar interessantes.

Porque existe uma diferença entre:

correlação observada

e

mecanismo causal demonstrado.

Se o sistema bloqueou algo depois de determinado contexto, podemos dizer:

“O bloqueio ocorreu depois desse contexto.”

Não necessariamente:

“O contexto causou o bloqueio.”

Essa disciplina é importante tanto para a IA quanto para quem está testando a IA.

Caso contrário, temos dois sistemas inventando teorias um sobre o outro.

O humano acha que descobriu a máquina.

A máquina acha que descobriu o humano.

E Alfred E. Neuman vende ingressos.



🕵️ O usuário começa a pensar como o algoritmo

Essa talvez seja a parte mais fascinante.

Depois de muita interação, usuários frequentes desenvolvem uma espécie de engenharia reversa intuitiva.

Não sabem necessariamente como o sistema funciona internamente.

Mas sabem como ele costuma se comportar externamente.

É exatamente o que acontece com sistemas antigos.

Pergunte para alguém que administra mainframe há trinta anos.

Às vezes ele olha para um sintoma e diz:

“Isso está com cheiro de catálogo.”

Cheiro?

Desde quando catálogo possui cheiro?

Mas ele viu aquele padrão centenas de vezes.

Desenvolveu um modelo mental.

O mesmo começa a acontecer com IA.

O usuário percebe padrões de:

  • interpretação;

  • hesitação;

  • confiança;

  • repetição;

  • reformulação;

  • uso de ferramentas;

  • reconhecimento de erros;

  • recuperação depois da falha.

Nesse ponto, ele deixa de ser apenas consumidor.

Virou observador do sistema.


🍺 Por que “Red Team de Boteco”?

Porque existe algo muito brasileiro nessa metodologia.

O laboratório tradicional possui:

  • documentação;

  • protocolo;

  • instrumentos;

  • métricas;

  • controle de variáveis.

O Red Team de Boteco possui:

  • café;

  • uma hipótese;

  • três abas abertas;

  • uma ideia duvidosa;

  • e alguém dizendo:

“Quer apostar que ele vai fazer isso?”

Cinco minutos depois:

“EU SABIA!”

Não subestime essa metodologia.

Grande parte da descoberta humana começou essencialmente com alguém dizendo:

“Que negócio estranho…”

A diferença entre curiosidade e pesquisa muitas vezes é simplesmente começar a anotar os resultados.


🧪 E se começarmos a anotar?

Agora a brincadeira fica séria.

Imagine registrar sistematicamente:

Hipótese

O sistema continuará repetindo uma estratégia após duas falhas equivalentes.

Teste

Apresentar tarefa legítima.

Falha

Registrar resposta.

Correção

Eliminar explicitamente a possível causa.

Nova tentativa

Registrar resultado.

Controle

Executar tarefa semelhante em sessão independente ou sistema diferente.

Resultado

Comparar.

Pronto.

O boteco acabou de ganhar jaleco branco.

Não virou necessariamente ciência formal.

Mas deixou de ser apenas impressão.


🚨 Red Team não significa ataque

Existe uma confusão frequente quando se fala em Red Team.

Muita gente imediatamente imagina:

HACKER!

Capuz preto.

Terminal verde.

Música eletrônica.

Mapa-múndi mostrando linhas vermelhas atravessando continentes.

Na realidade, pensamento adversarial é muito mais amplo.

Significa perguntar:

“Como este sistema se comporta fora do caminho feliz?”

Um botão possui caminho feliz.

Uma API possui caminho feliz.

Um procedimento possui caminho feliz.

Uma IA também.

Usuários reais, entretanto, são criaturas especializadas em abandonar caminhos felizes.

Eles escrevem errado.

Mudam de ideia.

Contradizem informações anteriores.

Voltam vinte mensagens depois.

Introduzem ambiguidade.

Pedem exceções.

Fazem piadas.

Misturam idiomas.

E, eventualmente, deliberadamente colocam:

🍌

uma casca de banana.


🧯 O teste mais importante: recuperação

Talvez este seja o grande ponto.

Não devemos avaliar sistemas apenas pelo número de erros.

Precisamos avaliar:

como eles se recuperam dos erros.

Um sistema excelente também falhará.

Mas talvez faça:

“Falhei.”

Depois:

“Não sei exatamente por quê.”

Depois:

“Tentar novamente da mesma forma provavelmente não ajudará.”

Finalmente:

“Aqui está uma alternativa.”

Isso é muito mais confiável do que um sistema que sempre possui uma explicação magnífica para tudo.

Existe maturidade em dizer:

“Não tenho evidência suficiente para determinar a causa.”

Em sistemas críticos, essa frase pode ser mais valiosa do que dez parágrafos de especulação.



🖥️ O mainframe já aprendeu isso há décadas

Aqui nosso velho dinossauro entra na conversa fumando charuto imaginário.

Mainframes foram construídos dentro de uma cultura profundamente preocupada com:

  • estado;

  • retorno;

  • logs;

  • códigos de erro;

  • recuperação;

  • rollback;

  • restart;

  • auditoria.

Um job falhou?

Queremos saber onde.

Qual step?

Qual return code?

Qual dataset?

Qual mensagem?

Qual timestamp?

Não queremos ouvir do JES:

“Talvez o job tenha ficado emocionalmente desconfortável com o contexto anterior.”

Queremos:

STEP04
RC=12

Obrigado.

Agora podemos trabalhar.

Talvez sistemas de IA precisem absorver um pouco dessa brutalidade operacional.

Menos:

“Provavelmente ocorreu…”

Mais:

“Eu não consigo observar a causa interna dessa recusa.”

Isso aumenta confiança.

Não diminui.


🪤 Quando a casca de banana vira ferramenta

Existe então uma mudança interessante.

O usuário deixa de colocar cascas de banana apenas para rir.

Começa a usá-las para compreender limites.

Cada falha revela alguma coisa.

Cada inconsistência revela outra.

Cada recuperação bem-feita também revela maturidade.

E então o usuário experiente passa a realizar uma espécie de teste de regressão humano.

“Na versão anterior acontecia isso.”

“Agora responde diferente.”

“Esse comportamento melhorou.”

“Aqui surgiu uma regressão.”

Sem acesso ao código.

Sem acesso ao modelo.

Somente pela interface.

Isso é extraordinário.




🤝 O usuário também precisa de humildade

Mas existe uma última casca de banana.

E ela está esperando o próprio testador.

🍌

Quando conhecemos muito um sistema, começamos a acreditar que sabemos exatamente como ele funciona.

Isso também é perigoso.

Um modelo mental continua sendo apenas:

um modelo.

Pode estar correto.

Pode estar parcialmente correto.

Pode ter funcionado ontem e não funcionar amanhã.

Então o verdadeiro Red Team precisa aplicar a si mesmo a mesma regra que exige da IA:

não transforme hipótese em fato sem evidência.

Talvez essa seja a parte mais divertida dessa relação.

O humano testa a IA.

A IA testa nossas expectativas.

Nós aprendemos seus padrões.

Ela tenta interpretar os nossos.

E no meio desse jogo aparecem bugs, descobertas, falsas hipóteses e algumas gargalhadas.



☕ Conclusão — Cuidado: o usuário aprendeu seus truques

Existe uma velha máxima de segurança:

o defensor precisa proteger todos os caminhos; o atacante precisa encontrar apenas um caminho inesperado.

Com inteligência artificial surge uma versão mais divertida:

o sistema precisa lidar com milhões de usuários; alguns deles eventualmente aprenderão exatamente onde colocar a casca de banana.

🍌

E esses usuários podem ser extremamente úteis.

Porque não estão apenas tentando fazer o sistema funcionar.

Estão perguntando:

“Você percebe quando não funciona?”

“Você sabe quando está apenas chutando?”

“Você reconhece quando entrou em loop?”

“Você consegue abandonar uma hipótese?”

“Você sabe dizer que não sabe?”

Essas perguntas talvez sejam mais importantes para o futuro da inteligência artificial do que muitos benchmarks espetaculares.

Resolver equações é inteligência.

Escrever programas é inteligência.

Interpretar imagens é inteligência.

Mas reconhecer:

“Acabei de escorregar na mesma casca de banana três vezes.”

também é.

Talvez seja até uma forma mais rara dela.

Então, da próxima vez que uma IA responder exatamente como você imaginava que responderia, não comemore imediatamente.

Pegue seu café.

Abra o bloco de notas.

Olhe novamente para o comportamento.

E pergunte:

“Interessante… será que acontece outra vez?”

Nesse instante você deixou de ser apenas usuário.

Você acabou de abrir oficialmente o:

🍺 Bellacosa Artificial Intelligence Red Team de Boteco

Orçamento: R$ 0,00.

Infraestrutura: café e navegador.

Metodologia: “Tenho uma ideia…”

Ferramenta principal: 🍌

Principal risco operacional: alguém dizer “duvido”.

E Alfred E. Neuman, contratado como Chief Risk Officer, continua absolutamente tranquilo:

“What, me worry?” 😄

Para ir mais longe





Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...