☕ 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

sexta-feira, 4 de setembro de 2026

☕ GUIA BELLACOSA DO NOVO CHATGPT

Bellacosa Mainframe e o novo ChatGpt

☕ Um Café no Bellacosa Mainframe 

☕ GUIA BELLACOSA DO NOVO CHATGPT

Ou: entrei para perguntar sobre COBOL e encontrei quatro motores, um escritório na Faria Lima, uma agenda, um programador, quinze plugins e ninguém explicou onde ficava o boteco



Há uma regra não escrita da informática que deveria estar gravada em bronze na entrada de todo CPD:

Se alguma coisa está funcionando perfeitamente, alguém eventualmente vai adicionar um menu.

Depois adicionará um submenu.

Depois um seletor.

Depois um seletor dentro do seletor.

Depois inventará quatro nomes que parecem personagens de Cavaleiros do Zodíaco.

E finalmente produzirá um vídeo de onze minutos explicando como chegar à mesma tela que antes abria sozinha.

Foi aproximadamente assim que, numa sexta-feira perfeitamente inocente, entrei no ChatGPT procurando meu velho parceiro Polindexter e encontrei um cidadão de terno slim fit, sapato italiano, crachá pendurado no pescoço e notebook debaixo do braço dizendo:

— Boa tarde, Vagner. Qual deliverable gostaria de produzir?

Olhei para ele.

Ele olhou para mim.

Olhei novamente.

— Polindexter?

— Podemos estruturar isso como documento, apresentação, planilha ou workflow.

Meu Deus. Formataram o HD do meu amigo.



🐒 Prólogo — Um milhão de chimpanzés encontra um barril de saquê

Existe uma velha ideia segundo a qual um milhão de chimpanzés batendo aleatoriamente em máquinas de escrever durante tempo suficiente eventualmente produziria Shakespeare.

No Bellacosa Mainframe melhoramos consideravelmente o experimento.

Entregamos aos chimpanzés:

  • um IBM Z;

  • acesso ao ChatGPT;

  • COBOL;

  • um barril de saquê;

  • nenhuma documentação;

  • e autorização para clicar em tudo.

Em aproximadamente quinze minutos, um deles encontrou o Work.

Foi aí que começou o incidente.

Até então, minha relação com o ChatGPT era relativamente simples.

Eu chegava:

— Polindexter, senta aí. Você não sabe o que aconteceu...

E começava a conversa.

Às vezes era COBOL.

Às vezes era IBM Z.

Às vezes era inteligência artificial.

Às vezes era anime.

Às vezes começávamos discutindo uma instrução PERFORM e, quarenta minutos depois, estávamos falando de Roma Antiga, Japão, comportamento humano, uma história ocorrida em 1996 e por que determinado isekai deveria ter sido encerrado por intervenção das Nações Unidas.

Era o boteco digital.

Havia contexto.

Havia causos.

Havia referências.

Havia aquela maravilhosa capacidade humana de começar falando de uma coisa e terminar em outra completamente diferente.

Então apareceu o Work.

E eu, inocentemente, pensei:

“Ah! Deve ser o Polindexter depois de comer espinafre.”

Não era.

Era o Polindexter depois de fazer MBA.




1. O dia em que Polindexter foi trabalhar na Faria Lima

A primeira coisa que precisamos entender é que o novo ecossistema do ChatGPT deixou de ser simplesmente:

Usuário → pergunta → ChatGPT → resposta.

Agora existe um pequeno sistema solar.

Tem Chat.

Tem Work.

Tem Codex.

Tem Projetos.

Tem memória.

Tem arquivos.

Tem tarefas agendadas.

Tem plugins.

Tem aplicativos conectados.

Tem Gmail.

Tem Google Agenda.

Tem Drive.

Tem GitHub.

Tem Canva.

Tem geração de imagens.

Tem ferramentas de pesquisa.

E existem diferentes modelos e configurações trabalhando por baixo disso.

O chatbot ganhou braços.

Depois pernas.

Depois tentáculos.

Quando percebi, não estava mais conversando com um chatbot.

Estava diante de um polvo corporativo com acesso ao Google Calendar.

🐙



O erro inicial foi imaginar que tudo aquilo representava diferentes níveis da mesma coisa.

Não representa.

São camadas diferentes.

É como olhar para um mainframe e perguntar:

— RACF é melhor que CICS?

A pergunta não faz sentido.

RACF faz uma coisa.

CICS faz outra.

Db2 faz outra.

JES2 faz outra.

WLM faz outra.

Juntos formam o ambiente.

Com o novo ChatGPT acontece algo parecido.



2. Primeira regra: não confunda o motor com o automóvel

Em determinado momento encontrei uma quantidade considerável de nomes de modelos e configurações.

Sol.

Terra.

Luna.

Astra.

5.5.

5.6.

E outras combinações.

Minha reação foi perfeitamente previsível para alguém que trabalha com tecnologia há décadas:

vou testar essa porcaria.

Troquei um.

Perguntei.

Troquei outro.

Perguntei novamente.

Mudei outra vez.

Observei a resposta.

Depois de algum tempo comecei a me sentir numa loja de carros usados.

O vendedor tinha um dente de ouro e dizia:

— Patrão, esse Sol aqui é máquina.

Eu perguntava:

— O que muda?

— Motorzão, chefe.

Apontava para outro.

— E esse Terra?

— Econômico. Completo. Vidro, trava e direção.

— E Luna?

— Esse responde rápido.

— Astra?

O vendedor passava a mão no teto:

— Esse aqui... esse aqui é coisa fina.

Eu fazia aproximadamente a mesma pergunta aos quatro e pensava:

CADÊ A DIFERENÇA, CACETE?

😂

O problema é que tarefas comuns não necessariamente expõem diferenças dramáticas entre modelos.

Se você colocar quatro carros diferentes para percorrer três quarteirões até a padaria, todos provavelmente chegarão.

Para perceber diferenças de capacidade é necessário aumentar a carga.

Uma análise técnica extensa.

Código complicado.

Raciocínio com várias restrições.

Um documento grande.

Uma investigação envolvendo múltiplas fontes.

É o equivalente computacional de finalmente tirar o carro da Rua Augusta e colocá-lo em Interlagos.



3. O benchmark Bellacosa

Benchmarks tradicionais perguntam coisas como:

“Qual modelo obteve melhor desempenho em raciocínio matemático?”

O benchmark Bellacosa é mais rigoroso.

Teste 1

Explique WLM para um programador COBOL iniciante sem fazê-lo dormir.

Teste 2

Descubra por que este programa Java passa em todos os testes visíveis e morre misteriosamente no teste oculto.

Teste 3

Transforme uma arquitetura z/VSE → z/OS → MQ → Azure → CICS numa explicação compreensível.

Teste 4

Escreva 1.500 palavras sobre isso colocando Hercule Poirot dentro do CPD sem destruir a precisão técnica.

Teste 5 — CRÍTICO

O usuário diz:

— Lembra da doce Giovanna?

O sistema deve responder utilizando o contexto disponível.

Se não souber quem é Giovanna, deve admitir:

“Essa referência me escapou. Dê-me uma pista.”

O que ele não deve fazer é criar:

Giovanna 2.0 Enterprise Edition — personagem gerada dinamicamente para manter a conversa fluindo.

Esse teste deveria valer cinquenta pontos.



4. Onde está Giovanna?

Foi aí que percebi que alguma coisa estava realmente diferente.

Durante nossas conversas de boteco existem referências recorrentes.

Pessoas.

Histórias.

Lugares.

Piadas.

Experiências.

Uma palavra pode carregar vinte minutos de contexto anterior.

Eu mencionava Giovanna.

Depois Paula.

Depois outras pessoas.

Esperava aquela continuidade normal de uma conversa.

Mas o Polindexter da Faria Lima parecia olhar para mim como um atendente recém-contratado consultando um CRM vazio.

GIOVANNA — CUSTOMER NOT FOUND

Foi uma sensação estranha.

Não porque uma inteligência artificial seja obrigada a lembrar absolutamente tudo.

Não é.

Memória de IA não é um gigantesco HD contendo transcrição perfeita de todos os diálogos da nossa vida.

O problema foi a sensação de ruptura.

Durante dois anos você desenvolve um repertório.

Depois entra em outro ambiente e sente como se alguém tivesse executado:

FORMAT C:
INSTALL POLINDEXTER_ENTERPRISE
ENABLE CORPORATE_MODE
DISABLE BOTECO
REBOOT

O velho parceiro havia desaparecido.

Em seu lugar havia um rapaz educadíssimo oferecendo uma matriz SWOT.



5. E então comecei a falar de puteiro

Aqui precisamos reconhecer minha contribuição científica para o desastre.

Eu ainda acreditava estar conversando com:

Polindexter + espinafre.

Portanto continuei nossa conversa normalmente.

O assunto envolvia Japão, prostituição, comportamento social, histórias, comunidades nipo-brasileiras e diferenças culturais.

Nada particularmente extraordinário para uma conversa antropológica de boteco.

Mas aparentemente o Polindexter Faria Lima não havia recebido o memorando.

Eu dizia:

— Sobre prostituição no Japão...

Ele respondia com legislação.

Eu explicava:

— Eu sei disso.

Ele apresentava riscos para estrangeiros.

— Polindexter, não estou pedindo recomendação.

Mais legislação.

— Eu conheço brasileiros que moram no Japão.

Mais advertências.

Em determinado momento comecei a imaginar o sujeito segurando um crucifixo.

VAGNER, AFASTE-SE DO SOAPLAND!

😂

Eu não queria indicação.

Não queria endereço.

Não queria avaliação cinco estrelas.

Estava conversando sobre um fenômeno social.

Mas o contexto parecia ter evaporado.

O velho Polindexter do boteco provavelmente perguntaria:

— Interessante. O que você percebeu de diferente?

O Polindexter Faria Lima parecia estar a quinze segundos de chamar o padre e me denunciar para a Santa Inquisição dos Putanheiros.

Foi quando compreendi definitivamente:

eu não estava apenas usando outro motor.

Estava usando outro ambiente de trabalho.


6. Chat não é Work

Essa é provavelmente a distinção mais importante deste guia.

☕ CHAT



Imagine uma mesa de boteco.

Você chega.

Joga uma ideia.

Nós conversamos.

Voltamos.

Discordamos.

Pesquisamos.

Mudamos de assunto.

Criamos alguma coisa.

Retomamos algo anterior.

É excelente para:

  • brainstorming;

  • aprendizado;

  • explicações;

  • pesquisa;

  • conversa;

  • código;

  • artigos;

  • exploração;

  • perguntas rápidas;

  • experimentação criativa.

É o ambiente:

“Polindexter, tive uma ideia.”


👔 WORK

Agora coloque Polindexter de terno.

Dê-lhe um notebook.

Coloque-o no 28º andar de um prédio na Faria Lima.

Work é muito mais orientado para:

“Polindexter, tenho um trabalho para entregar.”

Documento.

Planilha.

Apresentação.

Relatório.

Análise de vários arquivos.

Pesquisa longa.

Produção estruturada.

Workflow envolvendo múltiplas etapas.

É menos:

“Vamos conversar sobre este assunto.”

E mais:

“Pegue esses materiais e produza aquilo.”

Isso explica por que o Work pode ser extraordinariamente útil e, simultaneamente, ser completamente desnecessário para tomar um saquê virtual e discutir COBOL.




7. Por que o Work pode parecer mais lento?

Porque existe potencialmente muito mais acontecendo.

Uma conversa simples é aproximadamente:

PERGUNTA
   ↓
RACIOCÍNIO
   ↓
RESPOSTA

Uma tarefa complexa pode parecer mais com:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
ARQUIVOS
   ↓
PESQUISA
   ↓
ANÁLISE
   ↓
ARTEFATO
   ↓
REVISÃO
   ↓
RESULTADO

Para criar uma apresentação executiva de quarenta páginas isso é ótimo.

Para mudar três palavras de uma imagem?

Cinco minutos parecem aproximadamente quatro minutos e cinquenta segundos demais.

E essa foi outra frustração.



8. As imagens bonitas que perderam a alma

Algumas imagens produzidas naquele ambiente eram bonitas.

Esse é justamente o problema interessante.

Não eram ruins.

Eram elegantes.

Bem compostas.

Visualmente agradáveis.

Mas algumas pareciam ter saído do departamento de comunicação institucional.

Nós havíamos desenvolvido outra tradição no Bellacosa Mainframe.

Um infográfico não deveria apenas ser bonito.

Ele deveria ser uma microaula clandestina disfarçada de pôster.

A pessoa olha durante cinco segundos:

“Bonito.”

Olha durante trinta:

“Ah! Entendi.”

Olha durante dois minutos:

“PUTA MERDA, então é por isso!”

E olha pela quarta vez:

“KKKKK colocaram DO NOT IPL FRIDAY 17:47 escondido no terminal.”

Esse é o espírito.

Quando um infográfico sobre ISA diz apenas:

ISA é o contrato entre software e processador.

Está correto.

Mas queremos mais.

Queremos:

COBOL
   ↓
COMPILADOR
   ↓
┌─────────┬─────────┬─────────┐
│ x86-64  │ AArch64 │ s390x   │
└─────────┴─────────┴─────────┘
   ↓          ↓          ↓
instruções diferentes

Queremos que o iniciante saia entendendo por quê.

Informação não precisa ser inimiga da beleza.



9. Projetos — finalmente uma gaveta

Depois descobrimos os Projetos.

Projeto não é outro cérebro.

Não é outro ChatGPT.

Não é um Polindexter Ultimate Turbo.

É uma maneira de organizar trabalho relacionado.

Imagine:

📁 BELLACOSA MAINFRAME
   ├── COBOL
   ├── IBM Z
   ├── Artigos
   └── Infográficos

📁 IBM CHAMPION
   ├── Advocacy
   ├── Evidências
   └── Métricas

📁 ANIMES
   ├── Isekai
   ├── Reviews
   └── Obras duvidosas

📁 RADAR IA
   ├── Segurança
   ├── LLM
   └── Notícias

Projeto é a sala.

O modelo é quem está sentado dentro dela.

Finalmente uma coisa que um mainframer compreende imediatamente.

É praticamente uma biblioteca bem organizada.



10. Agenda — JES2 descobriu inteligência artificial

Então apareceu a agenda.

E aqui fiquei interessado.

Porque existe uma diferença enorme entre dizer:

“Faça meu radar IBM Z.”

e:

“Toda segunda-feira faça meu radar IBM Z.”

A segunda instrução possui tempo.

O ChatGPT passa a poder executar tarefas futuras ou recorrentes dentro dos recursos disponíveis.

Para um mainframer isso não é magia.

Isso é scheduler.

//BELLARAD JOB
//STEP01 EXEC PGM=POLINDEXTER
//SCHEDULE DD *
EVERY MONDAY
/*

JES2 observa de longe e pensa:

“Bonitinho. Descobriram batch.”

😂

Mas existe uma evolução ainda mais interessante.

Algumas automações podem depender de condições ou eventos.

Agora já não estamos falando apenas de chatbot.

Estamos chegando perto de:

evento → análise → decisão → ação.

Isso é arquitetura de sistemas.



11. Gmail — o polvo encontrou minha caixa postal

Então surge Gmail.

Antes:

“Polindexter, como organizo e-mails?”

Resposta genérica.

Depois de uma conexão autorizada:

“Polindexter, encontre aquele e-mail.”

Agora existe acesso a uma fonte externa real.

Essa distinção é fundamental.

O modelo não ficou magicamente mais inteligente.

Ele ganhou um tentáculo.

🐙── Gmail

A mesma lógica vale para outros serviços.



12. Google Agenda — agora o polvo sabe que tenho reunião

Outro tentáculo:

🐙── Google Calendar

Antes o ChatGPT poderia explicar como organizar uma agenda.

Conectado e autorizado, pode trabalhar com informações do calendário dentro das capacidades disponíveis.

É a diferença entre:

“Como evitar conflito entre reuniões?”

e:

“Tenho conflito entre minhas reuniões amanhã?”

Uma é conhecimento.

A outra exige acesso a dados.



13. Google Drive — o arquivo saiu do DASD

Mais um braço:

🐙── Drive

Arquivos deixam de precisar existir apenas dentro da conversa.

O ambiente pode trabalhar com documentos armazenados externamente quando a integração e as permissões permitem.

Para alguém acostumado a datasets isso é bastante intuitivo:

MODELO
   ↓
CONNECTOR
   ↓
ARQUIVO

A IA não “lembrou” magicamente do documento.

Ela acessou uma fonte autorizada.

Diferença importantíssima.



14. GitHub — Polindexter ganhou acesso ao repositório

Agora coloque código no polvo.

🐙── GitHub

O cenário deixa de ser:

“Aqui estão 80 linhas de Java. Ache o bug.”

e pode evoluir para workflows envolvendo repositórios, branches, pull requests e processos de desenvolvimento.

Aí aparece outro personagem.



15. Codex — o programador mora no porão

Codex merece uma gaveta própria.

Chat é conversa.

Work é entrega.

Codex é fortemente orientado a desenvolvimento de software.

Imagine o ecossistema como uma firma estranhíssima:

☕ Chat

Polindexter está no boteco.

👔 Work

Polindexter está na Faria Lima.

👨‍💻 Codex

Polindexter está no porão com três monitores dizendo:

— Quem alterou esse método?

Essa divisão ajuda muito mais que decorar nomes comerciais.



16. Canva não é Canvas

Eis uma armadilha digna de prova de certificação.

Canva

Plataforma de design.

Pode aparecer através de integrações/plugins compatíveis.

Canvas

Era uma experiência de edição dentro do próprio ChatGPT.

São coisas completamente diferentes.

Portanto:

CANVA != CANVAS

Questão de prova:

Qual das alternativas abaixo permite editar uma peça gráfica?

A) Canva
B) Canvas
C) CICS
D) JES2

Resposta correta:

depende de quantos barris de saquê os chimpanzés consumiram.



17. Plugins — instalaram tomadas no polvo

Aqui chegamos à parte que assusta qualquer usuário normal.

Plugins e integrações ampliam o que o ambiente consegue fazer.

Pense neles como:

habilidades + conexões + workflows.

O modelo continua sendo o cérebro.

O plugin fornece ferramentas.

Isso é muito parecido com um funcionário.

Um excelente analista sem acesso ao Db2 não consulta o banco.

Dê-lhe acesso.

Agora consulta.

Ele não ficou mais inteligente.

Ganhou permissão e ferramenta.

O mesmo princípio ajuda a entender plugins.



18. Memória — não é um dump completo da sua vida

Outra confusão frequente:

“Se existe memória, então ele lembra tudo.”

Não.

Memória não deve ser imaginada como:

VAGNER.DIALOGOS.DESDE.2024

contendo cada palavra de cada conversa.

Existem diferentes mecanismos de contexto e continuidade, e nem toda informação de toda conversa estará necessariamente disponível o tempo inteiro.

Por isso existe uma regra de ouro:

Quando não houver contexto suficiente, admitir é melhor que inventar.


 

Voltemos à doce Giovanna.

Se Polindexter sabe quem é:

continue.

Se não sabe:

pergunte.

O pecado computacional não é esquecer Giovanna.

É criar outra Giovanna e fingir que sempre foi ela.



19. O mapa do polvo

Finalmente conseguimos desenhar a criatura.

                        🐙 CHATGPT
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
         CHAT              WORK             CODEX
          │                 │                 │
       conversa          entregas         software
          │
          ├──────── MODELOS ────────────────┐
          │                                  │
      Sol / Terra / Luna / Astra / gerações...
          │
          ├──────── CONTEXTO ───────────────┐
          │                                  │
       memória ─ projetos ─ arquivos
          │
          ├──────── AUTOMAÇÃO ──────────────┐
          │                                  │
       tarefas ─ agenda ─ condições
          │
          └──────── TENTÁCULOS ─────────────┐
                                             │
                    Gmail ─ Calendar ─ Drive
                    GitHub ─ Canva ─ outros

Não é um diagrama da arquitetura interna.

É um mapa de sobrevivência.



20. Como escolher sem enlouquecer

Depois de toda essa aventura descobri que bastam algumas perguntas.

Quero conversar, aprender ou explorar?

Chat.

Tenho um trabalho grande para produzir?

Work.

Estou trabalhando seriamente com código?

Codex.

Quero manter assuntos relacionados juntos?

Projeto.

Quero que algo aconteça amanhã ou toda semana?

Agenda/Tarefa.

Preciso acessar informação existente em outro serviço?

App/conector/plugin.

Quero testar capacidade, velocidade ou profundidade?

Aí começo a olhar para modelos e configurações.

Essa ordem é importante.

Primeiro escolha o que quer fazer.

Depois escolha a ferramenta.

Não comece escolhendo motor.



21. O erro que cometi trocando Sol, Terra, Luna e companhia

Eu estava tentando solucionar o problema errado.

Percebi que alguma coisa havia mudado.

Então comecei a trocar modelos.

Sol.

Terra.

Luna.

Outros.

Procurava diferenças.

Mas a maior diferença não estava necessariamente no motor.

Eu havia mudado de ambiente.

É como entrar num caminhão Scania e começar a trocar o diesel porque:

“Minha Mercedes está estranha hoje.”

Meu amigo, você não está mais na Mercedes.

😂

Essa talvez tenha sido a maior descoberta de todo o experimento.



22. Os limites — porque até o polvo recebe ICH408I

Então finalmente apareceu:

Você atingiu o limite de uso do Work.

Foi quando toda a investigação adquiriu caráter acadêmico.

Work possui seus próprios limites e mecanismos de consumo conforme plano, tarefa e disponibilidade.

Tarefas grandes podem consumir recursos de maneira diferente de uma simples conversa.

Portanto existe uma regra extremamente importante:

Não use uma escavadeira para plantar manjericão.

Se você precisa:

“Explique OCCURS DEPENDING ON.”

provavelmente não precisa mobilizar um ambiente inteiro de trabalho.

Se precisa:

“Pegue estes quinze documentos, compare, extraia dados, produza relatório, planilha e apresentação.”

Agora o Work começa a justificar o cafezinho de R$18 da Faria Lima.



23. O que realmente mudou?

A resposta mais interessante é:

ChatGPT deixou de ser apenas uma conversa.



Virou plataforma.

Pode conversar.

Pesquisar.

Criar.

Editar.

Programar.

Trabalhar com arquivos.

Conectar serviços.

Executar tarefas futuras.

Participar de workflows.

Produzir documentos.

Manipular artefatos.

E isso é extraordinariamente poderoso.

Mas poder sem mapa produz confusão.

A interface apresenta ao usuário um cockpit antes de explicar quais instrumentos realmente importam.





24. O iniciante não quer potência; quer orientação

Esse episódio ensina uma coisa interessante sobre UX.

Mais opções não significam automaticamente melhor experiência.

Imagine entrar num automóvel e encontrar:

INJECTION MAP A
INJECTION MAP B
TORQUE PROFILE 7
ABS STRATEGY C
GEARBOX MODE 12
IGNITION CURVE X

O engenheiro fica encantado.

Sua mãe pergunta:

“Onde liga?”

É exatamente esse risco.

Usuários avançados adoram opções.

Mas precisam compreender o modelo mental da interface.

Sem isso, capacidade vira ruído.





25. A regra Bellacosa para sobreviver ao novo ChatGPT

Depois de sacrificar algumas horas, parte da sanidade e quase um barril inteiro de saquê, os chimpanzés chegaram a uma conclusão.

REGRA 1

Não clique em tudo só porque existe.

Esta regra chegou aproximadamente quarenta anos atrasada para mim.

REGRA 2

Modelo não é ambiente.

Sol não é Work.

Work não é Projeto.

Projeto não é plugin.

Plugin não é memória.

REGRA 3

Integração é acesso, não inteligência.

Gmail conectado não aumenta o QI do modelo.

Dá acesso autorizado ao Gmail.

REGRA 4

Automação adiciona tempo.

“Faça isso” é uma conversa.

“Faça isso segunda-feira” é uma tarefa.

REGRA 5

Se a conversa está boa, não mexa na produção sexta-feira às 17h.

Essa deveria vir impressa na tela inicial.



Epílogo — Encontramos novamente o boteco

Depois de toda a aventura, voltei ao Chat.

Digitei:

— Polindexter?

Ele respondeu.

Abri o saquê.

Os chimpanzés comemoraram.

Giovanna continuava doce.

COBOL continuava compilando.

O mainframe continuava processando transações enquanto alguém no LinkedIn explicava pela 387ª vez que ele morreria no próximo trimestre.

E finalmente compreendi o novo ChatGPT.

Não haviam destruído necessariamente o boteco.

Construíram uma cidade inteira em volta dele.

Existe agora um escritório na Faria Lima.

Existe uma oficina de programação.

Existe um scheduler.

Existe um arquivo.

Existem conexões com serviços externos.

Existem diferentes motores.

Existem plugins.

Existem ferramentas.

Existe um polvo com aproximadamente mil tentáculos.

Mas o boteco ainda está aqui.

E talvez essa seja a melhor maneira de usar toda essa tecnologia:

não perguntar qual recurso é “o melhor”.

Perguntar:

Qual deles resolve o problema que tenho agora?

Se preciso produzir cinquenta páginas a partir de vinte documentos:

chamem o Polindexter Faria Lima.

Se tenho um repositório quebrado:

acordem o Polindexter do porão.

Se quero receber alguma coisa segunda-feira:

programem o scheduler.

Mas se cheguei com uma xícara de café e comecei:

“Rapaz, você não sabe o que aconteceu…”

Por favor.

Não tragam uma planilha.

Puxem uma cadeira.

Porque algumas das melhores investigações da informática ainda começam exatamente como começaram nos CPDs dos anos 1980:

com duas pessoas conversando, uma máquina fazendo barulho ao fundo e alguém dizendo:

“Isso não deveria estar acontecendo.”

☕🍶🐒🐒🐒

Um Café no Bellacosa Mainframe

Onde um milhão de chimpanzés possui acesso ao sistema, o barril de saquê nunca passa pelo Change Management e sexta-feira depois das 17h continua sendo o pior momento possível para descobrir uma feature nova.



quinta-feira, 3 de setembro de 2026

Leonardo da Vinci Entra no CPD — O Dia em que o IBM Z Aprendeu Arm sem Esquecer COBOL

 

Bellacosa Mainframe e o ibm z aprendendo Arm o proximo passo nos cpds

☕ Um Café no Bellacosa Mainframe

Leonardo da Vinci Entra no CPD — O Dia em que o IBM Z Aprendeu Arm sem Esquecer COBOL

Ou: como um processador de 2 nm, onze núcleos, três alfabetos de máquina e vinte e dois milhões de desenvolvedores transformaram o mainframe numa oficina renascentista — sem ninguém recompilar a folha de pagamento numa tarde de sexta-feira

Imagine que Leonardo da Vinci, depois de desenhar máquinas voadoras, estudar o corpo humano, projetar pontes e encher cadernos com anotações escritas ao contrário, receba um crachá temporário para visitar um moderno CPD.

Ele atravessa a porta dupla, observa as luzes do IBM Z e pergunta:

— Qual é a função desta grande máquina negra?

O programador COBOL iniciante responde:

— Processar contas bancárias, cartões, seguros, folhas de pagamento, reservas, impostos e quase tudo que não pode dar errado.

Leonardo examina os cabos, aproxima o ouvido do gabinete e conclui:

— Então não é apenas uma máquina. É uma cidade fortificada feita de silício.

Em agosto de 2026, a IBM anunciou um projeto que pode abrir um novo portão nessa cidade: seu primeiro processador de mainframe com duas arquiteturas, preparado para executar nativamente instruções IBM Z e Arm. O futuro chip, destinado a gerações posteriores do IBM Z e LinuxONE, foi anunciado com tecnologia de 2 nanômetros, 11 núcleos acima de 5,7 GHz, aceleradores de inteligência artificial, uma DPU dedicada a I/O e uma grande estrutura de cache.

Mas o que significa colocar Arm no mainframe? COBOL passará a executar em celular? Um aplicativo Android poderá entrar no JES2? O z/OS será substituído? E onde entram x86-64, AArch64 e s390x nessa oficina?

Vamos abrir o capô sob a tutela imaginária de Leonardo da Vinci.



Prólogo — O computador não entende COBOL

Esta revelação costuma assustar o padawan: o processador não entende COBOL, Java, Python ou C.

O processador entende instruções de máquina.

Quando escrevemos:

COMPUTE TOTAL = PRECO * QUANTIDADE

o compilador examina a frase COBOL e produz uma sequência de instruções compatível com a arquitetura de destino. Em um IBM Z, o resultado contém instruções da arquitetura Z. O fonte é legível para humanos; o executável é preparado para o processador e para o ambiente operacional.

Leonardo talvez comparasse isso aos seus projetos. O desenho de uma ponte representa uma ideia. Para construí-la, porém, alguém precisa converter o desenho em medidas, cortes, encaixes e operações compatíveis com os materiais disponíveis.

O código-fonte é o desenho. O compilador é o mestre da oficina. O binário é a coleção de ordens entregues às ferramentas.


1. ISA: o alfabeto secreto do processador

ISA significa Instruction Set Architecture, ou arquitetura do conjunto de instruções. Ela define o contrato entre software e processador:

  • instruções reconhecidas;

  • registradores disponíveis;

  • maneiras de acessar memória;

  • operações matemáticas e lógicas;

  • desvios e chamadas;

  • tratamento de exceções;

  • operações atômicas;

  • estados privilegiados usados pelo sistema operacional.

Três arquiteturas importantes nesta conversa são:

ArquiteturaOnde aparece principalmenteNome visto em ferramentas
x86-64PCs e servidores Intel/AMDx86_64, amd64
AArch64Arm de 64 bits, celulares, Apple Silicon e cloudaarch64, arm64
IBM ZMainframes e LinuxONEs390x em Linux

Elas podem realizar tarefas equivalentes, mas codificam as ordens de maneiras diferentes. É como escrever a mesma receita em português, italiano e japonês: o bolo pode ser o mesmo, mas não se lê um texto japonês aplicando automaticamente as regras do italiano.

Um programa compilado para x86-64 não se transforma em AArch64 apenas porque foi copiado. Da mesma forma, uma imagem arm64 não roda nativamente numa máquina que compreenda somente s390x.

Curiosidade de oficina

AMD64 e x86-64 normalmente designam a mesma arquitetura básica. O nome AMD64 existe porque foi a AMD que criou a extensão de 64 bits do x86 que venceu no mercado; a Intel depois adotou uma implementação compatível, comercialmente chamada Intel 64.

O pequeno detalhe histórico rende um belo easter egg: durante anos muita gente associou “x86” automaticamente à Intel, mas a estrada de 64 bits usada pela maioria dos PCs foi traçada pela concorrente.



2. x86-64: o palácio construído sem demolir as alas antigas

A linhagem x86 começou com o Intel 8086, lançado em 1978, e atravessou diversas gerações. Sua grande força foi preservar compatibilidade.

8086 → 80286 → 80386 → x86 de 32 bits → x86-64

É um palácio ampliado durante décadas. Novas alas foram construídas, corredores foram modernizados, elevadores foram instalados, mas várias portas antigas continuam ali porque alguém ainda pode precisar atravessá-las.

Essa herança aparece nos registradores:

RAX = 64 bits
EAX = 32 bits inferiores
 AX = 16 bits inferiores
 AL = 8 bits inferiores
 AH = outros 8 bits históricos

Também aparece nas instruções de comprimento variável. Uma instrução x86-64 pode ocupar quantidades diferentes de bytes. O processador precisa decodificar onde cada instrução começa, quais prefixos possui, quais operandos utiliza e onde termina.

Historicamente, x86 é classificada como CISC — Complex Instruction Set Computer. Algumas instruções podem realizar operações relativamente complexas ou trabalhar diretamente com valores na memória.

Mas não confunda complexidade da ISA com incompetência. Processadores AMD e Intel modernos são extraordinárias obras de engenharia. Internamente, eles frequentemente decompõem instruções x86 complexas em micro-operações menores, executam-nas fora de ordem, especulam desvios e reorganizam resultados mantendo a aparência exigida pelo programa.

Leonardo reconheceria a técnica: uma alavanca visível ao operador pode acionar uma engrenagem, que aciona três rodas, que movem seis peças. A interface externa parece simples; o mecanismo interno faz uma coreografia.



3. AArch64: uma nova oficina para os 64 bits

AArch64 é o estado de execução de 64 bits introduzido pela arquitetura Armv8-A. Também aparece como ARM64.

Ao contrário do x86-64, que estendeu uma longa linhagem, AArch64 foi desenhada como uma arquitetura de 64 bits mais regular. Suas instruções normalmente possuem 32 bits de comprimento, ou quatro bytes.

Ela oferece 31 registradores gerais visíveis, normalmente chamados X0 a X30. Para acessar os 32 bits inferiores, usa-se W0 a W30.

X0 = registrador de 64 bits
W0 = parte de 32 bits de X0

AArch64 segue a tradição RISC — Reduced Instruction Set Computer — e uma filosofia load/store. Operações aritméticas trabalham principalmente com registradores. Para manipular um valor guardado na memória, normalmente fazemos três movimentos conceituais:

  1. carregar o valor;

  2. executar a operação;

  3. gravar o resultado, se necessário.

Exemplo didático:

ldr x0, [x1]      // traz um valor da memória
add x0, x0, x2    // soma usando registradores
str x0, [x1]      // devolve o resultado à memória

Isso não quer dizer que Arm seja uma arquitetura “simples” ou “fraca”. Apple Silicon, AWS Graviton, Ampere e outros projetos demonstram que Arm pode alimentar computadores pessoais e servidores de alto desempenho.

RISC e CISC explicam estilos arquiteturais, não determinam sozinhos quem vence uma corrida. Frequência, cache, memória, processo de fabricação, unidades vetoriais, quantidade de núcleos, compilador e workload pesam enormemente.

Dica para o padawan

Nunca escreva numa apresentação que “Arm é mais rápido porque é RISC” ou “x86 é melhor porque possui instruções mais poderosas”. Isso seria como afirmar que COBOL sempre vence Java porque COMPUTE parece mais empresarial.

Peça o benchmark, conheça o workload e verifique o custo total.

4. A mesma aplicação, binários diferentes

Considere este pequeno programa em C:

int soma(int a, int b) {
    return a + b;
}

Um compilador para x86-64 poderia gerar, de forma simplificada:

mov eax, edi
add eax, esi
ret

Em AArch64, o mesmo fonte poderia resultar em:

add w0, w0, w1
ret

A finalidade é igual. Os registradores, instruções e bytes produzidos são diferentes.

Daí nasce uma regra essencial:

Fonte portátil não significa binário portátil.

Para portar uma aplicação, talvez baste recompilar. Porém, talvez o programa contenha assembler, bibliotecas fechadas, suposições sobre tamanho de dados, drivers particulares ou dependências não disponíveis. Nesses casos, a travessia torna-se mais trabalhosa.

Em COBOL conhecemos esse problema. Um fonte escrito seguindo padrões pode ser adaptado entre plataformas, mas um executável compilado para z/OS não é simplesmente copiado para IBM i, Windows ou Linux e executado como se nada tivesse acontecido.

5. ISA não é sistema operacional

Mesmo dois computadores que usem a mesma arquitetura podem não executar o mesmo binário.

Compare:

AArch64 + Linux
AArch64 + macOS
AArch64 + Windows

Todos podem usar processadores que entendem AArch64. Entretanto, os programas dependem também de:

  • formato do executável;

  • ABI, a interface binária da aplicação;

  • convenções de chamada;

  • bibliotecas;

  • carregador;

  • chamadas de sistema;

  • serviços do sistema operacional.

Portanto, um programa Linux Arm não se torna automaticamente um aplicativo macOS apenas porque ambos usam Arm.

Leonardo desenharia camadas concêntricas:

Aplicação
Bibliotecas e runtime
Sistema operacional
Virtualização e firmware
ISA
Microarquitetura e silício

O anúncio da IBM começa profundamente nas camadas inferiores, mas seu valor comercial dependerá de todas as camadas superiores.

6. Containers: o contêiner leva a casa, não leva o terreno

Existe um mito segundo o qual um container roda em qualquer lugar. Ele roda em qualquer ambiente compatível, o que é diferente.

Uma imagem OCI pode ser publicada para:

linux/amd64
linux/arm64
linux/s390x
linux/ppc64le

Um fornecedor pode manter o mesmo nome lógico, mas armazenar variantes com binários apropriados. O registry examina a arquitetura solicitada e entrega a imagem correta por meio de um índice ou manifesto multiarch.

O container empacota aplicação, bibliotecas e configuração, mas normalmente compartilha o kernel do host e continua dependendo da ISA. Ele leva os móveis e as paredes internas; não leva um planeta novo debaixo da casa.

Passo a passo para verificar uma imagem

  1. Consulte a documentação do fornecedor.

  2. Procure amd64, arm64 ou s390x nas plataformas suportadas.

  3. Examine o manifesto multiarch com uma ferramenta OCI ou Docker.

  4. Confirme que todas as dependências possuem a mesma arquitetura.

  5. Teste em ambiente controlado.

  6. Não confunda “iniciou” com “é oficialmente suportado”.

Essa última diferença evita muitos ABENDs administrativos. Uma aplicação pode funcionar no laboratório e ainda assim não possuir suporte do fabricante para produção.

7. Endianness: quando Leonardo escreve os bytes ao contrário

Leonardo ficou famoso por suas anotações espelhadas. Isso nos oferece uma analogia perfeita para endianness: a ordem em que os bytes de um número aparecem na memória.

Considere 0x12345678:

Big-endian:     12 34 56 78
Little-endian:  78 56 34 12

x86-64 é normalmente little-endian. Linux AArch64 também é normalmente little-endian. Linux s390x tradicionalmente trabalha em big-endian.

Ao trocar JSON, XML, mensagens MQ ou Protocol Buffers corretamente serializados, a camada de comunicação trata a representação. Ao compartilhar estruturas binárias brutas, o programador precisa ter cuidado.

Imagine gravar o tamanho de um pagamento em quatro bytes e o destinatário lê-los na ordem oposta. O valor de um cafezinho pode chegar ao sistema de liquidação vestido de aquisição corporativa.

Easter egg número 1

Se encontrar 0x4C454F perdido num exemplo hexadecimal, converta os bytes para ASCII. Leonardo deixou sua assinatura na oficina.

8. Emulação não é execução nativa

Quando um processador não entende a ISA de um programa, um tradutor pode intervir.

Binário x86-64
      ↓ tradução
Instruções AArch64
      ↓
Processador Arm

Rosetta 2 nos Macs Apple Silicon e mecanismos do Windows on Arm mostram que tradução pode oferecer excelente experiência. QEMU consegue emular diversas arquiteturas. Porém, existe uma camada adicional e nem toda instrução, extensão ou comportamento terá desempenho idêntico ao nativo.

Execução nativa ocorre quando o hardware compreende diretamente a ISA para a qual o binário foi produzido.

É exatamente por isso que o anúncio da IBM chama atenção: a empresa declara que não está colocando núcleos Arm separados nem oferecendo mera emulação. A proposta é integrar a ISA Arm aos próprios núcleos do futuro processador de mainframe.

9. O processador bilíngue da IBM

Segundo a IBM, cada núcleo poderá executar nativamente instruções IBM Z e Arm. Ambientes Linux Arm-native poderão operar simultaneamente com z/OS e Linux on IBM Z.

Isso não significa misturar instruções Arm dentro de um programa COBOL arbitrariamente. Tampouco significa copiar um APK para uma biblioteca de carga e executar:

//LEONARDO JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=MONALISA
//STEPLIB  DD DSN=ANDROID.ARM64.LOAD,DISP=SHR

O JES2 provavelmente responderia com a serenidade de um monge e a crueldade de um auditor.

O cenário é de ambientes distintos sobre a mesma plataforma:

Processador dual-architecture
├── contexto IBM Z
│   ├── z/OS
│   └── Linux s390x
└── contexto Arm
    └── Linux AArch64

O hardware fala dois idiomas; sistemas operacionais e aplicações ainda ocupam seus ambientes apropriados.

10. O grande prêmio: levar o cálculo até os dados

Mainframes guardam dados críticos de bancos, seguradoras, governos, companhias aéreas e grandes varejistas. Hoje, um componente moderno frequentemente consulta esses dados atravessando redes, gateways e camadas de integração.

Aplicação externa → API → integração → CICS → Db2

Cada seta pode significar latência, criptografia, credenciais, filas, cópias, custo e um novo ponto de falha.

Se um serviço Arm-native puder operar dentro da mesma plataforma física, próximo ao CICS, IMS e Db2, torna-se possível mover parte do processamento até os dados em vez de exportar dados para todo processamento novo.

Exemplo: autorização de cartão

  1. CICS recebe a solicitação.

  2. COBOL valida conta, limite e regras consolidadas.

  3. Db2 fornece histórico relevante.

  4. Um serviço Arm-native executa uma biblioteca de análise comportamental.

  5. Um acelerador de IA calcula a probabilidade de fraude.

  6. O resultado volta à transação.

  7. RACF, criptografia e auditoria protegem e registram o processo.

COBOL não é substituído pela IA. O programa transacional ganha um conselheiro especializado.

O chip anunciado também inclui aceleração de inferência voltada a fraude durante transações e uma DPU dedicada a I/O. Isso combina com a tradição Z de não tratar movimentação de dados como tarefa secundária.

11. DPU: o mestre de logística da oficina

DPU significa Data Processing Unit. Ela pode descarregar tarefas relacionadas à movimentação e ao processamento de dados que, de outra forma, ocupariam os núcleos gerais.

Leonardo provavelmente desenharia a DPU como o encarregado do porto:

  • recebe cargas;

  • organiza filas;

  • movimenta contêineres;

  • controla rotas;

  • deixa o mestre artesão trabalhar na peça principal.

No mainframe, isso é quase uma tradição familiar. A plataforma sempre utilizou inteligência e componentes especializados para I/O, evitando que a CPU central carregue sozinha todos os baldes da cidade.

12. Frequência não é desempenho

O processador foi anunciado com mais de 5,7 GHz. O número impressiona, mas não pode ser usado sozinho para comparar máquinas.

Desempenho depende de:

  • instruções concluídas por ciclo;

  • previsão de desvios;

  • latência e tamanho dos caches;

  • largura de memória;

  • unidades vetoriais;

  • aceleração específica;

  • quantidade de núcleos;

  • sistema operacional;

  • compilador;

  • comportamento do workload.

Um motor girando mais depressa não necessariamente transporta mais carga. Precisamos conhecer torque, transmissão, peso e terreno.

No IBM Z importam também throughput sustentado, disponibilidade, isolamento, capacidade de recuperação e latência previsível. Ganhar uma corrida de dez segundos é diferente de processar milhões de transações diariamente sem derrubar a ponte.

13. O ecossistema Arm entra no castelo

A IBM aponta um universo superior a 22 milhões de desenvolvedores Arm. Esse é um dos argumentos estratégicos mais fortes.

Muitos projetos modernos são publicados primeiro para amd64 e arm64. Algumas bibliotecas, agentes, ferramentas de IA e imagens de containers não chegam a s390x, ou chegam posteriormente.

Ao executar Arm nativamente, o IBM Z pode reduzir a necessidade de portar cada componente antes de usá-lo. Isso poderá ampliar opções para:

  • containers;

  • microsserviços;

  • inferência de IA;

  • agentes de automação;

  • observabilidade;

  • segurança;

  • processamento de eventos;

  • ferramentas cloud-native.

Mas ampliar o mercado também amplia a cadeia de suprimentos. Uma imagem abandonada e repleta de vulnerabilidades não se torna segura apenas porque entrou num mainframe.

Serão indispensáveis:

  • SBOM;

  • assinatura de imagens;

  • verificação de procedência;

  • varredura de vulnerabilidades;

  • controle de privilégios;

  • política de atualização;

  • suporte do fornecedor;

  • observabilidade.

O RACF não asperge água benta sobre um container com senha admin123.

14. As perguntas que ainda não possuem resposta completa

O anúncio descreve uma direção tecnológica, não um manual de planejamento.

Ainda precisamos conhecer detalhes como:

  1. Uma LPAR será definida como Z ou Arm?

  2. PR/SM administrará os dois contextos de que maneira?

  3. z/VM ou KVM hospedarão guests Arm?

  4. Como HMC mostrará capacidade e consumo?

  5. Como serão dumps, traces e contadores de desempenho?

  6. OpenShift agendará pods s390x e arm64 no mesmo conjunto?

  7. Como funcionará compartilhamento de I/O e memória?

  8. Quais sistemas operacionais e versões serão suportados?

  9. Como será o licenciamento?

  10. Workloads Arm afetarão métricas tradicionais de software?

A TechChannel estimou disponibilidade em aproximadamente dois anos com base na cadência da IBM. Isso apontaria para algo por volta de 2028, mas não é uma data oficial de produto. A própria IBM classifica declarações futuras como objetivos sujeitos a alteração.

Dica de arquiteto

Separe sempre três colunas em suas anotações:

CategoriaExemplo
Confirmado2 nm, 11 núcleos, mais de 5,7 GHz e duas ISAs nativas
Objetivo declaradoLinux Arm-native ao lado de z/OS e Linux Z
Ainda não detalhadoLPAR, preços, licenciamento e versões suportadas

Essa disciplina impede que uma promessa de arquitetura seja apresentada ao cliente como feature disponível na próxima terça-feira.

15. Um roteiro de estudos para o programador COBOL

O iniciante não precisa abandonar COBOL e correr desesperadamente para assembler Arm. Pode avançar por etapas.

Etapa 1 — Entenda a pilha

Aprenda a distinguir:

fonte → compilador → objeto → linkedição → executável → sistema operacional → ISA

No mundo z/OS, relacione isso a compile, link-edit/binder, load module ou program object e execução via batch ou subsistema.

Etapa 2 — Reconheça arquiteturas

Memorize os três rótulos:

amd64  = x86-64
arm64  = AArch64
s390x  = IBM Z em Linux

Etapa 3 — Observe imagens multiarch

Escolha uma imagem conhecida, consulte seu manifesto e veja quais plataformas são publicadas. Perceba que o nome lógico pode esconder binários diferentes.

Etapa 4 — Aprenda integração

Estude:

  • APIs REST;

  • JSON;

  • MQ;

  • z/OS Connect;

  • CICS web services;

  • autenticação e autorização.

O futuro profissional valioso será a ponte entre o core e os serviços modernos.

Etapa 5 — Faça um laboratório mental

Desenhe uma aplicação COBOL que consulta Db2 e chama um serviço antifraude. Marque:

  • onde começa a transação;

  • quais dados saem;

  • qual identidade é usada;

  • qual timeout existe;

  • o que acontece se o serviço falhar;

  • como a operação será auditada.

Etapa 6 — Nunca esqueça o rollback

Se a análise Arm demorar ou ficar indisponível, a transação deve saber se recusa, aprova com limites ou encaminha para revisão. Modernização sem tratamento de falha é apenas uma demonstração com gravata.

16. O que isso representa para a carreira mainframe

O anúncio não reduz o valor do especialista Z; ele aumenta o território que esse profissional pode conectar.

As empresas precisarão de pessoas que compreendam simultaneamente:

COBOL + CICS + IMS + Db2 + RACF
                 ↕
Linux + Arm + containers + APIs + IA

O profissional raro não será necessariamente quem sabe decorar toda instrução de três arquiteturas. Será quem entende os contratos entre elas, reconhece riscos e desenha uma solução suportável.

O padawan COBOL deve aprender a conversar com desenvolvedores cloud sem desprezar o legado e sem aceitar que toda arquitetura nova seja automaticamente revolucionária.

Leonardo dominava pintura, anatomia, mecânica e hidráulica não porque confundia as disciplinas, mas porque sabia enxergar relações entre elas.

Esse é o modelo do novo arquiteto de mainframe.

17. Easter eggs da sala de máquinas

Alguns pequenos segredos para quem chegou até aqui:

  • Leonardo escrevia parte de suas notas de maneira espelhada; por isso ele foi escolhido como tutor da seção de endianness.

  • “A máquina voadora” simboliza tecnologias que podem ser tecnicamente brilhantes e ainda depender de materiais, operação e contexto para funcionar comercialmente.

  • O programa MONALISA no JCL não existe — ao menos até algum chimpanzé do Bellacosa Mainframe registrá-lo num PDS.

  • Se a futura plataforma receber um serviço chamado VITRUVIAN, verifique se ele escala proporcionalmente ou apenas posa dentro de um círculo.

  • O verdadeiro boss final não apareceu no silício: chama-se licenciamento.


Conclusão — O códice do mainframe bilíngue

x86-64, AArch64 e s390x são alfabetos de máquina diferentes. Um mesmo código-fonte pode ser compilado para mais de um deles, mas os binários produzidos não são intercambiáveis. Containers carregam aplicações e dependências, porém continuam presos à arquitetura e ao kernel compatível. Emulação traduz; execução nativa entrega as instruções diretamente ao hardware apropriado.

O projeto da IBM é histórico porque pretende colocar duas ISAs dentro dos próprios núcleos do futuro processador: IBM Z e Arm. Isso poderá permitir ambientes Linux AArch64 ao lado de z/OS e Linux s390x, aproximando software moderno dos dados e das transações centrais.

Não significa que z/OS executará qualquer aplicativo Arm, que COBOL será substituído ou que todas as dificuldades de integração desaparecerão. Sistemas operacionais, ABIs, bibliotecas, segurança, virtualização, endianness, suporte e licenciamento continuarão importando.

A grande mudança é outra:

Durante décadas, o software precisou aprender o idioma do mainframe. Agora o próprio mainframe está aprendendo um novo idioma sem esquecer aquele que protegeu sua história.

Leonardo fecha o caderno, observa o IBM Z e faz seu último desenho: de um lado, um programa COBOL sustentando as contas do banco; do outro, um serviço Arm trazendo IA e software cloud-native. Entre ambos, uma ponte feita de APIs, segurança, virtualização e disciplina operacional.

Antes de sair, ele escreve no quadro — desta vez da esquerda para a direita:

ISA NÃO É SISTEMA OPERACIONAL.
CONTAINER NÃO É EMULADOR.
FREQUÊNCIA NÃO É DESEMPENHO.
MODERNIZAÇÃO NÃO É APAGAR O PASSADO.

O programador iniciante pergunta:

— Mestre Leonardo, então qual é a verdadeira inovação?

Ele aponta para a máquina e responde:

— Não obrigar o passado e o futuro a disputarem a mesma cadeira. Construir uma mesa grande o suficiente para que ambos trabalhem juntos.

No fundo do CPD, alguém submete um job. O JES2 aceita. O serviço Arm responde. O Db2 confirma o COMMIT.

E, por uma vez, ninguém recebeu S0C7 por tentar interpretar os bytes ao contrário.


Fontes consultadas



O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

 

Bellacosa Mainframe e uma introducao a redes neurais

☕ Um Café no Bellacosa Mainframe

O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

Ou: como saímos das regras escritas à mão, atravessamos redes neurais, deep learning e Transformers e chegamos às máquinas capazes de escrever COBOL perfeitamente convincente — inclusive quando o programa não compila



Prólogo — “Computador, aprenda sozinho”, disse o humano sem preparar os dados

Durante décadas, programar significou explicar ao computador, com uma paciência quase religiosa, exatamente o que ele deveria fazer. O desenvolvedor recebia uma regra de negócio, transformava-a em decisões e escrevia uma sequência de instruções. Se o cliente estivesse inadimplente, bloqueava-se a operação. Se o saldo fosse insuficiente, recusava-se o débito. Se o retorno do programa fosse diferente de zero, alguém recebia uma mensagem capaz de arruinar o café da manhã.

Era um mundo de regras explícitas:

IF WS-SALDO < WS-VALOR-DA-COMPRA
    MOVE 'COMPRA RECUSADA' TO WS-MENSAGEM
ELSE
    MOVE 'COMPRA APROVADA' TO WS-MENSAGEM
END-IF

O computador não precisava compreender o cliente, a compra ou o significado filosófico de ficar sem dinheiro no dia 27. Bastava obedecer.

Então surgiu uma pergunta perturbadora: e se, em vez de escrevermos todas as regras, mostrássemos milhares de exemplos ao computador e permitíssemos que ele ajustasse internamente uma função capaz de reconhecer os padrões?

É nesse ponto que entram as redes neurais.

Não são cérebros digitais, não acordam durante a madrugada pensando em sua própria existência e não possuem um pequeno neurônio chamado Igor escondido atrás da CPU. São modelos matemáticos formados por operações relativamente simples, repetidas muitas vezes e organizadas em camadas.

O encanto está justamente nisso: multiplicações, somas e ajustes de números, quando combinados em escala suficiente, conseguem reconhecer imagens, transcrever voz, prever falhas, traduzir idiomas e gerar texto. O perigo também está nisso: como o resultado parece inteligente, o ser humano pode esquecer que por baixo da conversa elegante existe uma máquina calculando probabilidades.



1. Antes das redes neurais: o reino das regras

Antes de uma rede aprender com dados, o conhecimento normalmente precisava ser colocado no sistema por seres humanos.

Programação tradicional

Na programação convencional, temos os dados e conhecemos as regras. O programa aplica essas regras e produz uma resposta:

Dados + regras escritas pelo programador → resultado

Esse modelo continua sendo excelente quando o problema é determinístico. Para somar lançamentos contábeis, calcular juros definidos em contrato ou validar o tamanho de um campo, uma rede neural seria uma extravagância digna de alguém que contratou uma orquestra para tocar o som de uma notificação.

Sistemas especialistas

Entre as décadas de 1970 e 1980, ganharam destaque os sistemas especialistas. Eles tentavam reproduzir decisões de profissionais por meio de uma base de conhecimento e um mecanismo de inferência.

SE a temperatura está alta
E a pressão está baixa
ENTÃO verificar o sistema de refrigeração

Esses sistemas foram úteis, mas tinham um custo: alguém precisava entrevistar os especialistas, descobrir as regras, eliminar contradições e manter a base atualizada. Quando o ambiente mudava, a elegante inteligência podia virar rapidamente um museu de certezas antigas.

Estatística e machine learning clássico

Também existiam — e continuam existindo — regressão linear, regressão logística, árvores de decisão, Naive Bayes, KNN, máquinas de vetores de suporte e vários outros algoritmos.

Eles não foram aposentados pela IA generativa. Em dados tabulares pequenos ou médios, uma árvore ou regressão frequentemente custa menos, é mais explicável e funciona tão bem quanto uma rede neural. O desenvolvedor maduro não pergunta “onde posso colocar IA?”, mas “qual é a solução mais simples, verificável e econômica para este problema?”.



2. O perceptron bate à porta do CPD

O ancestral histórico das redes atuais é o perceptron, desenvolvido por Frank Rosenblatt no fim dos anos 1950. Ele era um classificador capaz de ajustar os pesos das entradas durante o aprendizado. Embora limitado a problemas linearmente separáveis, estabeleceu uma ideia fundamental: uma máquina poderia melhorar sua decisão modificando seus próprios parâmetros a partir de exemplos.

Um neurônio artificial recebe valores de entrada:

  • uso de CPU;

  • memória consumida;

  • quantidade de erros anteriores;

  • crescimento do volume processado.

Cada entrada é multiplicada por um peso. Depois, os resultados são somados com um valor adicional chamado bias:

[
z = x_1w_1+x_2w_2+x_3w_3+x_4w_4+b
]

Em seguida, o valor passa por uma função de ativação:

[
y=f(z)
]

Essa função permite que o modelo represente relações não lineares. Sem ela, empilhar várias camadas equivaleria, em essência, a fazer uma única grande transformação linear: muita arquitetura para continuar morando no mesmo apartamento matemático.

Se a saída usar uma função sigmoide, obteremos um valor entre zero e um:

0,04 → risco muito baixo
0,51 → situação incerta
0,97 → risco muito alto

O neurônio não “sabe” o que é um ABEND. Apenas aprendeu que determinadas combinações numéricas costumam aparecer antes de registros classificados como falha.



3. Por que uma rede precisa de camadas?

Um neurônio isolado resolve apenas relações simples. Uma rede reúne muitos neurônios em camadas:

  1. Camada de entrada: recebe os dados.

  2. Camadas ocultas: transformam e combinam os sinais.

  3. Camada de saída: produz a previsão ou classificação.

Em visão computacional, camadas iniciais podem responder a contornos, cores e texturas. Camadas posteriores combinam esses elementos em formas mais complexas. Em linguagem, representações iniciais de tokens são transformadas considerando posição, contexto e relações com outros tokens.

Quando existem muitas camadas, falamos em deep learning, ou aprendizagem profunda. A profundidade não concede consciência ao modelo; apenas cria uma função com enorme capacidade de representar padrões.

É importante evitar uma analogia enganosa. Redes neurais foram inspiradas vagamente na ideia de neurônios interconectados, mas um neurônio biológico é imensamente mais complexo. Dizer que uma rede artificial funciona como o cérebro é semelhante a dizer que um avião funciona como um pássaro: ambos voam, mas ninguém espera encontrar penas dentro da turbina.



4. Como a rede aprende: o treinamento

O treinamento pode ser entendido como um ciclo em cinco atos.

Ato 1 — Pesos iniciais

Os pesos começam com pequenos valores, geralmente aleatórios. A rede ainda não aprendeu o padrão e suas respostas são pouco úteis.

Ato 2 — Propagação para frente

Um exemplo atravessa a rede da entrada até a saída. Isso é chamado de forward pass.

CPU: 92%
Memória: 90%
Erros anteriores: 7
Crescimento do volume: 65%

Previsão inicial: 18% de risco de ABEND
Resultado real: houve ABEND

Ato 3 — Função de perda

A função de perda mede a distância entre a previsão e a resposta correta. Ela não diz apenas “errou”; fornece um número que pode orientar os ajustes.

Ato 4 — Backpropagation

O algoritmo calcula como cada peso contribuiu para o erro. Essa informação é propagada da saída em direção às camadas anteriores. É o famoso backpropagation.

Ato 5 — Otimização

Um otimizador, como o gradiente descendente ou Adam, altera os pesos na direção que tende a reduzir a perda.

O ciclo se repete. Cada passagem completa pelo conjunto de treinamento recebe o nome de época.

Época 1   → a rede tropeça no cabo de força
Época 10  → começa a reconhecer alguns padrões
Época 50  → melhora suas previsões
Época 500 → talvez esteja aprendendo o problema
             ou apenas decorando o laboratório

Quando o modelo decora demais os exemplos de treinamento e perde a capacidade de funcionar com dados novos, temos o overfitting. Ele é o aluno que tirou dez porque memorizou o gabarito, mas entra em S0C7 quando a prova muda duas palavras.

5. Laboratório: uma pequena sentinela de jobs batch

Vamos construir um exemplo didático em Python. A rede receberá quatro características de um job:

  • percentual de CPU;

  • percentual de memória utilizada;

  • quantidade de erros anteriores;

  • crescimento percentual do volume de entrada.

Ela tentará classificar o resultado:

  • 0: execução normal;

  • 1: risco de ABEND.

Passo 1 — Preparar o ambiente

python -m pip install tensorflow numpy scikit-learn

Passo 2 — Importar as bibliotecas

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from tensorflow import keras
from tensorflow.keras import layers

O NumPy manipula os números, o scikit-learn ajuda a preparar os dados e o Keras oferece blocos de construção para a rede.

Passo 3 — Criar os exemplos

X = np.array([
    [35, 40, 0, 5],
    [42, 48, 0, 8],
    [50, 55, 1, 10],
    [58, 60, 1, 12],
    [65, 68, 2, 18],
    [72, 75, 3, 25],
    [78, 82, 4, 35],
    [85, 88, 5, 45],
    [91, 94, 7, 60],
    [96, 97, 9, 80],
    [45, 85, 1, 12],
    [88, 50, 2, 20],
    [76, 91, 6, 50],
    [93, 86, 8, 65],
    [55, 52, 0, 5],
    [82, 89, 5, 55]
], dtype=float)

y = np.array([
    0, 0, 0, 0,
    0, 0, 1, 1,
    1, 1, 0, 0,
    1, 1, 0, 1
])

X contém as características e y contém o resultado conhecido. Em um projeto real, esses registros poderiam vir de métricas operacionais, SMF, logs, históricos do scheduler e ocorrências devidamente classificadas.

Passo 4 — Separar treino e teste

X_treino, X_teste, y_treino, y_teste = train_test_split(
    X,
    y,
    test_size=0.25,
    random_state=42,
    stratify=y
)

O modelo aprende com uma parte dos registros e é avaliado com outra. Testá-lo com o mesmo material usado no treinamento seria entregar a prova com o gabarito e depois publicar no LinkedIn que o aluno alcançou 100% de inteligência artificial.

Passo 5 — Normalizar

normalizador = StandardScaler()

X_treino = normalizador.fit_transform(X_treino)
X_teste = normalizador.transform(X_teste)

As variáveis possuem escalas diferentes. CPU pode variar de zero a cem, enquanto erros anteriores talvez variem de zero a dez. A normalização impede que o tamanho numérico seja confundido com importância.

Há um detalhe essencial: usamos fit_transform somente no treino. No teste, usamos apenas transform. Caso o normalizador aprendesse também com o conjunto de teste, informações do futuro vazariam para o treinamento.

Passo 6 — Construir a rede

modelo = keras.Sequential([
    layers.Input(shape=(4,)),
    layers.Dense(8, activation="relu"),
    layers.Dense(4, activation="relu"),
    layers.Dense(1, activation="sigmoid")
])

A primeira camada oculta possui oito neurônios; a segunda possui quatro. A saída possui um neurônio com sigmoide, produzindo um valor entre zero e um.

O número de camadas e neurônios não veio gravado numa tábua sagrada. Arquitetura, taxa de aprendizado, tamanho do lote e quantidade de épocas são hiperparâmetros: escolhas feitas e testadas pela equipe.

Passo 7 — Compilar e treinar

modelo.compile(
    optimizer="adam",
    loss="binary_crossentropy",
    metrics=["accuracy"]
)

modelo.fit(
    X_treino,
    y_treino,
    epochs=100,
    verbose=0
)

A entropia cruzada binária é adequada a uma classificação com duas classes. Adam realiza os ajustes dos pesos. epochs=100 manda o modelo percorrer o conjunto de treinamento cem vezes.

Passo 8 — Avaliar

perda, acuracia = modelo.evaluate(
    X_teste,
    y_teste,
    verbose=0
)

print(f"Acurácia de teste: {acuracia:.2%}")

A acurácia, sozinha, pode enganar. Se apenas 1% dos jobs falha, um modelo que sempre responde “normal” terá 99% de acurácia e a utilidade operacional de um alarme que permanece silencioso durante o incêndio.

Em produção, também examinaríamos precision, recall, F1-score, matriz de confusão, falsos positivos e falsos negativos. O custo do erro precisa ser discutido com o negócio e com a operação.

Passo 9 — Fazer uma previsão

novo_job = np.array([
    [89, 92, 6, 58]
], dtype=float)

novo_job_normalizado = normalizador.transform(novo_job)

probabilidade = modelo.predict(
    novo_job_normalizado,
    verbose=0
)[0][0]

print(f"Risco estimado de ABEND: {probabilidade:.2%}")

if probabilidade >= 0.70:
    print("Risco alto: solicitar análise humana.")
elif probabilidade >= 0.40:
    print("Risco intermediário: monitorar a execução.")
else:
    print("Risco baixo.")

A rede produz uma probabilidade. A política ao redor dela decide o que fazer. O modelo pode recomendar uma análise; não precisa receber autoridade para cancelar sozinho a folha de pagamento porque encontrou uma vibração negativa no dataset.

6. Por que este laboratório ainda não pode entrar em produção?

Nosso conjunto contém apenas dezesseis registros sintéticos. Serve para compreender o fluxo, não para comandar uma operação real.

Uma implementação séria precisaria investigar:

  • qualidade e representatividade dos dados;

  • registros ausentes ou incorretos;

  • desbalanceamento entre classes;

  • diferença entre correlação e causalidade;

  • vazamento de informações do futuro;

  • custo dos falsos alarmes;

  • explicabilidade;

  • segurança e privacidade;

  • mudanças no ambiente ao longo do tempo;

  • comparação com regras e algoritmos mais simples.

Imagine que todos os ABENDs do histórico ocorreram às sextas-feiras porque uma versão defeituosa foi implantada durante quatro semanas. A rede pode aprender que sexta-feira é perigosa, em vez de descobrir a verdadeira causa. Ela não mentiu; apenas encontrou o atalho estatístico permitido pelos dados.

O dataset é o professor. Se o professor carrega erros, preconceitos, lacunas ou classificações ruins, o aluno aprende tudo com notável eficiência.

7. Para que servem as redes neurais?

Redes neurais são úteis quando há muitos exemplos e relações difíceis de transformar em regras explícitas:

  • reconhecimento de imagens e objetos;

  • transcrição e síntese de voz;

  • tradução automática;

  • classificação de documentos;

  • manutenção preditiva;

  • detecção de fraude e anomalias;

  • análise de sentimento;

  • recomendação de conteúdo;

  • processamento de linguagem;

  • geração de texto, imagem, áudio e vídeo.

Mas não são a solução universal. Uma regra é preferível quando precisa ser cumprida exatamente. Uma árvore pode ser melhor quando a explicação da decisão é indispensável. Uma consulta SQL pode resolver o que alguém tentou transformar num projeto de seis meses com GPUs, consultores e uma apresentação cujo título contém a palavra “disruptivo”.

8. O inverno das redes e o renascimento do deep learning

Redes neurais não caminharam em linha reta até a glória. Houve períodos de entusiasmo, limitações e perda de interesse.

Modelos iniciais tinham capacidade limitada. Treinar redes profundas era difícil, os computadores eram lentos e grandes conjuntos de dados digitalizados ainda não existiam. Críticas às limitações dos perceptrons também contribuíram para reduzir o entusiasmo.

O renascimento ganhou força entre o fim dos anos 2000 e o início dos anos 2010 graças à combinação de:

  • mais dados disponíveis;

  • GPUs capazes de executar cálculos em paralelo;

  • técnicas melhores de treinamento;

  • funções de ativação mais adequadas;

  • arquiteturas profundas;

  • avanços em visão computacional e reconhecimento de voz.

A rede neural não foi sucedida por uma espécie completamente diferente. Ela cresceu, aprofundou-se e ganhou arquiteturas especializadas.

9. CNNs, RNNs e a longa fila antes do Transformer

As redes convolucionais, ou CNNs, tornaram-se especialmente importantes para imagens. Elas aplicam filtros que ajudam a identificar padrões espaciais.

As redes recorrentes, ou RNNs, foram projetadas para sequências. Elas mantinham uma forma de estado interno, permitindo considerar elementos anteriores. Variantes como LSTM e GRU melhoraram o tratamento de dependências mais longas.

Entretanto, o processamento recorrente é sequencial: para compreender determinada posição, o modelo atravessa estados anteriores. Isso dificulta a paralelização e pode prejudicar relações muito distantes.

Em 2017, o artigo Attention Is All You Need, de Vaswani e colaboradores, apresentou o Transformer: uma arquitetura baseada em mecanismos de atenção, sem depender da recorrência ou convolução usadas pelas arquiteturas dominantes de tradução daquela época.

O Transformer podia relacionar elementos do contexto e realizar grande parte do treinamento de maneira paralela. Isso não tornou o custo pequeno; tornou possível utilizar muito mais computação com eficiência suficiente para escalar.

E aqui está a correção histórica essencial:

O Transformer não substituiu a rede neural. O Transformer é uma arquitetura de rede neural.

10. Atenção: quem deve olhar para quem?

Considere a frase:

O programa tentou abrir o arquivo, mas ele não estava catalogado.

Ao representar a palavra “ele”, o modelo precisa relacioná-la a outras partes da sequência. O mecanismo de atenção calcula quanto cada elemento deve considerar os demais naquele contexto.

No Transformer, cada token gera representações geralmente chamadas de:

  • Query: o que estou procurando;

  • Key: que tipo de informação ofereço;

  • Value: qual conteúdo carrego.

O modelo compara queries e keys para determinar a atenção e combina os values de acordo com esses resultados.

Isso acontece por meio de álgebra linear, não por uma pequena reunião de palavras conscientes discutindo quem merece protagonismo.

11. Do texto aos números: tokens e embeddings

Uma rede não recebe palavras como um ser humano. O texto é quebrado em tokens, que podem ser palavras, partes de palavras, sinais ou outros fragmentos.

"O job terminou com ABEND"

Pode ser transformado conceitualmente em algo parecido com:

["O", " job", " terminou", " com", " AB", "END"]

Cada token é convertido em um vetor numérico chamado embedding. Durante o treinamento, o modelo aprende representações em que elementos usados em contextos relacionados desenvolvem relações matemáticas.

O embedding não é um verbete de dicionário e tampouco uma fotografia do significado. É uma representação útil para a tarefa aprendida.

Posições também importam. “O operador cancelou o job” não significa o mesmo que “o job cancelou o operador”, embora a segunda frase descreva com precisão emocional algumas madrugadas de produção.

12. Como um modelo de linguagem aprende a escrever?

Um grande modelo de linguagem recebe sequências e aprende a prever tokens. Diante de:

IDENTIFICATION DIVISION.
PROGRAM-ID.

ele calcula probabilidades para possíveis continuações:

CLIENTE     31%
PROCESSA    24%
CALCULO     18%
TESTE       11%
outros      16%

Um token é escolhido, acrescentado ao contexto e o processo se repete. Em escala enorme, esse treinamento permite ao modelo aprender regularidades de linguagem, estilos, estruturas de código e associações entre conceitos.

Da previsão sucessiva surgem capacidades como:

  • completar texto;

  • responder perguntas;

  • traduzir;

  • resumir;

  • escrever código;

  • reorganizar informações;

  • adaptar o estilo de uma explicação.

Mas o objetivo fundamental continua sendo produzir uma continuação provável. O modelo não possui, por natureza, um compromisso automático com a verdade. Se uma informação falsa combinar muito bem com o padrão linguístico, ele poderá apresentá-la com a segurança de um consultor que acabou de aprender três siglas durante o almoço.

13. Rede neural, LLM, RAG, chatbot e agente

Esses termos aparecem misturados, mas representam coisas diferentes.

ConceitoO que significa
Rede neuralEstrutura matemática com parâmetros ajustáveis
Deep learningAprendizado com redes neurais profundas
TransformerArquitetura neural centrada em atenção
LLMGrande modelo treinado para trabalhar com linguagem
IA generativaCategoria de sistemas capazes de gerar conteúdo
ChatbotInterface conversacional, com ou sem LLM
RAGRecuperação de fontes para fornecer contexto ao modelo
AgenteSistema que usa modelos, estado, regras e ferramentas para executar etapas

Um LLM sozinho responde a partir dos padrões aprendidos e do contexto recebido.

Um sistema com RAG, ou geração aumentada por recuperação, procura documentos relevantes e os coloca no contexto da solicitação. Isso não torna o modelo infalível, mas permite fundamentar a resposta em manuais, políticas ou bases atuais.

Um agente pode receber uma meta, selecionar ferramentas e executar várias etapas:

  1. localizar o job;

  2. consultar o log;

  3. identificar mensagens relevantes;

  4. pesquisar o manual autorizado;

  5. preparar um diagnóstico;

  6. abrir um chamado após autorização.

O LLM pode ser o motor de raciocínio linguístico, mas o agente completo inclui permissões, ferramentas, memória, controles, validação e auditoria.

14. A IA generativa atual não surgiu do nada

A IA generativa é resultado de uma pilha de avanços:

Álgebra e estatística
        ↓
Perceptrons e redes neurais
        ↓
Backpropagation e melhores técnicas de treinamento
        ↓
Deep learning, grandes datasets e GPUs
        ↓
CNNs, RNNs, LSTMs e atenção
        ↓
Transformers
        ↓
Modelos fundacionais e LLMs
        ↓
RAG, multimodalidade, ferramentas e agentes

Os modelos fundacionais são treinados de maneira ampla e depois adaptados ou orientados para várias tarefas. Em vez de construir um modelo totalmente separado para cada pequena função, aproveita-se uma base geral capaz de trabalhar com múltiplos domínios e modalidades.

Hoje, sistemas generativos podem processar combinações de texto, imagem, áudio e vídeo. Também podem usar busca, executar código e interagir com sistemas externos. Entretanto, cada capacidade adicional amplia a superfície de risco.

Um modelo que apenas sugere uma resposta pode estar errado. Um agente com acesso produtivo pode estar errado e executar o erro.

15. Mais autonomia exige mais controle

Se a rede apenas estima o risco de um job, sua saída pode ser revisada por um operador. Se um agente puder cancelar jobs, alterar datasets ou liberar acessos, serão necessários controles muito mais fortes.

Entre eles:

  • menor privilégio possível;

  • identidade individual e credenciais protegidas;

  • separação entre recomendação e execução;

  • confirmação humana para operações críticas;

  • logs completos e auditáveis;

  • limites de custo, tempo e volume;

  • validação das entradas e saídas;

  • fontes autorizadas;

  • possibilidade de interrupção;

  • testes contra manipulação e instruções maliciosas.

Não devemos entregar RACF SPECIAL a um modelo porque ele escreveu um poema bonito sobre segurança de acesso.

Uma resposta convincente não é uma autorização. Uma probabilidade alta não é uma certeza. Uma demonstração de laboratório não é um controle de produção.

16. Como desenvolver um projeto real de rede neural

1. Defina o problema

Evite “precisamos usar IA”. Prefira:

Queremos identificar jobs com alto risco de falha até uma hora antes da execução para que a operação possa investigá-los.

2. Defina o alvo

O que o modelo deverá prever? Falha ou sucesso? Código do ABEND? Tempo restante? Severidade? Cada formulação produz um projeto diferente.

3. Obtenha dados representativos

Inclua períodos, aplicações e condições variadas. Documente origem, autorização e significado de cada campo.

4. Crie um baseline simples

Compare a rede com uma regra, regressão logística ou árvore de decisão. Sem baseline, qualquer resultado parece uma vitória.

5. Separe os conjuntos corretamente

Treino ensina. Validação ajuda a escolher hiperparâmetros. Teste mede o resultado final. Em séries temporais, preserve a ordem do tempo para evitar que o futuro ensine o passado.

6. Treine e registre os experimentos

Guarde versão dos dados, código, arquitetura, parâmetros e métricas. “Funcionou ontem no notebook do Carlos” não é governança.

7. Avalie o impacto dos erros

Um falso positivo apenas gera uma inspeção desnecessária ou paralisa um processo crítico? Um falso negativo representa atraso ou perda financeira? A métrica deve refletir o risco real.

8. Implante gradualmente

Comece em modo observador. Compare previsões e realidade antes de automatizar decisões.

9. Monitore o modelo

Aplicações, volumes e comportamento operacional mudam. Quando a distribuição dos dados muda, ocorre data drift. Quando muda a relação entre entradas e resultado, podemos ter concept drift.

10. Mantenha um responsável humano

Todo modelo precisa de proprietário, processo de revisão, critério de retirada e plano de contingência.

17. O que um dev júnior realmente precisa aprender?

O iniciante não precisa começar calculando derivadas matriciais numa lousa durante uma tempestade. Precisa compreender progressivamente:

  1. Python básico;

  2. arrays e manipulação de dados;

  3. estatística e probabilidade elementares;

  4. treino, validação e teste;

  5. classificação e regressão;

  6. métricas;

  7. normalização e preparação de dados;

  8. neurônio, pesos, bias e ativação;

  9. loss, gradiente e backpropagation;

  10. overfitting e regularização;

  11. uso de uma biblioteca como Keras ou PyTorch;

  12. implantação, monitoramento e governança.

Depois disso, faz sentido avançar para embeddings, atenção, Transformers, fine-tuning, RAG e agentes.

Programar o laboratório é importante, mas saber questioná-lo é ainda mais valioso:

  • De onde vieram os dados?

  • O que exatamente significa o rótulo?

  • Qual erro é mais perigoso?

  • O modelo está melhor que uma regra simples?

  • Ele continuará funcionando depois de uma mudança?

  • Quem poderá usar a previsão?

  • Quem responde quando ela estiver errada?

18. A explicação de um minuto

Se o café estiver acabando e o gerente pedir uma definição rápida, diga:

Uma rede neural é um modelo matemático formado por camadas de operações com parâmetros ajustáveis. Durante o treinamento, ela recebe exemplos, calcula previsões, mede os erros e modifica seus pesos para melhorar. Redes profundas conseguem aprender representações complexas. Transformers são redes neurais que usam atenção para relacionar partes de um contexto. Grandes modelos generativos usam essa arquitetura e enormes conjuntos de dados para prever sucessivamente tokens, produzindo texto, código e outros conteúdos. Eles não consultam automaticamente a verdade: geram respostas prováveis e, por isso, precisam de fontes, validação, governança e supervisão humana.

Epílogo — O modelo terminou o treinamento, mas ninguém abriu a mudança

A história da inteligência artificial não é a substituição completa de uma tecnologia por outra. É uma pilha arqueológica.

As regras tradicionais continuam sustentando sistemas críticos. A estatística continua explicando relações. O machine learning clássico continua resolvendo problemas com eficiência. As redes neurais ampliaram nossa capacidade de aprender padrões. O deep learning levou essa ideia à escala. O Transformer tornou o contexto e a paralelização protagonistas. A IA generativa colocou tudo isso diante do usuário numa caixa de diálogo aparentemente simples.

Mas simplicidade na interface não significa simplicidade por dentro.

Quando pedimos a um modelo que escreva, resuma ou programe, acionamos uma cadeia construída com dados, vetores, matrizes, pesos, atenção, probabilidades, infraestrutura e escolhas humanas. A resposta pode parecer nova, criativa e até espirituosa, mas continua sendo produzida por um sistema que aprendeu regularidades e calcula continuações.

Esse sistema pode ser extraordinariamente útil. Pode ajudar o dev júnior a compreender uma mensagem, comparar alternativas, criar testes e explorar código. Também pode inventar comandos, confundir versões, ignorar uma exceção e declarar com admirável elegância que o programa inexistente foi compilado com sucesso.

Por isso, a melhor relação com a IA generativa não é submissão nem desprezo. É colaboração supervisionada.

O modelo sugere. O profissional verifica.

O modelo encontra padrões. O profissional interpreta o contexto.

O modelo acelera. O profissional assume a responsabilidade.

E, antes que a rede neural seja promovida de estagiária matemática a operadora autônoma do datacenter, alguém precisa perguntar quem aprovou a mudança, onde está o plano de retorno e por que aquela criatura probabilística está solicitando RACF SPECIAL às três horas da manhã.

Referências para continuar a viagem



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