☕ 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 Tecnologia. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Tecnologia. 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. 🖖☕

domingo, 6 de setembro de 2026

A Guilda dos Aventureiros Mainframe — Por Que Quase Não Existem Programadores Velhos no CPD?

Bellacosa Mainframe e os velhos aventureiros do CPD

Um Café no Bellacosa Mainframe

A Guilda dos Aventureiros Mainframe — Por Que Quase Não Existem Programadores Velhos no CPD?

Ou: como COBOL, Db2, CICS, cursos, certificações, horas extras, releases, burnout, boletos e um Ceifeiro Silencioso transformaram a carreira de TI numa dungeon em que sobreviver é apenas o começo

Existe uma coisa estranha nos animes de fantasia.

Entre numa Guilda dos Aventureiros.

Olhe ao redor.

Há guerreiros de vinte anos, arqueiras de dezoito, magos adolescentes, sacerdotisas jovens, aventureiros iniciantes carregando espadas maiores do que eles e meia dúzia de veteranos aparentemente na casa dos trinta.

Agora procure alguém com cinquenta anos.

Boa sorte.

Sessenta?

Talvez exista um velho Rank S sentado misteriosamente no fundo da taverna.

Mulheres com mais de cinquenta anos?

Em algumas aldeias parece que a população feminina passa diretamente dos 29 para os 78.

Isso sempre me deixou pensativo.

A princípio parece apenas uma convenção visual dos animes. Afinal, protagonistas jovens vendem mangá, figures e Blu-rays.

Mas existe outra possibilidade muito mais divertida — e assustadora.

Talvez aventureiros idosos sejam raros porque aventurar-se é uma profissão terrivelmente insalubre.

Você começa aos dezesseis anos.

Enfrenta goblins.

Depois orcs.

Depois trolls.

Depois dungeons.

Depois dragões.

No meio disso existem venenos, quedas, armadilhas, frio, fome, espadas, magia, infecções e monstros que aparentemente desenvolveram uma preferência gastronômica por aventureiros iniciantes.

Um único erro pode terminar a carreira.

Ou a vida.

Então comecei a imaginar a pirâmide profissional daquela Guilda.

Cem aventureiros entram.

Sessenta abandonam.

Vinte ficam incapacitados.

Quinze morrem.

Quatro encontram profissões mais sensatas.

Um chega aos cinquenta anos ainda carregando uma espada.

É justamente aquele sujeito grisalho sentado no canto da taverna que todos respeitam.

E então percebi algo.

Eu já conhecia essa Guilda.

Trabalhei nela durante décadas.

Só que não havia goblins.

Havia computadores.

Bem-vindo à Guilda dos Aventureiros Mainframe.



1. O jovem aventureiro recebe sua primeira espada

Todo programador começa aproximadamente da mesma maneira.

Você chega à empresa.

Recebe um crachá.

Um computador.

Algumas senhas.

E alguém lhe mostra o sistema.

Se for mainframe, aparecem diante dos seus olhos coisas como:

COBOL.

JCL.

TSO.

ISPF.

CICS.

Db2.

VSAM.

JES2.

SDSF.

Talvez IMS.

Talvez MQ.

Talvez RACF.

Você olha aquilo tudo como um aventureiro entrando pela primeira vez numa cidade gigantesca.

Os veteranos parecem magos.

Um programa apresenta S0C7.

Você ainda está tentando entender o que significa aquela sopa de letras quando um sujeito grisalho olha o dump e diz:

— Veja o offset.

Cinco minutos depois encontrou o problema.

Você pensa:

“Quero aprender a fazer isso.”

Parabéns.

Você acabou de aceitar sua primeira quest.


2. A primeira dungeon chama-se Produção

Nos primeiros anos tudo é novidade.

Cada incidente ensina alguma coisa.

Você descobre que aquilo que funcionava perfeitamente no ambiente de desenvolvimento pode desenvolver personalidade própria quando chega à produção.

Aprende sobre dados reais.

Volume real.

Concorrência.

Locks.

Timeouts.

Permissões.

Janelas de processamento.

Dependências.

Jobs.

Arquivos.

Filas.

Programas que chamam programas que chamam programas escritos por alguém que se aposentou quando você ainda usava Windows 95.

E então chega aquele momento iniciático da carreira:

o telefone toca de madrugada.

03:17.

Produção parou.

Nesse momento você deixa de ser apenas programador.

Você virou aventureiro.

A dungeon está aberta.



3. O problema é que monstros não respeitam horário comercial

O aventureiro dos animes trabalha em condições terríveis.

Caminha durante dias.

Dorme em florestas.

Carrega equipamento.

Enfrenta monstros.

Come quando consegue.

O consultor de tecnologia possui sua própria versão disso.

Horas extras.

Viradas de produção.

Fim de semana.

Feriado.

Implantação noturna.

Conference call internacional.

Incidente.

War room.

Mudança emergencial.

Telefone durante jantar.

Notebook durante férias.

Depois de alguns anos aparecem as marcas da batalha.

Tendinite.

Dor nas costas.

Problemas de sono.

Estresse.

Exaustão.

Ansiedade antes de determinadas implantações.

E, em situações mais graves, burnout.

Não existe espada atravessando sua armadura.

Mas o corpo mantém um log próprio.

E esse log também acumula eventos.



4. Onde estão os aventureiros de cinquenta anos?

Aqui surge a pergunta que iniciou toda esta reflexão.

Você entra em determinadas empresas e encontra equipes extraordinariamente jovens.

Isso pode parecer maravilhoso.

“Que empresa moderna!”

“Que equipe dinâmica!”

“Quanto talento jovem!”

Tudo verdade.

Mas existe outra pergunta possível:

Onde estão os profissionais que estavam aqui vinte anos atrás?

Onde está o programador COBOL que conhecia aquele sistema inteiro?

Onde está a especialista em Db2?

Onde foi parar aquele administrador CICS?

E aquele sujeito que conhecia IMS como se tivesse ajudado a escrever o produto?

Alguns se aposentaram.

Outros mudaram de carreira.

Alguns viraram gestores.

Outros fornecedores.

Muitos passaram a trabalhar como consultores.

E alguns conheceram uma criatura peculiar do universo corporativo.

Eu a chamo de:

O Ceifeiro Silencioso.


5. O Ceifeiro dos Salários Altos

Ele não usa manto preto.

Não carrega foice.

Carrega Excel.

Às vezes PowerPoint.

Sua apresentação geralmente possui algum título como:

Workforce Optimization Initiative

ou:

Operational Efficiency Program

Ele entra silenciosamente no CPD.

Não vê João, especialista em CICS com vinte e cinco anos de experiência.

Vê:

RESOURCE 8472 — HIGH COST

Não vê Maria, que sabe por que determinado batch não pode executar antes das 23:40.

Vê:

SENIOR RESOURCE

Não vê Carlos, uma das três pessoas que sabem recuperar determinado subsistema depois de uma falha específica.

Vê:

ANNUAL COST: $$$$

E então surge a pergunta fatal:

— Por que estamos pagando tanto para uma pessoa?

Alguém responde:

— Porque ele possui vinte e cinco anos de experiência.

Então a planilha realiza sua magia:

1 especialista = 3 profissionais iniciantes pelo mesmo custo.

Pronto.

Nasceram três aventureiros Rank D.

E o Rank A desapareceu da Guilda.


6. Três juniores não são necessariamente um senior

Isso precisa ser dito com cuidado.

Todo senior já foi junior.

Profissionais jovens precisam receber oportunidades.

Precisamos formar novas gerações.

O problema não está nisso.

O erro está em imaginar que conhecimento profissional funciona como memória RAM.

Se preciso de 32 GB, posso colocar quatro módulos de 8 GB.

Experiência não funciona assim.

3 × Junior ≠ 1 × Senior

Às vezes:

10 × Junior ≠ 1 × Senior

Não porque os dez sejam incapazes.

Mas porque o veterano possui uma coisa extremamente difícil de medir:

contexto acumulado.

Ele sabe que aquele programa estranho existe porque uma legislação mudou em 1998.

Foi alterado novamente em 2005.

Recebeu integração em 2011.

Foi remendado durante uma crise em 2017.

E continua daquele jeito porque outro sistema ainda depende daquela estrutura.

O jovem olha o código e pergunta:

— Por que isso existe?

O veterano responde:

— Não mexe.

— Por quê?

— Mexemos uma vez em 2014.

— E?

— Parou faturamento.

Isso parece superstição.

Muitas vezes é arqueologia corporativa.


7. O veterano não sabe apenas matar monstros

Num mundo de fantasia, um aventureiro de sessenta anos deveria valer uma fortuna.

Não porque ainda consiga correr mais rápido que o guerreiro de vinte.

Mas porque sabe coisas que o jovem ainda precisa descobrir.

O jovem pergunta:

— Que espada devemos levar?

O veterano responde:

— Nenhuma.

— Como assim?

— Choveu três dias. A dungeon alaga pelo oeste. Os kobolds vão migrar para o segundo nível. Voltamos terça-feira.

Isso é experiência.

No CPD acontece a mesma coisa.

O jovem possui dez ferramentas modernas abertas.

O veterano olha o horário do incidente e diz:

— Isso não é Db2.

— Como sabe?

— O batch começou enquanto CICS ainda estava segurando aquele recurso.

Ele reconheceu o padrão.

Experiência profissional é, em grande parte, uma gigantesca biblioteca interna de padrões.


8. Só que o aventureiro precisa pagar pela própria espada

Existe outra semelhança cruel.

Aventureiros aparentemente ganham muito dinheiro.

Matam monstros.

Recebem recompensas.

Encontram tesouros.

Vendem materiais raros.

Mas continuam vivendo modestamente.

Por quê?

Porque faturamento não é lucro.

Recebeu 1.000 moedas.

Gastou 200 em poções.

150 reparando armadura.

100 afiando espada.

120 em hospedagem.

80 em transporte.

100 em comida.

150 substituindo equipamento destruído.

Sobrou pouco.

O aventureiro descobriu fluxo de caixa.

O profissional de tecnologia também.

Só que seu equipamento possui outra natureza.

Curso.

Livro.

Laboratório.

Certificação.

Webinar.

Evento.

Assinatura.

Computador.

Internet.

Cloud.

Software.

Idioma estrangeiro.

E sobretudo:

tempo.


9. Curso gratuito não significa custo zero

Essa é uma das grandes ilusões da educação profissional.

“Curso gratuito!”

Excelente.

Duração:

40 horas.

Então ele não custa zero.

Custa quarenta horas da sua vida.

Quarenta horas que poderiam ser usadas dormindo.

Caminhando.

Conversando.

Viajando.

Lendo.

Ou realizando aquela atividade cultural extremamente importante para a manutenção psicológica do profissional mainframe:

assistir anime.

O verdadeiro custo de uma formação não é apenas financeiro.

Existe custo de oportunidade.

Depois de determinada idade, começamos a perguntar menos:

“Quanto custa este curso?”

e mais:

“Isso vale vinte horas da minha vida?”

Essa pergunta é muito mais importante.


10. XP não garante promoção

Nos RPGs existe uma lógica maravilhosa:

XP aumenta.

Level aumenta.

Skills aumentam.

Rank aumenta.

Recompensa aumenta.

Na vida corporativa:

XP aumenta.

Certificações aumentam.

Responsabilidade aumenta.

Skills aumentam.

Conhecimento aumenta.

A empresa responde:

— Excelente trabalho!

Você espera.

— Continue assim!

Você continua esperando.

— Vamos discutir oportunidades no próximo ciclo.

E o salário permanece observando tudo de longe.

Esse é um problema interessante da carreira tecnológica:

o crescimento do conhecimento não possui relação linear com o crescimento da remuneração.

Você pode estudar duzentas horas durante um ano e receber exatamente o mesmo salário.

O conhecimento possui valor.

Aumenta empregabilidade.

Aumenta capacidade.

Pode aumentar poder de negociação.

Mas a conversão em dinheiro não acontece automaticamente.


11. Skill Inflation — o monstro que cresce junto com você

Quando comecei, uma determinada vaga poderia pedir algumas tecnologias.

Com o passar dos anos, a lista foi crescendo.

COBOL.

JCL.

CICS.

Db2.

VSAM.

Depois MQ.

RACF.

APIs.

REST.

Git.

CI/CD.

Java.

Python.

Cloud.

DevOps.

OpenShift.

Containers.

Observabilidade.

Segurança.

Agile.

Agora IA.

E inglês.

Naturalmente.

A profissão desenvolveu uma espécie de inflação de habilidades.

Aquilo que ontem era diferencial hoje virou requisito.

O que hoje é diferencial amanhã aparecerá discretamente na vaga como:

“conhecimento desejável”.

Depois:

“conhecimento obrigatório”.

A Guilda continua adicionando skills necessárias.

Só esqueceu de aumentar proporcionalmente a recompensa das quests.


12. A esteira tecnológica anda para trás

Existe uma crueldade particular na tecnologia.

Parte do conhecimento acumula.

Parte envelhece.

Alguns fundamentos permanecem valiosos durante décadas:

lógica;

algoritmos;

arquitetura;

modelagem;

transações;

concorrência;

segurança;

debugging;

sistemas operacionais;

bancos de dados;

análise de problemas.

Mas ferramentas mudam.

Versões mudam.

Interfaces mudam.

Produtos mudam.

Menus mudam.

E finalmente acontece aquela experiência maravilhosa.

Você abre uma ferramenta que conhece há dez anos.

Houve atualização.

Olha a tela.

E pensa:

“Onde colocaram essa porcaria?”


13. “Eu sei fazer isso!”

Essa frase merece atenção.

Você sabe fazer.

Realmente sabe.

Só não sabe mais onde fazer.

Antes:

Settings > Security > Authentication

Depois:

Workspace > Identity > Access > Advanced

Seu conhecimento não desapareceu.

Seu mapa desapareceu.

É como voltar para uma cidade onde você morou vinte anos antes.

Você conhece o destino.

Mas construíram viadutos.

Mudaram ruas.

Alteraram sentidos.

Transferiram a estação.

Você não desaprendeu a dirigir.

O território mudou.

E UI/UX consegue produzir no especialista uma sensação extremamente desagradável:

sentir-se iniciante numa atividade que domina.


14. Conhecimento possui meia-vida

Por isso gosto de separar conhecimento profissional em camadas.

Conhecimento fundamental

Algoritmos, arquitetura, lógica, debugging, transações, concorrência.

Possui longa duração.

Conhecimento de ecossistema

COBOL, Db2, CICS, IMS, MQ, Java, Python.

Muda, mas mantém continuidade conceitual.

Conhecimento de versão

“Na versão X esta configuração funciona desta maneira.”

Envelhece mais rápido.

Conhecimento de interface

“Clique no terceiro botão da esquerda.”

Esse pode morrer amanhã de manhã.

O erro é gastar energia demais memorizando conhecimento altamente perecível como se fosse fundamento.


15. A skill Rank S: reaprender

Depois de décadas, acontece algo curioso.

Você percebe que jamais conseguirá saber tudo.

E para de tentar.

Em compensação desenvolve uma habilidade extraordinária:

aprender novamente muito rápido.

Diante de uma ferramenta nova, o veterano começa fazendo perguntas conhecidas.

Onde estão os logs?

Como autentica?

Onde ficam permissões?

Como configura?

Existe CLI?

Existe API?

Como exporta?

Como automatiza?

Onde está a documentação?

O produto mudou.

As perguntas fundamentais não.

E saber quais perguntas fazer é uma forma sofisticada de conhecimento.


16. O eterno DLC chamado inglês

Então você decide estudar tecnologia.

Descobre que grande parte da documentação está em inglês.

Os melhores webinars aparecem em inglês.

Conferências internacionais usam inglês.

Fóruns técnicos usam inglês.

Manuais usam inglês.

Cursos usam inglês.

Você queria aprender COBOL.

Descobriu uma dependência:

COBOL REQUIRES ENGLISH

Então investe centenas ou milhares de horas aprendendo outro idioma.

E depois de anos aparece uma vaga:

English required.

Todo aquele esforço virou uma linha.

A Guilda considera simplesmente que você deveria possuir aquela skill.


17. O Ceifeiro volta

Depois de décadas estudando, trabalhando e sobrevivendo a produções, acontece algo irônico.

Seu salário finalmente ficou alto.

Porque você acumulou experiência.

E justamente por ter ficado alto...

chama atenção.

O Ceifeiro Silencioso retorna.

Olha a planilha.

Olha seu salário.

Olha novamente a planilha.

A foice começa a brilhar.


18. O nascimento do mercenário mainframe

O especialista deixa a grande empresa.

Mas existe um problema.

Ele possui uma criatura doméstica extremamente exigente.

Seu nome é:

BOLETO.

O verdadeiro Demon Lord.

Level 99.

Resistente a magia.

Imune a argumento.

E possui uma habilidade terrível:

Respawn mensal.

Então o veterano aceita outro projeto.

Seis meses.

Um ano.

Migração.

Upgrade.

Assessment.

Incidente.

Treinamento.

Conversão.

Modernização.

Ele virou mercenário.

Ou, usando terminologia empresarial:

consultor independente.


19. A ironia final

Alguns anos depois, a empresa percebe que perdeu determinado conhecimento.

Surge um projeto crítico.

Precisam urgentemente de alguém experiente.

Contratam uma grande consultoria.

A consultoria procura especialistas.

E encontra...

o mesmo sujeito dispensado anos antes.

Ele retorna.

Antes tinha crachá azul.

Agora possui crachá vermelho:

EXTERNAL CONSULTANT

Antes seu salário era considerado caro.

Agora sua hora custa três vezes mais.

Mas está em outro centro de custo.

Portanto:

aprovado.

Se isso não é roteiro de anime, não sei o que é.


20. O paradoxo do sistema que funciona

Existe ainda uma característica especialmente cruel de infraestrutura.

Quanto melhor funciona, menos visível fica seu valor.

Sistema cai semanalmente:

— Precisamos desses especialistas!

Especialistas trabalham.

Corrigem problemas.

Criam procedimentos.

Automatizam.

Estabilizam.

Cinco anos depois quase não existem incidentes.

Então alguém pergunta:

— Por que precisamos de tantos especialistas?

É extraordinário.

O aventureiro matou todos os monstros ao redor da aldeia.

Durante dez anos ninguém viu um goblin.

O prefeito conclui:

“Estamos desperdiçando dinheiro com aventureiros.”

Dispensa todos.

Dois anos depois aparece um dragão.

Nasce imediatamente:

Dragon Remediation Transformation Program

Orçamento: dez vezes maior.

Consultoria externa: contratada.

Prazo: ontem.


21. E finalmente chegamos ao sorriso ninja

Depois de décadas nessa profissão, surge uma cena recorrente.

Cliente:

— Você sabe fazer?

O veterano olha calmamente.

Sorri.

😎

— Sei.

Por dentro:

🦋🦋🦋🦋🦋

“Puta que pariu.”

Porque ele sabia perfeitamente fazer aquilo na versão anterior.

Agora existe release nova.

Interface nova.

Menus diferentes.

Funções renomeadas.

Documentação atualizada.

Talvez uma arquitetura parcialmente diferente.

Mas ele mantém o sorriso.

Não necessariamente porque conhece exatamente o caminho.

E certamente não porque seja irresponsável.

Existe algo mais profundo.

Ele pensa:

“Nunca fiz exatamente isso.”

E imediatamente:

“Mas já fiz quinze coisas parecidas.”

Essa é a diferença.


22. O veterano entra na dungeon

O monstro chama-se:

Enterprise Platform Ultimate Cloud AI Edition 2027.

Ele nunca viu aquela versão.

O monstro olha para ele.

Ele olha para o monstro.

🦋

Abre documentação.

🦋🦋

“Por que mudaram isso?”

Abre release notes.

🦋🦋🦋

“Claro. Deprecated.”

Encontra um manual de 684 páginas.

Café.

Laboratório.

Primeiro teste.

ERROR

— Interessante.

Segundo teste.

ERROR

— Muito interessante.

Terceiro teste.

SUCCESS

Silêncio.

Ele fecha 37 abas.

Volta para a reunião.

😎

— Como eu estava dizendo, podemos fazer.

Ninguém viu as borboletas.


23. Easter egg: o verdadeiro significado de Senior

Talvez senioridade nunca tenha significado:

“Eu sei tudo.”

Isso seria impossível.

Senioridade talvez seja:

“Já estive perdido vezes suficientes para saber que consigo encontrar o caminho.”

Essa diferença é gigantesca.

O iniciante teme não saber.

O veterano também não sabe algumas coisas.

Mas já aprendeu a funcionar dentro da incerteza.

Sabe pesquisar.

Testar.

Comparar.

Eliminar hipóteses.

Ler logs.

Criar laboratório.

Voltar atrás.

Perguntar.

Experimentar.

Errar pequeno antes de errar grande.

Essa talvez seja a maior skill adquirida depois de décadas trabalhando com tecnologia.


24. Então por que existem tão poucos aventureiros grisalhos?

Porque a carreira seleciona.

Alguns abandonam.

Alguns mudam.

Alguns viram gestores.

Alguns ensinam.

Alguns tornam-se arquitetos.

Alguns passam para fornecedores.

Alguns viram consultores.

Alguns são encontrados pelo Ceifeiro.

E alguns simplesmente decidem que já passaram noites demais acordados esperando um job terminar.

Os que permanecem carregam cicatrizes invisíveis.

Mas carregam também uma coisa extraordinariamente valiosa:

memória institucional.

Eles lembram monstros que já não existem.

Sabem por que determinadas muralhas foram construídas.

Reconhecem sinais que os demais ainda não aprenderam a observar.

São bibliotecas ambulantes de incidentes, soluções, fracassos e decisões.

Uma empresa inteligente não deveria perguntar apenas:

“Quanto custa esse profissional?”

Deveria perguntar:

“Quanto custa perder aquilo que somente ele sabe?”

São perguntas completamente diferentes.


Epílogo — 03:17

O telefone toca.

O jovem programador atende.

Produção está parada.

Ele olha os logs.

Não entende.

Tenta novamente.

Nada.

Ao lado existe um velho consultor tomando café.

— Posso perguntar uma coisa?

O veterano aproxima a cadeira.

Olha a tela durante alguns segundos.

— Quando começou?

— 02:46.

Ele sorri.

— Veja o job que executou às 02:45.

O jovem encontra.

Ali está.

O problema.

— Como você sabia?

O veterano pega novamente a caneca.

— Em 2009 aconteceu algo parecido.

Silêncio.

O jovem olha para ele como eu olhava para os veteranos quando comecei.

Talvez pense:

“Um dia quero saber tudo isso.”

Mas o veterano sabe de uma coisa que o jovem ainda descobrirá.

Nunca saberá tudo.

A dungeon continuará mudando.

Novos monstros aparecerão.

Novas releases serão instaladas.

Interfaces serão redesenhadas.

Skills ficarão obsoletas.

Cursos serão necessários.

Certificações vencerão.

O Ceifeiro continuará andando silenciosamente pelos corredores.

E o Boleto continuará ressuscitando todo mês.

O que resta ao aventureiro?

Continuar aprendendo.

Continuar curioso.

Ensinar aquilo que sabe.

Preservar os fundamentos.

Não confundir interface com conhecimento.

Não gastar a vida tentando decorar tudo.

E, principalmente, entender que experiência não é conhecer antecipadamente todas as respostas.

Experiência é saber o que fazer quando você não conhece a resposta.

O jovem fecha o incidente.

03:42.

— Resolvido.

O veterano levanta.

— Ótimo.

— Posso perguntar mais uma coisa?

— Claro.

— Quando o diretor perguntou se você sabia resolver isso... você já sabia?

O velho aventureiro para por alguns segundos.

Olha para o jovem.

Abre aquele sorriso ninja desenvolvido depois de décadas entrando em dungeons corporativas.

😎

— Claro que sabia.

E continua andando pelo corredor.

Enquanto, invisíveis para todos os outros...

🦋🦋🦋

...as últimas borboletas finalmente abandonam seu estômago.

Porque existe uma coisa que nenhum curso ensina e nenhuma certificação consegue medir:

o veterano não entra tranquilo na dungeon porque sabe o que encontrará.

Ele entra porque já voltou vivo de muitas outras.

Um Café no Bellacosa Mainframe

Onde todo programador é um aventureiro, toda produção é uma dungeon e todo boleto tem respawn automático.


quinta-feira, 20 de agosto de 2026

A Lei Seca do Algoritmo — ou como comecei lendo uma lei brasileira e duas semanas depois a ONU cercava minha ilha

Bellacosa Mainframe e a lei seca do algoritmo ia moderna um jogo do absurdo

☕ Um Café no Bellacosa Mainframe

A Lei Seca do Algoritmo — ou como comecei lendo uma lei brasileira e duas semanas depois a ONU cercava minha ilha

Uma pequena história sobre leis, IA, jurisdições, Port Royal, mercenários, dilemas de segurança e a extraordinária capacidade humana de transformar um IF de quatro linhas numa crise internacional

Tudo começou de maneira perfeitamente inocente.

Eu estava lendo uma notícia sobre uma lei brasileira.

Qual lei?

Não importa.

Aliás, é melhor nem dizer, porque o objeto específico da lei é muito menos interessante do que o fenômeno que ela despertou nos aproximadamente um milhão de chimpanzés que administram meu cérebro, supervisionados, naturalmente, por Tico e Teco.

A notícia explicava uma evolução legislativa bastante curiosa.

Primeiro havia o humano.

O humano fazia alguma coisa, sofria alguma coisa ou aparecia em alguma coisa.

A sociedade dizia:

— Isso não pode.

O legislador concordava:

— Realmente não pode.

E escrevia uma lei.

Muito bem.

Caso encerrado.

Só que então apareceu uma situação nova.

A lei não previa exatamente aquilo.

Então alguém colocou um puxadinho.

Depois apareceu outra situação.

Novo puxadinho.

Depois veio a Internet.

Mais um puxadinho.

Depois atravessaram fronteiras.

Puxadinho internacional.

Depois chegaram algoritmos capazes de produzir coisas que anteriormente exigiam participação humana.

E o legislador descobriu horrorizado que agora existia algo que parecia com o objeto originalmente proibido, mas que havia sido criado sem que nenhum ser humano tivesse participado daquilo como matéria-prima.

Era sintético.

Artificial.

Quase uma carne vegana jurídica.

Parecia carne.

Tinha formato de carne.

Era consumida como carne.

Mas nenhuma vaca havia participado da reunião.

E meus chimpanzés imediatamente interromperam suas atividades normais.



🧠 O primeiro IF era simples

Imagino que a versão 1.0 da legislação fosse conceitualmente parecida com isto:

IF EXISTE-HUMANO
   AND OCORREU-ATO-PROIBIDO
       MOVE "CRIME" TO RESULTADO
END-IF

Elegante.

Legível.

Cabe numa tela 3270.

O problema é que seres humanos são excelentes em encontrar situações que o programador original não imaginou.

Logo apareceu:

IF EXISTE-HUMANO
   OR EXISTE-REPRESENTACAO-DO-HUMANO

Depois:

OR EXISTE-GRAVACAO
OR EXISTE-FOTOGRAFIA
OR EXISTE-AUDIO

Depois chegou a Internet:

OR FOI-DISTRIBUIDO
OR FOI-COMPARTILHADO
OR FOI-TRANSMITIDO

Depois alguém colocou o servidor em outro país.

Novo ELSE.

Depois apareceu IA generativa.

E finalmente chegamos ao maravilhoso:

OR NAO-EXISTE-HUMANO
   BUT-PARECE-QUE-EXISTE


Nesse momento o velho programador COBOL dentro de mim olhou para aquilo e pensou:

isso virou sistema legado.

A intenção original continua lá.

Só que quarenta change requests depois ninguém mais sabe exatamente onde termina a regra original e começa o remendo colocado numa sexta-feira às 17h43 porque produção precisava subir naquele fim de semana.



🤖 Então o humano desapareceu

Essa foi a parte que realmente me chamou atenção.

Durante muito tempo havia uma cadeia relativamente compreensível:

humano → ato → registro → distribuição → dano.

Mas a tecnologia tornou possível outra:

algoritmo → geração → arquivo → distribuição.

O humano que originalmente justificava boa parte da proteção simplesmente poderia não existir naquela cadeia.

Não houve modelo.

Não houve fotografia original.

Não houve gravação.

Não houve determinada pessoa fazendo aquilo.

O objeto nasceu sinteticamente.

Naturalmente, a sociedade respondeu:

— Continua não podendo.

E surgiu outro puxadinho.

Perfeitamente compreensível.

Só que meus chimpanzés fizeram a pergunta que jamais se deve permitir que chimpanzés façam:

E se em outro país puder?

Silêncio.

Tico olhou para Teco.

Teco abriu um atlas.

Temos quase duzentos países no planeta.

É estatisticamente difícil conseguir fazer quase duzentos governos concordarem até sobre a temperatura adequada do café.

Naturalmente haverá diferenças legislativas.

E alguém encontrará uma.



🌎 Regulation-as-a-Service

Imagine então um pequeno país.

Não precisamos dizer qual.

Chamaremos de República Democrática, Popular, Constitucional, Marítima e Absolutamente Respeitável de Qualquerlândia.

Qualquerlândia analisa o assunto e decide:

— Material envolvendo pessoas reais? Proibido.

— Material inteiramente sintético?

O funcionário consulta o código.

Consulta novamente.

Chama o chefe.

O chefe chama o ministro.

O ministro chama um advogado.

Finalmente alguém responde:

— Aqui não é crime.

Pronto.

Nasceu uma indústria.

Criadores registram empresas em Qualquerlândia.

Servidores aparecem.

Processadores financeiros aparecem.

Advogados aparecem.

Contadores aparecem.

Data centers aparecem.

O resto do mundo continua consumindo exatamente o mesmo produto.

A diferença é que agora a receita termina em Qualquerlândia.

O país que proibiu continua tendo consumidores.

Continua tendo demanda.

Continua tendo dinheiro saindo.

Só deixou de ter a empresa.

O imposto.

O servidor.

O emprego.

E parte da capacidade de fiscalização.

Nesse momento pensei:

isso é uma espécie de Lei Seca digital.



🍺 Al Capone precisava de caminhões

A Lei Seca americana descobriu uma coisa desagradável:

proibir oferta não significa automaticamente eliminar demanda.

Se existe demanda suficientemente grande, alguém tentará atendê-la.

Só que Al Capone tinha um problema logístico.

Álcool pesa.

Precisa de garrafas.

Caixas.

Caminhões.

Navios.

Depósitos.

Motoristas.

Fronteiras.

Policiais subornáveis.

Um arquivo digital não possui nenhuma dessas inconveniências.

Ele pesa aproximadamente:

nada.

Pode atravessar cinquenta fronteiras antes que eu termine esta frase.

E IA generativa acrescentou algo ainda mais divertido.

Talvez nem sequer exista estoque.

O advogado de Qualquerlândia poderia dizer:

— Nós não armazenamos o produto.

— Não importamos o produto.

— Não exportamos o produto.

— Não possuímos o produto.

— O usuário solicita alguma coisa e uma máquina calcula pixels.

Imagino 193 delegações internacionais pedindo intervalo para café.



🏴‍☠️ Foi quando fundei Port Royal

Aqui meus chimpanzés abandonaram definitivamente qualquer compromisso com a realidade.

Pensei:

Muito bem. Então criarei minha própria Port Royal.

Uma pequena jurisdição marítima.

Centenas de servidores.

Energia própria.

Data center.

Links redundantes.

E uma constituição extremamente simples:

FREE FOR ALL

Não recomendo isso como política pública.

Estamos fazendo ficção satírica.

Mas mentalmente era maravilhoso.

Na entrada:

WELCOME TO PORT ROYAL CLOUD

Free for All Since 2026.

Terms and Conditions: No.

E imediatamente descobrimos o primeiro problema.

Você pode declarar independência.

Seu roteador não.



🌐 O ASN também tem sentimentos

Port Royal precisava de Internet.

Quem anuncia nosso ASN?

Precisávamos de upstream.

Precisávamos de cabos.

Precisávamos de DNS.

Precisávamos importar SSDs.

Precisávamos comprar processadores.

Precisávamos receber pagamentos.

Precisávamos contratar pessoas.

Precisávamos de peças para os geradores.

Ou seja:

às 14h eu havia declarado independência.

Às 14h07 descobri que dependia economicamente de metade do planeta.

Mas meus chimpanzés não desistiram.

Port Royal cresceu.

Criadores começaram a aparecer.

Empresas começaram a registrar suas obras ali.

Dinheiro começou a circular.

E algum governo estrangeiro finalmente disse:

— Chega.



🚤 Primeiro veio a Guarda Costeira

Essa parte é importante.

Na minha imaginação, ninguém começou mandando porta-aviões.

Seria ridículo.

Primeiro veio uma pequena força marítima de fiscalização.

Objetivo limitado.

Entrar.

Interromper determinadas atividades.

Talvez apreender alguma coisa.

Port Royal respondeu:

— Vocês não possuem jurisdição aqui.

Eles responderam:

— Achamos que possuímos.

Port Royal tinha segurança privada.

Mercenários.

Os mercenários impediram a intervenção.

E naquele exato segundo aconteceu algo fundamental:

a discussão deixou de ser sobre arquivos.

Agora era sobre soberania.



⚓ Então veio um navio maior

O governo estrangeiro não poderia simplesmente dizer:

— Bem, nossos homens foram expulsos. Vida que segue.

Porque agora havia precedente.

Então enviou força suficiente para garantir que aquilo não acontecesse novamente.

Port Royal observou o horizonte.

Um destróier.

Talvez dois.

Meus chimpanzés convocaram reunião extraordinária.

E foi quando apareceram os amigos.



🤝 A Liga dos Países que Também Não Gostam que Mandem Neles

Algumas nações possuíam relações comerciais com Port Royal.

Outras não davam a mínima para nossos servidores, mas estavam muito interessadas no precedente.

Porque a pergunta havia mudado.

Não era mais:

"Port Royal pode hospedar aquilo?"

Agora era:

"Um país pode entrar militarmente numa jurisdição menor porque discorda das leis dela?"

Isso interessava a muita gente.

Uma pequena liga de países amigos enviou navios para defesa dissuasora.

Não para atacar.

Naturalmente.

Todos estavam ali pela paz.

E essa é uma das frases mais perigosas que a humanidade já inventou:

"Trouxemos armas para garantir a paz."



📈 O algoritmo da dissuasão

O primeiro lado tinha um navio.

O segundo colocou dois.

O primeiro pensou:

— Dois?

Então trouxe quatro.

O segundo percebeu quatro navios hostis e trouxe oito.

Logo:

A = 1
B = 2

A = 4
B = 8

A = 16
B = 32

Port Royal:

— Gente... eram uns servidores.

Ninguém estava ouvindo.

Agora havia aeronaves de patrulha.

Guerra eletrônica.

Submarinos.

Defesa aérea.

Navios de apoio.

Satélites observando.

Serviços de inteligência.

E jornalistas transmitindo ao vivo da praia.



💣 O dilema de segurança

Existe uma perversidade maravilhosa nesse mecanismo.

O lado A diz:

— Estou aumentando minhas forças porque B está perigoso.

B responde:

— Estou aumentando minhas forças porque A está aumentando suas forças.

A observa:

— Viu? Eu estava certo sobre B!

B observa:

— Viu? Eu estava certo sobre A!

Ambos podem sinceramente não querer guerra.

Ambos podem sinceramente acreditar que suas forças são defensivas.

E ambos terminam extraordinariamente preparados para travar justamente a guerra que dizem querer evitar.

Port Royal havia se tornado uma demonstração prática do dilema de segurança.

E ninguém pediu autorização aos chimpanzés.



📰 CNN: CRISE DE PORT ROYAL — DIA 12

Nesse ponto imagino a televisão.

Especialistas diante de mapas.

Setinhas vermelhas.

Setinhas azuis.

Fotos de satélite.

Almirantes aposentados.

Professores de relações internacionais.

Economistas.

Advogados.

Um sujeito chamado "especialista em Port Royal" que duas semanas antes provavelmente não sabia que Port Royal existia.

Mercados caindo.

Petróleo subindo.

Seguradoras marítimas suspendendo cobertura.

Companhias desviando rotas.

E em algum estúdio alguém pergunta:

— Como chegamos até aqui?

Ninguém sabe responder em menos de quarenta minutos.



🏛️ Finalmente chegamos à ONU

E foi aí que minha imaginação chegou ao ponto que originalmente contei primeiro.

A ONU entra no circuito.

Conselho de Segurança.

Reuniões extraordinárias.

Propostas de resolução.

Vetos.

Sanções.

Diplomatas entrando e saindo de salas.

Coalizões.

Estados com capacidade nuclear envolvidos indiretamente na crise.

Importante: a ONU não possui uma esquadra nuclear própria esperando alguém apertar o botão vermelho.

Mas isso pouco importava para meus chimpanzés.

Na versão mental cinematográfica, o horizonte de Port Royal já estava cheio de poder naval suficiente para fazer qualquer pessoa reconsiderar seriamente suas escolhas profissionais.

E então percebi algo extraordinário.



❓ Ninguém mais lembrava por que aquilo começou

Essa é provavelmente minha parte favorita.

No começo:

"Precisamos discutir determinado material sintético."

Depois:

"Precisamos discutir jurisdição."

Depois:

"Precisamos discutir Port Royal."

Depois:

"Precisamos discutir violação territorial."

Depois:

"Precisamos discutir o incidente com a Guarda Costeira."

Depois:

"Precisamos discutir a presença da frota."

Depois:

"Precisamos discutir o tratado entre Port Royal e seus aliados."

Depois:

"Precisamos discutir equilíbrio estratégico regional."

Depois:

"Precisamos impedir uma guerra internacional."

O objeto original?

Esquecido.

Enterrado debaixo de quinze camadas de consequências.

É exatamente como um incidente de produção.


🖥️ INC0000001 — Usuário não consegue abrir arquivo

Se você trabalha há tempo suficiente em mainframe, já viu isso.

Às 9h:

Usuário não consegue acessar arquivo.

Às 10h:

DBA entrou na bridge.

10h15:

Storage.

10h30:

RACF.

11h:

Rede.

11h30:

Middleware.

12h:

Fornecedor.

13h:

Gerência.

14h:

Diretoria.

15h:

Executivo.

16h:

Regulador informado.

17h:

Quarenta e sete pessoas na conference call.

Às 17h12 alguém finalmente pergunta:

— Qual era mesmo o erro original?

Silêncio.

Um velho operador consulta o log.

— Permissão errada num diretório.

Port Royal era exatamente isso.

Só que com submarinos nucleares.


☕ E talvez essa seja a verdadeira história

Comecei lendo uma lei brasileira.

Não importa qual.

Ela apenas serviu como ponto inicial para observar uma característica extraordinariamente humana.

Criamos regras para resolver problemas.

A realidade encontra situações que as regras não previram.

Acrescentamos exceções.

A tecnologia cria outras possibilidades.

Acrescentamos novas regras.

As atividades atravessam fronteiras.

Criamos mecanismos extraterritoriais.

Empresas migram.

Governos reagem.

Jurisdicionalmente permissivos descobrem oportunidades econômicas.

Outros governos pressionam.

A questão econômica torna-se diplomática.

A questão diplomática torna-se estratégica.

E, se ninguém apertar PAUSE, podemos acabar discutindo porta-aviões quando originalmente estávamos discutindo pixels.

A tecnologia não destrói necessariamente a lei.

Ela frequentemente faz algo muito mais divertido:

obriga a lei a persegui-la.

E cada vez que a lei alcança a tecnologia, alguém pergunta:

— E se fizermos deste outro jeito?

Novo puxadinho.

Novo IF.

Novo ELSE.

Nova jurisdição.

Até algum programador jurídico do futuro abrir o código legislativo e perguntar:

— Quem foi o desgraçado que escreveu isso?

E alguém responder:

— Ninguém.

— Como ninguém?

— Começou pequeno em 1998. Depois fomos fazendo manutenção.

O programador fecha o terminal.

Vai buscar café.

E decide não tocar em absolutamente nada.


🏴‍☠️ Epílogo — Dia 14 em Port Royal

O secretário-geral consegue finalmente reunir todas as partes.

Do lado de fora existem navios suficientes para transformar o oceano num estacionamento.

Ele abre uma pasta de oitocentas páginas.

Ajusta os óculos.

Olha para as delegações.

— Senhores, estamos diante de uma das mais graves crises internacionais das últimas décadas.

Silêncio absoluto.

— Antes de começarmos, gostaria apenas de esclarecer uma coisa.

Folheia os documentos.

Folheia novamente.

Chama um assessor.

Cochicham.

Ele volta ao microfone:

— Alguém poderia explicar por que começou tudo isso?

Silêncio.

Russos olham para americanos.

Americanos olham para europeus.

Europeus olham para chineses.

Chineses olham para Port Royal.

No fundo da sala, levanto timidamente a mão.

— Excelência...

Todos olham.

— Bem...

Pigarreio.

— Eu estava lendo uma notícia sobre uma lei brasileira.

Silêncio.

O secretário-geral fecha os olhos.

— E?

— E achei curioso.

Mais silêncio.

— Então comecei a pensar.

O secretário-geral olha pela janela para três grupos de batalha de porta-aviões.

Depois olha para mim.

Depois para os papéis.

Depois novamente para mim.

— Senhor Bellacosa...

— Sim?

— Da próxima vez...

Longa pausa.

Leia futebol.

☕ Fim.


Um Café no Bellacosa Mainframe

Onde começamos com legislação, passamos por inteligência artificial, fundamos uma micronação, contratamos mercenários, reinventamos a Lei Seca, descobrimos o dilema de segurança e quase provocamos a Terceira Guerra Mundial.

Tudo porque ninguém colocou um MAX-RETRY = 3 nos chimpanzés.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-de-boteco-quando-o-usuario.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/antes-do-chatgpt-tinha-biblioteca-nao.html

https://eljefemidnightlunch.blogspot.com/2026/08/o-milhao-de-chimpanzes-gutenberg-e.html

https://eljefemidnightlunch.blogspot.com/2026/08/organizacoes-tabajara-mainframe-seus.html










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




 

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...