☕ 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

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.


sábado, 5 de setembro de 2026

O Barão de Münchhausen Entra no CPD — Da Estatística à GenAI, sem precisar cavalgar uma bala de canhão

 

Bellacosa Mainframe apresenta Data Analytics

☕ Um Café no Bellacosa Mainframe

O Barão de Münchhausen Entra no CPD — Da Estatística à GenAI, sem precisar cavalgar uma bala de canhão

Ou: como Estatística, Pesquisa Operacional, Tukey, Codd, Data Warehousing, Analytics, Big Data, Data Science, Machine Learning e IA Generativa acabaram encontrando COBOL dentro do IBM Z — e por que o programador que entende os dados tem uma vantagem que nenhum dashboard consegue inventar


Prólogo — O Barão chegou ao CPD montado numa distribuição normal

Conta o Barão de Münchhausen que certa manhã atravessou uma distribuição normal montado numa média aritmética, saltou sobre três outliers, amarrou seu cavalo numa mediana e chegou ao CPD exatamente no momento em que um batch COBOL terminava de processar alguns milhões de transações.

Naturalmente, não devemos acreditar em tudo.

A parte da distribuição normal é discutível.

A parte dos milhões de transações, nem tanto.

Quem trabalha com mainframe convive diariamente com quantidades gigantescas de dados: pagamentos, cartões, seguros, contas bancárias, pedidos, estoques, reservas, faturamento, logística, transações governamentais e inúmeras outras atividades.

Durante décadas aprendemos a fazer esses sistemas funcionarem.

Agora existe uma pergunta adicional:

O que podemos aprender com os dados que esses sistemas produzem?

É aí que começa nossa viagem pelo Data Analytics.

E nosso guia será justamente o homem conhecido por contar algumas das histórias mais improváveis da literatura.

Isso será conveniente porque existe uma regra importante em análise de dados:

Se uma história parece extraordinária, procure os dados antes de acreditar nela.



1. Afinal, o que é Data Analytics?

Podemos traduzir Data Analytics como Análise de Dados.

Mas simplesmente dizer isso esconde boa parte da história.

Data Analytics é um conjunto de processos, técnicas e ferramentas utilizados para transformar dados em informações capazes de ajudar pessoas e organizações a compreender acontecimentos e tomar decisões.

Podemos representar isso assim:

DADOS
  ↓
PREPARAÇÃO
  ↓
ANÁLISE
  ↓
PADRÕES
  ↓
INSIGHTS
  ↓
COMUNICAÇÃO
  ↓
DECISÃO

Observe algo importante.

O objetivo final não é criar um gráfico.

Também não é executar Python.

Muito menos instalar alguma ferramenta milagrosa com IA.

O objetivo é tomar decisões melhores com base em evidências.

Imagine um banco processando milhões de transações.

O sistema pode saber que:

CLIENTE = 837291
VALOR   = 9800
HORA    = 03:17
CANAL   = WEB

Esses são dados.

Mas Data Analytics começa quando perguntamos:

Esse valor é normal para esse cliente?

Ele costuma comprar às três da manhã?

Esse canal é habitual?

Houve outras compras semelhantes?

O endereço IP está relacionado à localização normalmente utilizada?

Agora os dados começaram a contar uma história.



2. “Mas quem inventou Data Analytics?”

O Barão imediatamente levanta a mão:

— Fui eu! Em 1783, durante uma viagem à Lua...

Não, Barão.

Pode abaixar a mão.

Não existe uma única pessoa reconhecida como inventora do Data Analytics.

Também não encontramos um inventor específico para a expressão Introduction to Data Analytics.

Esse é simplesmente um título descritivo usado para cursos introdutórios sobre análise de dados.

A história intelectual do Data Analytics é muito mais interessante porque várias disciplinas contribuíram para sua formação.

Uma árvore bastante simplificada seria:

ESTATÍSTICA
   │
   ├── Pesquisa Operacional
   │
   ├── Análise de Dados
   │      └── John Tukey — 1962
   │
   ├── Bancos de Dados
   │      └── Edgar F. Codd — década de 1970
   │
   ├── Decision Support Systems
   │
   ├── Data Warehousing / BI
   │
   ├── Analytics
   │      └── Thomas Davenport — 2006
   │
   ├── Big Data
   │
   ├── Data Science
   │
   └── Machine Learning / GenAI

Essa árvore não deve ser interpretada como uma genealogia rígida na qual uma tecnologia simplesmente substitui a anterior.

É melhor enxergá-la como uma acumulação de conhecimentos.

Estatística continua existindo.

SQL continua existindo.

Data Warehouse continua existindo.

Machine Learning não tornou regressão inútil.

IA generativa não tornou bancos de dados obsoletos.

E, para surpresa de algumas apresentações corporativas...

COBOL também continua aqui.



3. A raiz: Estatística

Antes de existir computador, já existia a necessidade de analisar números.

Populações, comércio, agricultura, astronomia, seguros, economia e administração pública produziram problemas que exigiam métodos quantitativos.

Daí se desenvolveram conceitos fundamentais como:

  • média;

  • mediana;

  • moda;

  • variância;

  • desvio padrão;

  • distribuição;

  • probabilidade;

  • correlação;

  • regressão.

Para o programador COBOL, alguns desses conceitos parecem muito mais familiares quando saem do livro de estatística.

Imagine tempos de resposta:

0,31
0,29
0,30
0,32
0,31
0,30
2,87

Existe alguma coisa estranha ali.

O 2,87 merece investigação.

Chamamos valores muito afastados do comportamento esperado de outliers.

O Barão naturalmente garante que o tempo de resposta de 2,87 segundos ocorreu porque um cavalo ficou preso no canal ESCON.

A equipe de produção prefere consultar os logs.


4. Média não conta toda a história

Imagine cinco transações:

100
105
110
115
10.000

A média é:

(100 + 105 + 110 + 115 + 10000) / 5
= 2086

Mas quatro das cinco transações estão perto de 100.

Por isso precisamos conhecer também mediana e dispersão.

A mediana seria:

110

Muito mais representativa do comportamento central daquele pequeno conjunto.

A dispersão, por sua vez, ajuda a entender quanto os valores se afastam uns dos outros.

Essa é uma lição fundamental para analytics:

Um único número raramente explica um sistema complexo.

É igualmente verdadeira para performance de mainframe.

Dizer:

“O response time médio é 300 ms.”

pode esconder períodos de 50 ms e outros de 5 segundos.

Por isso média, percentis, distribuição e dispersão importam.


5. Pesquisa Operacional entra no CPD

Outra contribuição importante veio da Pesquisa Operacional.

Ela utiliza modelos matemáticos para encontrar melhores decisões diante de restrições.

Imagine:

recursos limitados
+
múltiplas alternativas
+
objetivos
+
restrições

Isso aparece em logística, produção, transporte, escalonamento e planejamento.

Para quem conhece mainframe, a ideia não deveria parecer alienígena.

Um ambiente computacional também possui:

CPU
Memória
I/O
Prioridades
Workloads
SLAs
Janelas batch

E precisamos decidir como utilizar recursos limitados da melhor maneira possível.

O WLM provavelmente cumprimentaria a Pesquisa Operacional com bastante respeito.


6. John Tukey e a Análise de Dados

Em 1962, o estatístico John Tukey publicou o influente trabalho The Future of Data Analysis.

Tukey ajudou a fortalecer a ideia de que analisar dados era uma atividade intelectual própria, não simplesmente uma aplicação mecânica da estatística.

Posteriormente, seu trabalho sobre Exploratory Data Analysis — EDA tornou-se particularmente importante.

A ideia é poderosa:

Antes de tentar provar alguma coisa, explore os dados.

Observe.

Visualize.

Procure padrões.

Procure inconsistências.

Faça perguntas.

Para um programador COBOL, podemos traduzir:

Antes de alterar o programa porque alguém disse que “o sistema está lento”, investigue.


7. Edgar F. Codd aparece carregando tabelas

Chegamos aos anos 1970.

Entra em nossa história Edgar F. Codd, pesquisador da IBM.

Codd apresentou o modelo relacional para bancos de dados.

Essa contribuição transformaria profundamente a maneira como sistemas armazenam e consultam informações.

Em vez de pensar somente em estruturas físicas, passamos a trabalhar conceitualmente com:

TABELAS
LINHAS
COLUNAS
CHAVES
RELACIONAMENTOS

E desse universo emergiria SQL.

Para o programador COBOL:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE CONTA_ID = :WS-CONTA-ID
END-EXEC.

Parece cotidiano.

Mas existe uma enorme história da computação escondida atrás desse SELECT.


8. Decision Support Systems

À medida que empresas armazenavam mais informações, surgiu outra necessidade:

usar computadores não apenas para executar operações, mas também para ajudar pessoas a decidir.

Daí crescem os Decision Support Systems — DSS.

O sistema transacional responde:

“A venda aconteceu?”

O sistema de apoio à decisão pode perguntar:

“Por que as vendas caíram?”

Perceba a mudança.

OLTP → executar o negócio

Analytics → compreender o negócio

Naturalmente os dois mundos podem se alimentar.


9. Data Warehouse e Business Intelligence

Empresas possuíam dados espalhados em diversos sistemas.

Então apareceu outro problema:

Como juntar tudo isso para análise?

Entram Data Warehouses, Data Marts, processos ETL e ferramentas de Business Intelligence.

ETL significa:

Extract
Transform
Load

Ou:

Extrair
Transformar
Carregar

Quem trabalha com mainframe talvez esteja pensando:

“Nós fazemos coisas parecidas há décadas.”

E não está totalmente errado.

Arquivos são extraídos, classificados, combinados, transformados e carregados desde muito antes de o termo data pipeline virar moda.

DFSORT poderia escrever memórias bastante interessantes sobre isso.


10. Data Wrangling — o faxineiro que salva o projeto

Dados reais são bagunçados.

Encontramos:

campos vazios
duplicidades
datas incompatíveis
valores inválidos
espaços
códigos antigos
unidades diferentes
registros incompletos

Data Wrangling é o processo de transformar esse material em algo apropriado para análise.

Um fluxo típico inclui:

Discovery
   ↓
Transformation
   ↓
Validation
   ↓
Publishing

Isso pode envolver:

  • joins;

  • unions;

  • normalização;

  • limpeza;

  • enriquecimento;

  • validação.

Aqui existe uma regra que merece ser escrita na parede do CPD:

IA aplicada sobre dado ruim produz erro tecnologicamente sofisticado.

Ou, na versão tradicional:

Garbage In, Garbage Out.

O Barão prefere:

Garbage In, história extraordinária Out.


11. Analytics chega à sala da diretoria

Em 2006, Thomas H. Davenport publicou na Harvard Business Review o artigo Competing on Analytics.

Ele ajudou a popularizar a utilização de analytics como instrumento de vantagem competitiva.

A pergunta empresarial deixa de ser apenas:

“Quanto vendemos?”

e passa a incluir:

Quem compra?

Quando compra?

Por que compra?

Quem provavelmente deixará de comprar?

Onde existe fraude?

O que provavelmente acontecerá depois?

Os dados começam a participar diretamente da estratégia empresarial.


12. Big Data — quando o dataset comeu demais

Depois veio a explosão de dados.

Web.

Smartphones.

Sensores.

Logs.

Redes sociais.

Streaming.

IoT.

Transações digitais.

Passamos a falar dos famosos Vs do Big Data.

Entre eles:

Volume — quantidade.

Velocity — velocidade.

Variety — variedade.

Veracity — confiabilidade.

Tecnologias distribuídas como Hadoop e Spark ganharam destaque nesse cenário.

Mas existe uma curiosidade importante para nós.

Enquanto o mundo descobria que havia dados demais...

o mainframe provavelmente respondeu:

“Interessante. Conte-me mais.”


13. Data Science

Data Science combina conhecimentos de várias áreas:

Estatística
+
Computação
+
Conhecimento do domínio
+
Métodos analíticos

Isso explica uma coisa importantíssima.

O melhor profissional não é necessariamente aquele que conhece mais bibliotecas Python.

Conhecimento do domínio importa enormemente.

E é aí que um desenvolvedor COBOL experiente possui uma vantagem.

Ele talvez conheça:

cliente
conta
apólice
pedido
pagamento
fatura
liquidação
compensação
estoque

Não apenas como colunas.

Mas como processos reais do negócio.


14. Machine Learning

Machine Learning leva a análise adiante permitindo que modelos aprendam padrões a partir dos dados.

Algumas tarefas clássicas incluem:

Classificação

Determinar uma categoria.

TRANSAÇÃO
   ↓
LEGÍTIMA
ou
SUSPEITA

Clustering

Agrupar elementos semelhantes sem necessariamente possuir classes previamente definidas.

clientes
   ↓
grupo A
grupo B
grupo C

Regressão

Investigar relações entre variáveis e produzir estimativas.

Detecção de anomalias

Encontrar comportamentos incomuns.

E essa última nos leva diretamente ao exemplo do curso.


15. O ladrão roubou o cartão — ou talvez apenas as credenciais

Imagine um cliente que normalmente:

faz 3 compras por semana
gasta aproximadamente R$ 150
compra em São Paulo
utiliza dispositivos conhecidos

De repente:

12 compras
4 minutos
valores elevados
IP incomum
localização diferente
nova preferência de entrega

Nenhum desses elementos isoladamente prova fraude.

Mas juntos formam um comportamento digno de investigação.

Esse é um excelente exemplo de detecção de anomalias.

O processo seria aproximadamente:

1. Definir o problema
        ↓
2. Identificar os dados necessários
        ↓
3. Coletar
        ↓
4. Limpar
        ↓
5. Transformar
        ↓
6. Analisar
        ↓
7. Detectar padrões/anomalias
        ↓
8. Visualizar
        ↓
9. Comunicar
        ↓
10. Decidir

Esse é o coração do Data Analytics.



16. Visualização — porque ninguém quer interpretar 800 mil linhas

Imagine entrar numa reunião executiva e dizer:

— Descobri o problema. Aqui estão 4,7 milhões de registros CSV.

Você provavelmente não será convidado novamente.

Visualização transforma dados em representações compreensíveis.

Podemos utilizar:

  • gráficos de barras;

  • linhas;

  • histogramas;

  • scatter plots;

  • mapas;

  • dashboards.

Um gráfico pode revelar em segundos algo escondido em milhões de registros.

Mas cuidado:

visualização não substitui análise.

Um gráfico bonito com dados incorretos continua incorreto.

Só ficou mais convincente.


17. Storytelling — o momento Münchhausen

Finalmente chegamos ao território favorito do Barão.

Contar histórias.

Mas agora precisamos fazer exatamente o contrário do nosso guia.

Nada de exageros.

Nada de inventar.

Nada de cavalgar balas de canhão.

Data Storytelling significa comunicar uma conclusão apoiada por evidências.

Uma boa narrativa pode seguir:

CONTEXTO
   ↓
PROBLEMA
   ↓
EVIDÊNCIA
   ↓
DESCOBERTA
   ↓
IMPACTO
   ↓
RECOMENDAÇÃO

Em vez de dizer:

“CPU aumentou.”

Podemos dizer:

“Após o crescimento de 38% do volume transacional entre 10h e 11h, observamos aumento consistente no consumo de CPU acompanhado por crescimento do response time. A análise indica concentração no workload X e recomenda investigação das transações Y.”

Agora existe história.

Existe contexto.

Existe decisão possível.


18. E então apareceu a IA Generativa

Chegamos ao capítulo mais recente.

LLMs e IA generativa conseguem:

  • resumir informações;

  • gerar consultas;

  • auxiliar análise;

  • explicar padrões;

  • produzir código;

  • ajudar na documentação;

  • apoiar visualizações;

  • conversar com bases de conhecimento.

Mas existe um detalhe delicioso.

IA precisa de dados.

Dados precisam de:

qualidade
contexto
governança
segurança
interpretação

Portanto nossa árvore não desapareceu.

Ela ficou maior.

Estatística
     ↓
Data Analysis
     ↓
Databases
     ↓
BI
     ↓
Analytics
     ↓
Big Data
     ↓
Data Science
     ↓
Machine Learning
     ↓
GenAI

Cada camada carrega ideias das anteriores.



19. O IBM Z estava no porão o tempo inteiro

Agora olhamos para o mainframe.

Ali encontramos:

COBOL
CICS
IMS
Db2
VSAM
JES2
SMF
RMF
MQ
APIs

E atrás dessas tecnologias existem dados.

Muitos dados.

Transacionais.

Operacionais.

Financeiros.

Históricos.

De performance.

De segurança.

O mainframe não é apenas uma máquina executando programas COBOL.

É também uma das maiores fontes de informação empresarial de alto valor.


20. Por que um desenvolvedor COBOL deveria aprender tudo isso?

Porque o trabalho está mudando.

Não significa abandonar:

COBOL
JCL
CICS
Db2
VSAM

Significa acrescentar:

SQL avançado
Estatística
Data Analytics
Visualização
Python
IA

Um desenvolvedor tradicional pode perguntar:

“Onde esse campo é atualizado?”

Um profissional com mentalidade analítica também pergunta:

“O que podemos descobrir analisando dez anos desse campo?”

Essa segunda pergunta abre um universo novo.



21. Um laboratório Bellacosa

Quer começar sem instalar um cluster Hadoop no quintal?

Pegue um conjunto de dados simples.

Pode ser:

DATA
HORÁRIO
TRANSAÇÃO
VALOR
CPU
RESPONSE_TIME
STATUS

Passo 1 — explore

Quantos registros existem?

Quais campos?

Há valores faltantes?

Passo 2 — limpe

Remova duplicidades.

Padronize datas.

Verifique valores inválidos.

Passo 3 — calcule

Descubra:

média
mediana
mínimo
máximo
desvio

Passo 4 — procure outliers

Quais transações fogem do comportamento esperado?

Passo 5 — relacione variáveis

Por exemplo:

volume × CPU
volume × response time
CPU × response time

Passo 6 — visualize

Crie um gráfico temporal.

Passo 7 — conte a história

Não diga apenas:

“Existe um pico.”

Explique:

quando ocorreu;

qual foi sua magnitude;

quais variáveis mudaram;

quais workloads foram afetados;

qual hipótese merece investigação.

Parabéns.

Você acabou de sair de:

“olhar relatório”

para:

“fazer análise de dados”.


22. Easter egg — o Barão encontra um outlier

No final da visita, Münchhausen olha para nosso dataset.

TEMPO_RESPOSTA

0.28
0.31
0.30
0.29
0.32
47.81
0.30

Ele aponta imediatamente para 47.81.

— Conheço esse número! Foi exatamente o tempo que levei para escapar de um pântano puxando a mim mesmo pelos cabelos!

O analista consulta SMF.

O DBA consulta Db2.

O sysprog consulta RMF.

O desenvolvedor abre os logs.

Descobrem uma contenção.

O Barão parece decepcionado.

Mas acabamos de aprender uma última lição:

Um outlier começa uma investigação. Ele não termina uma investigação.


Epílogo — Não abandone o canhão; aprenda balística

Existe uma tentação recorrente na tecnologia de anunciar que cada novidade matou tudo o que existia antes.

Cloud matou mainframe.

Java matou COBOL.

NoSQL matou SQL.

Big Data matou Data Warehouse.

Machine Learning matou estatística.

IA matou programação.

Enquanto isso, no mundo real, todas essas tecnologias continuam convivendo.

O profissional valioso não é necessariamente aquele que corre atrás de cada buzzword.

É aquele que consegue entender como as peças se conectam.

Para o desenvolvedor COBOL, Data Analytics oferece justamente essa oportunidade.

Você já conhece sistemas que produzem dados críticos.

Conhece transações.

Conhece regras de negócio.

Conhece exceções.

Conhece processamento batch.

Conhece online.

Conhece bancos de dados.

Conhece o estranho campo WS-FLAG-X9 que ninguém documentou desde 1997.

Agora acrescente:

estatística.

análise.

visualização.

storytelling.

Machine Learning.

IA.

E talvez você descubra que não precisa abandonar 30 anos de experiência para entrar no futuro.

Pode fazer algo muito mais inteligente:

colocar o futuro em cima desses 30 anos.

Nossa árvore, afinal, não cresce destruindo suas raízes.

Ela cresce justamente porque possui raízes.

                    GenAI
                      ▲
              Machine Learning
                      ▲
                Data Science
                      ▲
                  Big Data
                      ▲
                 Analytics
                      ▲
             Data Warehouse / BI
                      ▲
                    DSS
                      ▲
                Databases
                      ▲
               Data Analysis
                      ▲
           Pesquisa Operacional
                      ▲
                 Estatística

                     │
                     │
               DADOS REAIS
                     │
              ┌──────┴──────┐
            COBOL          CICS
              │              │
             Db2            IMS
              │              │
            VSAM           MQ/API
              └──────┬───────┘
                     │
                   IBM Z

O Barão de Münchhausen sobe novamente em seu cavalo.

Olha para o IBM Z.

Olha para nosso dashboard.

Olha para a IA.

E antes de cavalgar rumo ao próximo absurdo tecnológico, deixa um conselho surpreendentemente sensato:

“Meu caro programador: eu posso inventar histórias porque sou o Barão. Você, quando trabalhar com dados, precisa provar as suas.”

Bellacosa Mainframe

Do cartão perfurado à Inteligência Artificial, os dados sempre tiveram uma história para contar. Nossa profissão é aprender a ouvi-la.

IBM Bob Entra no CPD — O Dia em que o Programador COBOL Parou de Pedir Código e Começou a Comandar Agentes

 

Bellacosa Mainframe e o ibm bob chegando no cpd

☕ Um Café no Bellacosa Mainframe

IBM Bob Entra no CPD — O Dia em que o Programador COBOL Parou de Pedir Código e Começou a Comandar Agentes

Ou: por que “eu uso IA para programar” já vale quase o mesmo que dizer “sei usar Google”, como ASK, PLAN e AGENT mudam a engenharia de software, por que um agente merece menos privilégios que um estagiário com RACF SPECIAL e como o COBOL pode ensinar uma lição ao futuro da programação




Prólogo — Bob chegou ao CPD e pediu acesso ao código

Imagine a cena.

São 22h37.

O CPD está silencioso.

O café já foi requentado duas vezes.

No canto da sala existe um programa COBOL chamado:

PAYR001

Ele tem 18 mil linhas.

Foi criado quando alguém ainda dizia:

“Internet? Isso aí não vai pegar.”

Ninguém sabe exatamente tudo o que o programa faz.

O analista que escreveu a primeira versão se aposentou.

O sujeito que conhecia metade das regras de negócio abriu uma pousada em Ubatuba.

O último programador que tentou “modernizar rapidinho” deixou três comentários no fonte:

      * NAO MEXER AQUI
      * NAO SEI PQ FUNCIONA
      * MAS FUNCIONA

Então entra Bob.

Não o operador Bob.

Não o Bob da contabilidade.

IBM Bob, o parceiro de desenvolvimento baseado em inteligência artificial.

Bob olha para PAYR001.

O programador COBOL iniciante olha para Bob.

E comete o primeiro pecado da programação assistida por inteligência artificial:

“Bob, modernize isso.”

Nesse instante, em algum lugar do universo, um sysprog derruba uma caneca de café.

Porque o problema da IA em desenvolvimento de software nunca foi apenas:

Ela consegue escrever código?

A pergunta correta é:

Você sabe o que está autorizando a IA a fazer?

Bem-vindo à próxima etapa da programação.



1. “Eu uso IA para programar” deixou de impressionar

Há alguns anos, colocar no currículo:

Experiência com inteligência artificial aplicada ao desenvolvimento.

podia chamar atenção.

Depois vieram ChatGPT, GitHub Copilot, CodeWhisperer, Claude, Gemini, IBM Bob e uma coleção cada vez maior de ferramentas.

Hoje é comum um desenvolvedor digitar:

crie uma função

e receber uma função.

Depois:

crie os testes

e receber testes.

Depois:

documente

e receber documentação.

Isso continua sendo útil.

Mas deixou de ser extraordinário.

É parecido com escrever no currículo:

“Sei pesquisar no Google.”

Parabéns.

Em 2001 talvez fosse diferencial.

Em 2026 é parte do trabalho.

O que começa a separar profissionais é outra coisa:

o que você consegue fazer com a IA depois que ela deixa de ser uma simples máquina de completar código?





2. O iniciante costuma confundir programação com digitação de programa

Essa confusão já existia muito antes da inteligência artificial.

Veja este COBOL:

       IF WS-SALDO > 0
           MOVE 'ATIVO' TO WS-STATUS
       ELSE
           MOVE 'INATIVO' TO WS-STATUS
       END-IF.

Um iniciante pode aprender essa sintaxe rapidamente.

Isso significa que ele entende o sistema?

Não.

Talvez WS-SALDO represente:

  • saldo contábil;

  • saldo disponível;

  • saldo bloqueado;

  • saldo devedor;

  • posição intraday;

  • um campo legado chamado saldo que na prática representa outra coisa.

O problema empresarial não mora na palavra MOVE.

Ele mora no significado.

Esse é um dos primeiros ensinamentos que o mainframe oferece para a era da IA:

Código é representação. Negócio é contexto.

IA ficou extraordinariamente boa na primeira parte.

A segunda continua sendo muito mais complicada.


3. O código está deixando de ser o gargalo

Durante décadas, escrever software era caro.

Você precisava transformar uma ideia em milhares de instruções.

Então nasceram linguagens de alto nível.

Depois bibliotecas.

Frameworks.

IDEs.

Stack Overflow.

Geradores.

Low-code.

E finalmente grandes modelos de linguagem.

Agora imagine que produzir código fique dez vezes mais rápido.

Excelente.

Mas surge um efeito curioso.

Antes:

REQUISITO
   ↓
ANÁLISE
   ↓
CODIFICAÇÃO     ← lento
   ↓
REVISÃO
   ↓
TESTE
   ↓
HOMOLOGAÇÃO
   ↓
PRODUÇÃO

Depois da IA:

REQUISITO
   ↓
ANÁLISE
   ↓
IA
   ↓
████████████████████
REVISÃO
TESTES
SEGURANÇA
VALIDAÇÃO
████████████████████
   ↓
PRODUÇÃO

Você não eliminou necessariamente o gargalo.

Você mudou o gargalo de lugar.

A própria documentação e comunicação recente em torno do IBM Bob refletem essa mudança de foco: Bob trabalha hoje com modos específicos para perguntar, planejar e executar, além de ferramentas, subagentes, MCP e integrações além da simples geração de texto.

Quanto mais código conseguimos produzir automaticamente, mais importante passa a ser responder:

Isto está correto?

Isto deveria existir?

Isto viola alguma regra?

Isto quebra quem?

Isto pode ir para produção?

A IA acelera a construção.

Mas alguém ainda precisa saber o que merece ser construído.



4. Conheça os três estados mentais: ASK, PLAN e AGENT

Aqui aparece uma das ideias mais educativas do IBM Bob.

Os modos nativos atuais distinguem três comportamentos fundamentais:

ASK
PLAN
AGENT

Não pense nisso apenas como botões de interface.

Pense como três níveis diferentes de relacionamento entre você e um agente.

A documentação do Bob define Ask como apropriado para explicações e análise sem modificações; Plan para investigar e elaborar estratégias antes da implementação; e Agent para tarefas que envolvem modificar código, executar comandos e implementar mudanças.

Isso deveria estar pregado na parede de todo CPD:

ENTENDER
ANTES DE
PLANEJAR

PLANEJAR
ANTES DE
ALTERAR


5. ASK — “Bob, explique essa tranqueira antes que alguém mexa nela”

Imagine que você recebeu:

PAYR001

Você não sabe o que faz.

O comportamento errado seria:

Refatore esse programa.

O comportamento inteligente começa com investigação:

Analise PAYR001.

Identifique:

- arquivos utilizados;
- copybooks;
- chamadas CALL;
- tabelas Db2;
- recursos CICS;
- acessos VSAM;
- códigos de retorno;
- possíveis dependências;
- pontos que parecem representar regras de negócio.

Não modifique nenhum arquivo.

Perceba a última frase:

Não modifique nenhum arquivo.

Essa frase vale ouro.

Estamos usando IA como analista, não como cirurgião.

Ela pode responder:

PAYR001
 |
 +-- COPY EMPREG
 |
 +-- COPY TAXAS
 |
 +-- DB2 EMPLOYEE
 |
 +-- CALL TAXCALC
 |
 +-- VSAM FUNCION
 |
 +-- CICS LINK PAYR020

Agora você começou a construir um mapa.

Esse é o papel ideal do Ask.



6. Easter egg nº 1 — Sherlock Holmes deveria ter trabalhado com legado

Uma grande parte da manutenção de sistemas antigos é investigação.

Você encontra:

       MOVE 17 TO WS-TIPO-CALCULO.

Por quê 17?

Ninguém sabe.

Você pesquisa o programa.

Depois o copybook.

Depois o JCL.

Depois uma tabela.

Depois encontra uma documentação de 1998.

E finalmente descobre:

Tipo 17 = cálculo especial utilizado durante fechamento de fevereiro.

Isso não é programação.

Isso é arqueologia industrial.

Bob pode ser um excelente Watson.

Mas ainda precisamos de Sherlock para perguntar:

“Por que fevereiro?”



7. PLAN — o momento mais importante ocorre antes da primeira alteração

Agora suponha que nossa missão seja mudar uma regra de juros.

Não diga:

Faça.

Peça:

Planeje a alteração necessária para modificar
a regra de juros do produto X.

Antes de qualquer implementação:

1. identifique os módulos afetados;
2. liste dependências;
3. identifique copybooks envolvidos;
4. localize testes existentes;
5. identifique possíveis impactos externos;
6. proponha uma estratégia;
7. liste riscos;
8. defina critérios de aceitação.

Bob pode retornar:

PLANO

1. Modificar CALCJURO.cbl
2. Alterar TAXAS.cpy
3. Revisar tabela DB2 TAXA_JUROS
4. Atualizar teste TC019
5. Executar regressão
6. Validar PAYR001 e PAYR020

O iniciante diz:

“Parece ótimo!”

O veterano grita do fundo do CPD:

“NÃO MEXE NO TAXAS.CPY!”

Por quê?

Porque o veterano sabe que aquele copybook é utilizado por 47 programas.

A IA talvez tenha identificado somente 13.

Ou talvez nem tenha acesso a todos os repositórios.

Esse momento é crucial.

Você responde:

Plano rejeitado parcialmente.

TAXAS.CPY é compartilhado por outros sistemas.

Não alterar o copybook.

Proponha uma solução local mantendo a interface atual.

Pronto.

A inteligência mais importante dessa interação talvez não tenha sido a inteligência artificial.

Foi o julgamento humano.



8. Eis o verdadeiro superpoder do profissional experiente

Muito se fala que IA diminuirá a importância da experiência.

Em sistemas empresariais antigos pode ocorrer justamente o contrário.

Porque um sistema legado é:

código
+
dados
+
procedimentos
+
infraestrutura
+
interfaces
+
regras empresariais
+
exceções
+
história
+
conhecimento tribal

IA pode ler muito código.

Mas talvez não saiba que:

“Esse job nunca deve rodar antes do fechamento da filial argentina.”

Talvez isso não esteja documentado.

Talvez esteja apenas na cabeça de alguém chamado Carlos.

Carlos trabalha ali desde 1994.

Todos chamam aquilo de:

REGRA DO CARLOS

Nenhum compilador conhece.

Nenhum modelo conhece.

Carlos conhece.

Esse tipo de contexto será extremamente valioso.



9. AGENT — agora Bob recebe a caixa de ferramentas

Depois que o plano foi investigado e aprovado, chegamos ao modo Agent.

Aqui as coisas ficam sérias.

Bob pode trabalhar com operações de leitura, edição, execução de comandos e ferramentas conectadas.

A relação passa de:

Humano pergunta
IA responde

para:

Humano define objetivo
      ↓
Agente investiga
      ↓
Agente modifica
      ↓
Agente executa
      ↓
Agente testa
      ↓
Humano revisa

Essa é uma mudança gigantesca.

Porque agora a IA não está apenas falando sobre o sistema.

Ela está fazendo coisas no sistema.



10. Programador, conheça uma palavra importante: autoridade

Considere dois agentes.

Agente A

Pode apenas ler arquivos.

Risco:

baixo

Agente B

Pode:

ler arquivos
editar arquivos
executar shell
chamar APIs
consultar serviços
abrir pull request
alterar configuração

Risco:

hmmmm...

Agora imagine:

Agente C

Pode:

acessar produção
alterar banco
ler secrets
fazer deploy
aprovar merge

O operador do mainframe desmaia.

É exatamente aqui que décadas de experiência em controle de acesso voltam a ficar modernas.


11. RACF encontra inteligência artificial

O mainframeiro olha para essa discussão e pergunta:

“Vocês descobriram autorização agora?”

🤣

No mundo z/OS aprendemos há décadas a perguntar:

QUEM É VOCÊ?
        ↓
O QUE VOCÊ PODE ACESSAR?
        ↓
PODE APENAS LER?
        ↓
PODE ALTERAR?
        ↓
PODE EXECUTAR?
        ↓
QUEM CONCEDEU?
        ↓
EXISTE LOG?

Agora substitua usuário por agente:

QUAL AGENTE?
        ↓
QUAIS FERRAMENTAS?
        ↓
QUAIS ARQUIVOS?
        ↓
QUAIS SERVIDORES MCP?
        ↓
PODE EXECUTAR COMANDOS?
        ↓
PODE ALTERAR REPOSITÓRIO?
        ↓
PODE PUBLICAR?
        ↓
QUEM APROVA?

O futuro da IA empresarial parece surpreendentemente parecido com uma conversa que um administrador RACF teria em 1995.

Easter egg:

Não dê SPECIAL para Bob.

Ele é gente boa.

Mas ninguém merece SPECIAL.


12. Least privilege — trate a IA como trataria qualquer outro ator do sistema

Uma arquitetura saudável poderia permitir:

Bob pode:

[X] ler código
[X] criar branch
[X] alterar branch de trabalho
[X] executar testes
[X] gerar documentação
[X] criar Pull Request

Bob não pode:

[ ] merge direto em main
[ ] acessar senha de produção
[ ] modificar tabela produtiva
[ ] fazer deployment produtivo
[ ] desligar JES2 porque "pareceu uma boa ideia"

Esse modelo é chamado de princípio do menor privilégio.

Não dê uma permissão porque o agente pode eventualmente precisar.

Dê somente aquilo que é necessário para a tarefa atual.


13. Human-in-the-loop — existe um humano entre a ideia e o estrago

Um fluxo simples:

IA propõe
    ↓
HUMANO REVISA
    ↓
IA EXECUTA
    ↓
HUMANO VALIDA

Esse é um modelo conhecido como:

Human in the Loop

O ser humano participa diretamente dos checkpoints.

Depois de ganhar maturidade, certas tarefas podem usar algo semelhante a:

Human on the Loop

O agente executa atividades dentro de limites predeterminados e o humano supervisiona.

Por exemplo:

Bob:
    criar teste             SIM
    rodar teste             SIM
    corrigir branch         SIM
    abrir PR                SIM
    merge em produção       NÃO

Não precisamos escolher entre:

humano faz tudo

e

robô faz tudo.

Existe uma enorme região intermediária.

É ali que provavelmente estará grande parte da engenharia empresarial dos próximos anos.


14. Subagents — quando Bob monta sua própria equipe

Agora nossa história fica ainda mais interessante.

Bob pode utilizar subagents, agentes independentes que executam tarefas focadas em janelas de contexto isoladas e devolvem um resumo ao agente principal. A documentação atual distingue inclusive subagentes explore, orientados à exploração somente-leitura, e general, capazes de usar ferramentas mais amplas. O usuário aprova a criação antes da execução.

Imagine:

                BOB
                 |
     +-----------+-----------+
     |           |           |
  AGENTE      AGENTE      AGENTE
   COBOL        DB2         TESTE
     |           |           |
 PAYR001       SQL       REGRESSÃO

O agente COBOL analisa dependências.

O agente Db2 investiga consultas.

O agente de testes verifica cobertura.

Todos retornam resumos.

Bob junta as peças.

Isso começa a parecer menos com:

“assistente de programação”

e mais com:

“equipe técnica virtual”.


15. Mas subagent não é Pokémon

Existe uma tentação:

Bob, crie 27 agentes.

Não.

Mais agentes não significam automaticamente resultado melhor.

Cada agente:

  • consome contexto;

  • executa ferramentas;

  • pode interpretar algo incorretamente;

  • aumenta custo;

  • aumenta coordenação.

O próprio Bob procura usar subagentes quando o trabalho é realmente autocontido e quando separar o contexto faz sentido, em vez de lançar agentes indiscriminadamente para qualquer leitura simples.

Regra Bellacosa:

Se uma tarefa exige dois minutos, não convoque os Vingadores.


16. MCP — Bob encontrou tomadas no CPD

Outra sigla importante:

MCP

Model Context Protocol.

De forma simplificada, MCP permite que um agente trabalhe com ferramentas e fontes externas através de uma interface padronizada.

Antes:

LLM
 |
 conversa

Depois:

              BOB
               |
              MCP
       +-------+-------+
       |       |       |
      Git     API    Sistema
       |       |       |
      Jira   Docs    Ferramentas

A documentação do Bob apresenta MCP justamente como mecanismo para estender o agente com ferramentas externas e integrações personalizadas.

Essa é uma mudança fundamental.

Porque um chatbot só poderia dizer:

“Você deveria abrir um ticket.”

Um agente conectado talvez possa:

abrir o ticket

A diferença entre conselho e ação é enorme.


17. Bob Shell — quando o polvo sai do editor

Em agosto de 2026, a IBM colocou o agente V2 também no Bob Shell, levando a arquitetura compartilhada do Bob para o terminal. A atualização também trouxe mudanças no Bobalytics, IDE e gerenciamento relacionado a MCP e revisão de edições.

Para um programador isso significa algo importante.

Antes:

IDE
 |
assistente

Agora podemos imaginar:

TERMINAL
   |
 Bob Shell
   |
   +-- build
   +-- test
   +-- git
   +-- scripts
   +-- ferramentas

E quem trabalha com mainframe sabe uma coisa:

quando algo chega ao terminal, começa a entrar no território da automação.


18. O futuro não é prompt engineering

Durante algum tempo todo mundo falava:

PROMPT ENGINEERING

Como se a habilidade definitiva fosse descobrir a frase mágica.

Algo parecido com:

“Escreva um programa extraordinário, pense passo a passo, seja genial e não erre.”

Não.

A evolução real parece mais próxima de:

PROMPT
   ↓
CONTEXTO
   ↓
PLANO
   ↓
DELEGAÇÃO
   ↓
EXECUÇÃO
   ↓
VALIDAÇÃO
   ↓
GOVERNANÇA
   ↓
OBSERVABILIDADE
   ↓
MÉTRICA

A habilidade passa de:

saber conversar com IA

para:

saber operar IA dentro de um processo de engenharia.


19. O portfólio do iniciante também precisa mudar

Imagine dois candidatos.

Candidato 1

GitHub:

CRUD de clientes
Clone do Netflix
Lista de tarefas
Calculadora

Tudo produzido parcialmente com IA.

Legal.

Agora candidato 2 cria:

cobol-modernization-lab/
 |
 +-- README.md
 +-- docs/
 |    +-- architecture.md
 |    +-- decisions.md
 |    +-- risks.md
 |
 +-- prompts/
 |    +-- analysis.md
 |    +-- plan.md
 |
 +-- src/
 |
 +-- tests/
 |
 +-- lessons-learned.md

No README:

Problema
↓
Análise inicial
↓
Plano sugerido pelo agente
↓
Plano revisado
↓
Decisões rejeitadas
↓
Implementação
↓
Testes
↓
Resultado

Quem você acha que dará mais assunto numa entrevista?


20. A melhor seção do README talvez seja: “onde Bob errou”

Sim.

Você leu corretamente.

Imagine:

## AI Recommendation Rejected

Bob sugeriu modificar COPY TAXAS.

A recomendação foi rejeitada porque o copybook
é compartilhado por múltiplas aplicações.

Decisão humana:

manter interface pública e implementar adaptação
local no programa CALCJURO.

Isso é maravilhoso.

Porque demonstra:

IA sugeriu
        ↓
VOCÊ ENTENDEU
        ↓
VOCÊ DISCORDOU
        ↓
VOCÊ EXPLICOU
        ↓
VOCÊ DECIDIU

A competência não está em aceitar a IA.

Está em saber quando não aceitar.


21. Uma entrevista técnica do futuro

Recrutador:

Você utiliza agentes de IA?

Candidato:

Sim.

Recrutador:

Conte uma decisão do agente que você rejeitou.

Silêncio.

O candidato que simplesmente gerava código morreu na praia.

Já outro responde:

O agente sugeriu alterar um contrato compartilhado. Analisei dependências, percebi risco de quebra em consumidores externos, rejeitei a solução e implementei um adapter preservando compatibilidade.

Pronto.

Temos uma conversa de engenharia.


22. O programador COBOL tem uma vantagem inesperada

COBOL ensina algo precioso:

software não existe isoladamente

Um programa está conectado a:

JCL
copybooks
VSAM
Db2
CICS
IMS
MQ
jobs
arquivos
procedimentos
controle
segurança
scheduler
processos empresariais

Por isso manutenção mainframe raramente permite a fantasia:

“Vou apenas reescrever esse módulo.”

Esse módulo talvez seja chamado às 03h17 por um job que ninguém mencionou.

Pode alimentar um arquivo que vai para outro banco.

Pode produzir uma saída utilizada por um sistema que pertence a outra diretoria.

Em sistemas corporativos:

dependência é a criatura que mora atrás da porta que ninguém abriu.


23. Passo a passo Bellacosa para usar um agente em COBOL

Vamos montar um procedimento.

Etapa 1 — Entender

Use Ask:

Explique este programa COBOL.

Mapeie:
- divisions;
- paragraphs;
- copybooks;
- CALLs;
- arquivos;
- SQL;
- CICS;
- códigos de retorno.

Não altere nada.

Etapa 2 — Mapear dependências

Pergunte:

Quais componentes externos podem ser afetados
por uma modificação neste módulo?

Não confie cegamente.

Confirme no repositório e nas ferramentas existentes.


Etapa 3 — Criar plano

Crie um plano para implementar a mudança X.

Inclua:
- arquivos afetados;
- risco;
- rollback;
- testes;
- dependências;
- critérios de sucesso.

Não implemente ainda.

Etapa 4 — Revisar manualmente

Leia tudo.

Pergunte:

Isso realmente faz sentido?

Se não entende algum item, não aprove.

Peça explicação.


Etapa 5 — Limitar escopo

Em vez de:

modernize o sistema

prefira:

altere somente o módulo CALCJURO
sem modificar interfaces públicas
nem copybooks compartilhados.

Etapa 6 — Executar

Agora sim:

Implemente o plano aprovado.

Etapa 7 — Testar

Nunca aceite:

“Parece correto.”

Use:

Compile.
Execute testes.
Analise return codes.
Compare resultados.

Em COBOL:

COMPILOU

não significa:

FUNCIONOU

e:

FUNCIONOU

não significa:

ESTÁ CORRETO

Etapa 8 — Revisar o diff

Pergunte:

O que mudou?
Por que mudou?
Quais comportamentos podem ser afetados?

Depois olhe você mesmo.


Etapa 9 — Documentar

Registre:

o que a IA sugeriu
o que foi aceito
o que foi rejeitado
por quê
quais testes foram realizados

Isso cria auditoria e aprendizado.


24. Nunca terceirize compreensão

Existe um anti-pattern perigoso:

não entendo
  ↓
pergunto IA
  ↓
IA responde
  ↓
continuo não entendendo
  ↓
mas executo mesmo assim

Isso é apenas terceirização da ignorância.

🤣

O fluxo correto:

não entendo
   ↓
IA explica
   ↓
pergunto novamente
   ↓
verifico
   ↓
entendo suficientemente
   ↓
decido

IA deveria diminuir sua ignorância.

Não escondê-la.


25. Curiosidade — COBOL já viveu uma revolução parecida

Nos anos 1950, programar significava trabalhar muito mais perto da máquina.

Linguagens de alto nível eram uma abstração revolucionária.

Algum programador Assembly poderia olhar COBOL e dizer:

“Agora qualquer incompetente escreve programa!”

Talvez dissesse:

“Esses jovens nem sabem registrador!”

Décadas depois acontece algo curioso.

Programadores modernos dizem:

“Com IA qualquer pessoa gera programa!”

A história gosta de rir.

Compiladores automatizaram a transformação:

linguagem humana-ish
        ↓
código de máquina

IA automatiza outra camada:

intenção humana
        ↓
representação técnica

Mas abstração nunca eliminou necessidade de engenharia.

Ela apenas permitiu construir sistemas maiores.


26. Quanto maior a abstração, maior o raio da explosão

Em Assembly, você poderia errar uma instrução.

Com COBOL, uma regra errada poderia afetar milhões de registros.

Com um pipeline automatizado, uma alteração pode chegar a centenas de servidores.

Com agentes:

UM OBJETIVO MAL DEFINIDO
          ↓
MÚLTIPLAS ALTERAÇÕES
          ↓
TESTES
          ↓
AUTOMAÇÃO
          ↓
PR

Velocidade amplifica coisas boas.

E coisas ruins.

Por isso:

AUTONOMIA ↑
=
GUARDRAILS ↑

27. Guardrail é a cerca elétrica em volta do robô

Guardrail é qualquer mecanismo que limita comportamento.

Exemplos:

não editar produção
não acessar determinados diretórios
não executar determinados comandos
não enviar dados sensíveis
não modificar secrets
não publicar automaticamente
exigir aprovação

Pense em uma locomotiva.

Ela é extremamente poderosa.

Mas só é útil porque existe trilho.

Um agente sem trilho não é uma locomotiva.

É um trem atravessando o estacionamento.


28. E finalmente chegamos às métricas

Depois que uma empresa compra IA para centenas de desenvolvedores, aparece o gerente financeiro.

Ele não pergunta:

“Bob é legal?”

Ele pergunta:

“Quanto custou?”

Depois:

“Quanto economizou?”

Depois:

“Como você sabe?”

E aqui começa a parte adulta.

Não basta medir:

linhas de código

Linhas de código são uma métrica terrível.

Você pode produzir 200 mil linhas de lixo.

Melhores indicadores incluem:

Lead Time
Cycle Time
Defect Rate
Change Failure Rate
MTTR
Test Coverage
Rework
Deployment Frequency
Tempo economizado
Custo por mudança

As versões atuais do ecossistema Bob incluem Bobalytics justamente como uma camada de visibilidade sobre uso e atividade; a atualização de agosto de 2026 adicionou novas visões para observar atividade diária e padrões de utilização.


29. Bobalytics encontra SMF no boteco

O mainframeiro vê analytics e novamente começa a rir.

Porque estamos acostumados com a pergunta:

“O que aconteceu?”

E alguém responde:

“Vamos olhar os registros.”

SMF.

RMF.

Logs.

Auditoria.

Accounting.

Histórico.

Agora o mesmo princípio chega à IA:

Quem utilizou?
Quanto utilizou?
Para quê?
Qual resultado?
Quanto custou?
Qual foi a produtividade?

No futuro talvez ninguém aceite:

“A IA ajudou bastante.”

Precisaremos dizer:

antes: 12 horas
depois: 5 horas

antes: 8 defeitos
depois: 3 defeitos

custo de IA: X
tempo preservado: Y

Aí temos ROI.


30. Cuidado com a “produtividade placebo”

Existe um fenômeno interessante.

Desenvolvedor:

“Estou produzindo 70% mais rápido!”

Pergunta:

“Como você mediu?”

Resposta:

“Senti.”

🤣

Isso não é métrica.

É horóscopo corporativo.

Talvez a IA realmente tenha melhorado produtividade.

Mas precisamos separar:

sensação de velocidade

de:

resultado empresarial

31. O futuro do profissional técnico

A escada provavelmente será algo semelhante a:

NÍVEL 1
"uso autocomplete"

NÍVEL 2
"gero código"

NÍVEL 3
"forneço contexto"

NÍVEL 4
"planejo com agente"

NÍVEL 5
"delego tarefas"

NÍVEL 6
"coordeno subagents"

NÍVEL 7
"conecto ferramentas"

NÍVEL 8
"governo permissões"

NÍVEL 9
"meço resultado"

NÍVEL 10
"assumo responsabilidade"

O último é o mais importante.

Porque quando alguma coisa der errado ninguém aceitará:

“Mas Bob fez.”

A pergunta será:

“Quem aprovou?”


32. O easter egg escondido no SYSOUT

Depois de terminar a alteração, nosso programador encontra no relatório:

IEF142I JOB PAYROLL STEP01 - STEP WAS EXECUTED

Tudo parece normal.

Mais abaixo aparece:

BOB0001I ARTIFICIAL INTELLIGENCE COMPLETED TASK
BOB0002I HUMAN REVIEW REQUIRED

E finalmente:

BOB9999I CAFE REQUIRED BEFORE PRODUCTION

Esse último ainda não existe.

Mas deveria.


33. O iniciante não deve abandonar fundamentos por causa da IA

Se você está começando em COBOL, ainda precisa aprender:

IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION

PIC
MOVE
IF
EVALUATE
PERFORM
CALL
FILE STATUS
COMP
COMP-3
COPYBOOKS
JCL
VSAM
DB2
CICS

Por quê?

Porque se Bob gerar:

       MOVE WS-AMOUNT TO WS-BALANCE

você precisa entender o que aconteceu.

Se ele sugerir redefinir:

       05 WS-AMOUNT PIC S9(9)V99 COMP-3.

você precisa saber por que isso pode importar.

A IA não elimina fundamentos.

Ela aumenta a penalidade de não conhecê-los.


34. A regra do mestre Jedi do mainframe

Use IA para chegar mais rápido à pergunta difícil.

Não para fugir dela.

Se você gastava três horas procurando onde determinada regra estava implementada e Bob encontra em três minutos:

fantástico.

Use as duas horas e cinquenta e sete minutos economizadas para descobrir:

“Essa regra ainda deveria existir?”

Isso é valor.


35. Programação está mudando de escrever para dirigir

Podemos representar a mudança assim:

ONTEM

Humano
  ↓
Código
  ↓
Computador

Hoje:

Humano
  ↓
IA
  ↓
Código
  ↓
Computador

Amanhã:

              HUMANO
                 |
        arquitetura / intenção
                 |
                 ↓
              AGENTE
        +--------+--------+
        |        |        |
     subagent subagent subagent
        |        |        |
      código   testes   análise
        \        |        /
             ferramentas
                 |
              sistemas

O humano sobe um nível.

Mas não desaparece.


36. Talvez “programador” volte ao significado original

Existe uma ironia bonita aqui.

Programar significa essencialmente:

estabelecer uma sequência de ações para atingir um objetivo.

Durante décadas transformamos “programador” em:

pessoa que digita código.

Agentes podem fazer com que o programador volte a ser mais literalmente alguém que:

define objetivos
decompõe tarefas
estabelece restrições
coordena execução
verifica resultado

Ou seja:

talvez IA não esteja destruindo o conceito de programador.

Talvez esteja obrigando a palavra a recuperar seu significado.


37. Checklist Bellacosa antes de deixar Bob trabalhar

Antes:

[ ] Entendo o problema?
[ ] Sei qual é o resultado esperado?
[ ] Identifiquei o escopo?
[ ] Mapeei dependências?
[ ] Pedi um plano?
[ ] Revisei o plano?
[ ] Defini o que NÃO pode ser alterado?

Durante:

[ ] Estou acompanhando as alterações?
[ ] O agente está dentro do escopo?
[ ] Surgiu nova dependência?
[ ] Existem decisões que exigem humano?

Depois:

[ ] Compilou?
[ ] Testou?
[ ] Comparei comportamento?
[ ] Revisei diff?
[ ] Avaliei segurança?
[ ] Documentei decisões?
[ ] Existe rollback?

Se a resposta para metade for:

¯\_(ツ)_/¯

não vá para produção.


38. Epílogo — Bob pergunta se pode fazer deploy

Voltamos ao nosso CPD.

23h58.

PAYR001 foi analisado.

O plano foi criado.

Uma alteração perigosa em TAXAS.CPY foi rejeitada.

Bob modificou o módulo correto.

Os testes passaram.

O programador revisou o diff.

Bob então pergunta:

“Deseja fazer deployment?”

O programador olha para o relógio.

Olha para Bob.

Olha para o calendário.

É sexta-feira.

Ele responde:

NÃO.

Bob pergunta:

“Por quê?”

E o jovem programador finalmente demonstra que aprendeu a mais importante regra da computação corporativa:

“Porque eu posso ser iniciante, Bob, mas não sou maluco.”

Na segunda-feira faremos a mudança.

Com aprovação.

Com backup.

Com rollback.

Com logs.

E com alguém responsável olhando.

Porque o futuro da programação não será decidido por quem consegue produzir mais código.

Será decidido por quem consegue comandar máquinas cada vez mais capazes sem entregar a elas aquilo que nunca deveria ter sido terceirizado: julgamento, responsabilidade e compreensão do negócio.

IBM Bob pode ser copiloto.

Pode ser investigador.

Pode ser planejador.

Pode ser executor.

Pode convocar subagentes.

Pode usar ferramentas.

Pode trabalhar pelo terminal.

Pode atravessar o MCP e conversar com outros sistemas.

Mas alguém ainda precisa ocupar a cadeira do comandante.

E se você está começando agora em COBOL, existe uma oportunidade extraordinária diante de você:

não aprenda apenas a escrever programas.

Aprenda a entender sistemas.

Aprenda por que aquele MOVE existe.

Aprenda quem chama aquele programa.

Aprenda o que acontece quando o job termina com RC=08.

Aprenda por que segurança existe.

Aprenda por que produção exige respeito.

Aprenda a perguntar.

Aprenda a planejar.

Aprenda a discordar da inteligência artificial.

Porque talvez a habilidade técnica mais valiosa da próxima década não seja saber dizer para um agente:

“Faça.”

Será saber olhar para o plano produzido por ele, apoiar a caneca de café sobre a mesa e responder:

“Não, Bob. Essa parte você não vai mexer.”

E explicar exatamente por quê.

Bem-vindo ao Bellacosa Mainframe.

Artigo DIO - Bellacosa Mainframe

☕ E se amanhã um agente de IA pedir acesso ao seu código COBOL?

Leia o artigo completo publicado na DIO sobre IBM Bob, inteligência artificial, COBOL, mainframe e o futuro da engenharia de software.

☕ Carregando o artigo...
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...