☕ 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

quarta-feira, 3 de junho de 2026

A Família IBM Storage TS: Os Guardiões Silenciosos dos Dados que Mantêm o Mundo Funcionando

 

Bellacosa Mainframe a familia ibm storage ts: tapes e cartridges

☕ Um Café no Bellacosa Mainframe

A Família IBM Storage TS: Os Guardiões Silenciosos dos Dados que Mantêm o Mundo Funcionando

Muito além das fitas: conheça a evolução do armazenamento corporativo e descubra por que os maiores bancos do mundo ainda confiam na família IBM TS.

"Um programador COBOL normalmente pensa em arquivos, datasets e VSAM. Um administrador pensa em discos. Mas existe uma camada inteira entre eles que poucos enxergam. É nela que mora a verdadeira magia do armazenamento corporativo."

Existe uma curiosidade interessante.

Pergunte para um desenvolvedor júnior:

"Onde fica armazenado o arquivo que seu programa COBOL acabou de gravar?"

A resposta normalmente será:

"No disco."

Tecnicamente...

Está correta.

Mas também está extremamente incompleta.

Na verdade, entre seu programa COBOL e o disco físico existe um universo inteiro composto por controladoras, caches, virtualização, compressão, replicação, criptografia, fitas virtuais, bibliotecas robotizadas e algoritmos que trabalham 24 horas por dia para garantir que nenhum byte desapareça.

Hoje vamos tomar um café e conhecer um dos mundos mais fascinantes da computação corporativa: a família IBM Storage TS.


Antes de falar de Storage...

Vamos fazer uma viagem no tempo.

Imagine um banco em 1985.

O expediente termina às 18h.

À noite começa o Batch.

Depois dos programas COBOL processarem milhões de transações...

Era necessário fazer backup.

Como?

Em fitas magnéticas.

Literalmente.

O operador colocava dezenas ou centenas de cartuchos na biblioteca.

Os drives começavam a trabalhar.

CPU

↓

COBOL

↓

Disco

↓

Fita

No dia seguinte...

As fitas eram retiradas.

Algumas iam para cofres.

Outras viajavam para outro prédio.

Outras eram guardadas durante anos.

Era o famoso plano de recuperação de desastres.

Na época fazia todo sentido.

Hoje...

Nem tanto.


O problema do backup tradicional

Imagine um banco que possui:

  • 5 PB de dados

  • milhares de servidores

  • centenas de máquinas virtuais

  • IBM Z

  • Linux

  • Windows

  • Cloud

Será que copiar tudo uma vez por dia continua funcionando?

Não.

O mundo mudou.

Hoje existem aplicações funcionando:

  • 24 horas

  • 7 dias por semana

  • 365 dias por ano

Não existe mais "janela de backup".


Bellacosa Mainframe apresenta Virtual Tape

O nascimento do Virtual Tape

A IBM percebeu esse problema ainda nos anos 90.

Em 1997 lançou uma tecnologia revolucionária.

O primeiro Virtual Tape System (VTS).

A ideia parecia simples.

Em vez de gravar diretamente na fita...

O sistema gravaria primeiro em discos rápidos.

Depois moveria automaticamente os dados para fita.

Visualmente:

Aplicação COBOL

↓

Canal FICON

↓

Virtual Tape

↓

Disco

↓

Fita Física

Para o programa...

Nada mudou.

Ele continua acreditando estar escrevendo numa fita.

Esse detalhe é genial.


Curiosidade ☕

Seu programa COBOL nunca "soube" que a fita era virtual.

O JCL continuou praticamente igual.

O DD continuou apontando para uma fita lógica.

Toda a inteligência acontecia atrás das cortinas.

É um dos maiores exemplos de retrocompatibilidade da história da computação.


O que significa TS?

Muita gente acredita que TS significa apenas "Tape Storage".

Na realidade, dentro da linha IBM, TS identifica uma família de soluções de armazenamento corporativo voltadas principalmente para tecnologias de fita e virtualização de fita, embora seus recursos hoje vão muito além do simples uso de cartuchos físicos.

Ao longo dos anos surgiram equipamentos como:

  • TS1120

  • TS1130

  • TS1140

  • TS1150

  • TS1160

  • TS4500

  • TS7700

  • TS7770

  • TS7780

  • TS7785

Cada geração trouxe melhorias em:

  • desempenho

  • criptografia

  • compressão

  • capacidade

  • confiabilidade


A evolução da família TS

Podemos imaginar essa evolução assim:

Fita Física

↓

Virtual Tape

↓

GRID

↓

Cloud

↓

Always-On Data Protection

Perceba que não estamos falando apenas de hardware.

Estamos falando da evolução da própria filosofia de proteção de dados.


A família TS7700

Se existe uma estrela dentro desse universo...

Ela atende pelo nome:

IBM TS7700.

Durante muitos anos foi considerada a principal plataforma de Virtual Tape para ambientes IBM Z.

Ela introduziu conceitos que hoje parecem comuns.

Na época eram revolucionários.

Como:

✔ Cache inteligente

✔ Replicação

✔ GRID

✔ Failover automático

✔ Balanceamento

✔ Virtualização


Imagine uma biblioteca...

Pense numa biblioteca gigantesca.

Milhões de livros.

Agora imagine quatro bibliotecas espalhadas pelo país.

Todas possuem exatamente o mesmo catálogo.

Você entra em qualquer uma.

Pede um livro.

Ela encontra.

Pouco importa onde ele foi guardado originalmente.

Essa é a ideia do GRID.


O que é GRID?

GRID é provavelmente o conceito mais importante da família TS.

Antes:

Servidor Principal

↓

Backup

Depois:

Cluster A

↔

Cluster B

↔

Cluster C

↔

Cluster D

Todos trabalham.

Todos conhecem todos.

Todos possuem consciência dos dados.

É como um time de futebol.

Não existe apenas um jogador.

Se alguém sair machucado...

O jogo continua.


Easter Egg 🎮

Se você assistiu Star Wars, imagine o Conselho Jedi.

Não existe um único Jedi controlando toda a galáxia.

Todos colaboram.

O GRID funciona de maneira parecida.

Cada nó conhece o estado do ambiente inteiro.


Active-Active

Aqui aparece outro conceito importante.

Durante décadas existiu a arquitetura:

Primary

↓

Replica

↓

Standby

O standby ficava parado.

Esperando.

Às vezes durante anos.

No TS7785 isso muda.

Todos trabalham.

Todos recebem carga.

Todos respondem.

Todos podem restaurar dados.

É muito mais eficiente.


O TS7785

Chegamos ao protagonista.

O TS7785 representa uma evolução enorme da arquitetura TS7700.

Ele nasceu para atender não apenas Mainframe.

Mas também:

  • IBM i

  • LinuxONE

  • RHEL

  • ambientes distribuídos

É como se a IBM tivesse dito:

"A tecnologia que funcionou durante décadas no IBM Z agora está pronta para proteger qualquer plataforma."


Construído sobre IBM Power9+

Outro detalhe interessante.

O TS7785 utiliza processadores IBM Power9+.

Por quê?

Porque backup moderno faz muito mais do que copiar arquivos.

Ele precisa:

  • comprimir

  • criptografar

  • verificar integridade

  • sincronizar GRID

  • movimentar dados

  • conversar com Cloud

Tudo isso exige processamento.

Muito processamento.


4 GB por segundo

O artigo informa até:

4 GB/s por cluster.

Vamos traduzir.

4 GB/s

=

240 GB/min

=

14,4 TB/h

Isso significa que enormes volumes podem ser protegidos rapidamente.


Compressão ou Deduplicação?

Essa parte costuma confundir iniciantes.

Hoje quase todo fabricante fala de deduplicação.

A IBM escolheu outro caminho.

Compressão inline.

Vamos entender.


Deduplicação

Imagine dois arquivos.

ABCDEF

ABCXYZ

Os primeiros blocos são iguais.

A deduplicação guarda apenas uma cópia.

Economiza espaço.

Mas...

Na hora do restore precisa reconstruir tudo.

Isso pode consumir tempo.


Compressão Inline

Na compressão:

Arquivo

↓

Compacta

↓

Grava

Na recuperação:

Lê

↓

Descompacta

↓

Pronto

Mais simples.

Mais previsível.

Especialmente em cargas sequenciais típicas de backup.


Curiosidade ☕

A IBM prefere desempenho previsível.

Em ambientes bancários isso normalmente vale mais do que economizar alguns terabytes.


Unified Data Model

Imagine dez administradores.

Cada um sabe onde estão seus backups.

Problema.

Agora imagine:

Um catálogo único.

Todos enxergam tudo.

É isso que faz o Unified Data Model.

Você não precisa decorar onde cada cópia está armazenada.

O sistema resolve isso.


Cloud Storage Tier

Outra evolução importante.

Antigamente:

Disco

↓

Fita

Hoje:

SSD

↓

Disco

↓

Cloud

↓

Deep Archive

Tudo automatizado.

Baseado em políticas.

Por exemplo.

Após 30 dias.

Mover para Cloud.

Após um ano.

Mover para Archive.

Sem intervenção humana.


LAN-Free Backup

Essa tecnologia existe há anos.

Mas continua extremamente relevante.

Sem LAN-Free:

Servidor

↓

Rede Ethernet

↓

Backup Server

↓

Storage

Toda a rede sofre.

Com LAN-Free:

Servidor

↓

Fibre Channel

↓

Storage

Muito mais rápido.

Muito menos congestionamento.


Synthetic Full

Outro nome bonito.

A ideia também é simples.

Ao invés de criar um Full toda semana...

O sistema monta um Full virtual usando:

  • Full anterior

  • incrementais

Resultado.

Economiza:

✔ espaço

✔ tempo

✔ processamento


O conceito de Cyber Resilience

Repare que a IBM quase não fala "backup".

Ela fala:

Cyber Resilience.

Existe uma diferença enorme.

Backup significa:

"Tenho uma cópia."

Cyber Resilience significa:

"Mesmo atacado, continuo funcionando."

São filosofias completamente diferentes.


A regra 3-2-1

Você provavelmente ouvirá essa expressão durante entrevistas.

Ela significa:

  • 3 cópias dos dados

  • 2 mídias diferentes

  • 1 cópia fora do ambiente principal

Hoje muitos especialistas já falam em:

3-2-1-1-0

Onde existe ainda:

  • uma cópia imutável

  • zero erros após validação


Dica para quem trabalha com Mainframe

Se você conhece:

  • JCL

  • DFSMS

  • HSM

  • DFSMShsm

  • FICON

  • SMS

  • Catalog

  • RACF

Você já possui metade dos conceitos necessários para entender Storage Enterprise.

O restante é aprender como esses componentes conversam entre si.


Curiosidade histórica ☕

Os primeiros operadores de Mainframe literalmente carregavam caixas de fitas pelo Data Center.

Hoje um robô faz isso sozinho.

Algumas bibliotecas conseguem movimentar milhares de cartuchos automaticamente sem intervenção humana.

Se você visitar um grande Data Center verá braços robóticos deslizando entre estantes de fitas. Parece cena de ficção científica.


Easter Egg 🎮

Lembra do filme Indiana Jones e os Caçadores da Arca Perdida, quando a Arca é levada para um gigantesco depósito cheio de caixas idênticas?

Aquilo lembra bastante uma biblioteca de fitas corporativa.

A diferença é que, no mundo IBM, um software sabe exatamente onde cada "caixa" está e consegue encontrá-la em segundos.


Outro Easter Egg para os Padawans

No universo Star Wars existe o Holocron.

Ele guarda conhecimento dos Jedi.

No mundo IBM...

As fitas fazem algo parecido.

Elas preservam décadas de informações bancárias, governamentais e empresariais que continuam acessíveis quando necessário.


O futuro

O TS7785 mostra claramente para onde o mercado está caminhando.

Não basta possuir backups.

Será necessário possuir:

  • dados sempre disponíveis

  • múltiplos sites

  • Cloud integrada

  • inteligência automática

  • proteção contra ransomware

  • recuperação quase instantânea

Backup deixa de ser uma tarefa operacional.

Passa a ser parte da estratégia de continuidade do negócio.


Conclusão

Durante muito tempo, storage era visto como "aquele equipamento onde os arquivos ficam guardados". Hoje sabemos que essa visão é limitada. A família IBM Storage TS representa décadas de engenharia voltadas para garantir disponibilidade, desempenho e proteção dos ativos mais valiosos de qualquer organização: seus dados.

Da fita física ao Virtual Tape, da arquitetura GRID ao TS7785 com proteção contínua, a evolução mostra que a IBM não apenas acompanhou as mudanças do mercado, mas ajudou a defini-las. Conceitos como Active-Active, Unified Data Model, Cloud Storage Tier, LAN-Free Backup, Synthetic Full e Cyber Resilience demonstram que armazenamento moderno é muito mais do que capacidade; é inteligência, automação e continuidade operacional.

Para um programador COBOL júnior, entender esse ecossistema é um diferencial importante. Mesmo que você nunca administre um storage corporativo, seus programas gravam dados que percorrem essa infraestrutura todos os dias. Saber o que acontece "do outro lado do dataset" amplia sua visão da arquitetura corporativa e ajuda a compreender por que o IBM Z continua sendo referência mundial em confiabilidade.

No fim das contas, existe uma frase que resume bem a missão da família IBM Storage TS:

"O melhor backup é aquele que você quase nunca percebe... porque os dados continuam disponíveis quando o negócio mais precisa deles."

E talvez esse seja o maior legado da engenharia IBM: construir tecnologias tão confiáveis que passam despercebidas, enquanto silenciosamente protegem bilhões de transações todos os dias.


☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

 

Bellacosa Mainframe como pagar dividas tecnicas em mainframe



☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

Existe uma frase muito conhecida no mercado de tecnologia:

"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."

Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.

Mas a verdade é muito mais divertida.

Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.

Toda vez que alguém dizia:

"Depois a gente arruma."

Nascia uma nova parcela.

E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.

Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.


O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.

Imagine um programa COBOL.

Você precisa entregar uma alteração urgente.

O correto seria:

  • Revisar arquitetura

  • Atualizar documentação

  • Criar testes

  • Refatorar módulos

Mas o prazo é amanhã.

Então alguém faz:

IF CLIENTE = '999999'
    GO TO TRATAMENTO-ESPECIAL.

Entrega.

Produção funciona.

Cliente feliz.

Projeto encerrado.

Mas daqui a dois anos ninguém lembra por que aquele IF existe.

A dívida nasceu.


O MAIOR MITO DO MAINFRAME

Muita gente acredita que:

"Código antigo é dívida técnica."

Errado.

Código antigo pode ser excelente.

Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.

Por outro lado, existem programas escritos há seis meses que já nasceram endividados.

A idade do código não importa.

O que importa é:

  • Complexidade

  • Manutenibilidade

  • Clareza

  • Testabilidade

  • Documentação


COMO IDENTIFICAR DÍVIDA TÉCNICA

O primeiro passo é aprender a enxergá-la.

Alguns sintomas clássicos:

Programa que ninguém quer alterar

Quando uma demanda chega e todos falam:

"Tomara que não seja naquele programa..."

Existe dívida.


Alteração simples demora dias

Mudança:

Trocar 20 para 25.

Tempo gasto:

3 dias

Existe dívida.


Muitos abends

Se o mesmo módulo gera incidentes frequentemente:

  • S0C7

  • S0C4

  • SQLCODE negativos

  • Arquivos inconsistentes

Existe dívida.


Dependência de especialistas

Quando apenas uma pessoa entende o sistema.

Isso é uma dívida técnica humana.

Extremamente perigosa.


A METÁFORA DO CARTÃO DE CRÉDITO

A IBM utiliza uma analogia excelente.

Imagine um cartão.

Você compra algo hoje.

O benefício é imediato.

O pagamento fica para depois.

Dívida técnica funciona igual.

Benefício imediato:

Entreguei no prazo

Pagamento futuro:

Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho

O problema não é usar o cartão.

O problema é esquecer da fatura.


COMO MAPEAR A DÍVIDA TÉCNICA

A primeira atividade prática é criar um inventário.

Monte uma planilha contendo:

SistemaProblemaImpactoPrioridade
CadastroGO TO excessivoMédioMédia
CobrançaSem documentaçãoAltoAlta
FaturamentoAlta complexidadeAltoAlta

Você não consegue corrigir aquilo que não consegue enxergar.


MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA

Uma das métricas mais famosas.

Ela mede quantos caminhos lógicos existem em um programa.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Pouca complexidade.

Agora imagine:

IF A
 IF B
  IF C
   IF D

A complexidade explode.

Quanto maior a complexidade:

  • Mais difícil testar

  • Mais difícil manter

  • Maior risco de erro

Regra prática:

ValorSituação
1 a 10Boa
11 a 20Atenção
Acima de 20Risco

MÉTRICA 2 – TEMPO DE MANUTENÇÃO

Métrica simples.

Quanto tempo leva para implementar uma mudança?

Exemplo:

Alteração simples:

4 horas

Virou:

3 dias

A dívida está cobrando juros.


MÉTRICA 3 – QUANTIDADE DE INCIDENTES

Monitore:

  • Chamados

  • Tickets

  • Problemas recorrentes

Se determinado programa gera:

20% dos incidentes

Ele deve entrar imediatamente no backlog técnico.


MÉTRICA 4 – COBERTURA DE TESTES

Quanto do sistema possui testes?

Exemplo:

10%

Muito arriscado.

80%

Muito saudável.

No mundo COBOL isso pode envolver:

  • Unit Test

  • Testes automatizados

  • Batch Validation


MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO

MTTR

Mean Time To Recovery.

Quanto tempo leva para resolver um problema?

Exemplo:

10 minutos

Excelente.

8 horas

Existe forte dívida técnica.


A REGRA DOS 20%

Uma prática muito utilizada é reservar:

80% desenvolvimento
20% redução de dívida técnica

Isso impede que a dívida cresça infinitamente.


TÉCNICA 1 – REFATORAÇÃO CONTÍNUA

Refatorar significa melhorar sem alterar comportamento.

Exemplo:

Antes:

GO TO ERRO.
GO TO ERRO.
GO TO ERRO.

Depois:

PERFORM TRATA-ERRO.

Mesmo resultado.

Código mais limpo.


TÉCNICA 2 – MODULARIZAÇÃO

Programas gigantes são fábricas de dívida.

Já encontrei programas com:

80.000 linhas

Divida responsabilidades.

Crie módulos menores.

Mais simples de entender.

Mais simples de testar.


TÉCNICA 3 – DOCUMENTAÇÃO VIVA

Documentação morta é inútil.

Documentação viva é atualizada junto com o sistema.

Documente:

  • Fluxos

  • Arquivos

  • Tabelas

  • Regras de negócio


TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO

Existe um cemitério escondido em todo sistema.

Trechos como:

IF FLAG = 'X'

Que nunca mais executam.

Remover código morto reduz:

  • Complexidade

  • Risco

  • Tempo de manutenção


TÉCNICA 5 – BACKLOG TÉCNICO

Crie um backlog específico.

Exemplo:

Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto

A dívida precisa aparecer oficialmente.

Caso contrário ela nunca será priorizada.


FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME

IBM Application Discovery

Mapeia dependências.

Mostra:

  • Programas

  • Arquivos

  • CICS

  • DB2

Excelente para arqueologia de sistemas.


IBM ADDI

Application Discovery and Delivery Intelligence.

Permite visualizar relacionamentos invisíveis.

Muito útil para sistemas legados.


SonarQube

Mesmo para COBOL.

Detecta:

  • Complexidade

  • Duplicação

  • Código suspeito


IBM Developer for z/OS

Auxilia:

  • Navegação

  • Análise

  • Refatoração


Jira

Controle de backlog técnico.

Muitas empresas utilizam para registrar dívida técnica.


EASTER EGG MAINFRAME

Quer descobrir rapidamente onde existe dívida?

Procure:

GO TO
ALTER
NEXT SENTENCE

Ou:

STEP099
STEP100
STEP101

Sem documentação.

Você provavelmente encontrou um sítio arqueológico corporativo.


O ERRO MAIS COMUM DOS JUNIORES

Pensar:

"Vou reescrever tudo."

Não.

Esse é o caminho para o desastre.

A melhor estratégia quase sempre é:

Pequenas melhorias contínuas.

Todo dia.

Toda sprint.

Todo projeto.

Toda manutenção.


COMO EVOLUIR COMO PROFISSIONAL

Programadores experientes não são aqueles que escrevem mais código.

São aqueles que reduzem complexidade.

Quando você consegue olhar para um sistema e dizer:

"Esse trecho vai gerar problema daqui a dois anos."

Você começou a pensar como arquiteto.


O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS

Eles não combatem apenas bugs.

Eles combatem as causas dos bugs.

Essa é a diferença entre apagar incêndios e construir sistemas duradouros.


CONCLUSÃO

Dívida técnica não é um defeito.

Ela é uma ferramenta.

Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.

O problema surge quando ninguém controla o saldo.

O programador COBOL júnior que aprender a:

  • Identificar dívida

  • Medir dívida

  • Priorizar dívida

  • Reduzir dívida

  • Monitorar dívida

Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.

Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.

É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.



terça-feira, 2 de junho de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Para Transformar um Chatbot em um Verdadeiro Ambiente de Engenharia de Software com Inteligência Artificial

 

Bellacosa Mainframe e 100 dicas do claude em uma pagina

☕ Um Café no Bellacosa Mainframe 

100 Dicas do Claude em Uma Página

O Que Todo Programador COBOL Padawan Precisa Saber Para Transformar um Chatbot em um Verdadeiro Ambiente de Engenharia de Software com Inteligência Artificial

"A maioria das pessoas conversa com uma IA. Os profissionais que realmente aumentam sua produtividade trabalham em parceria com ela."  


Introdução

Quando surgiram os primeiros assistentes de Inteligência Artificial, a maioria das pessoas acreditava que eles seriam apenas uma versão mais sofisticada de um mecanismo de busca.

Você fazia uma pergunta.

Recebia uma resposta.

Fim da conversa.

Era quase como consultar um manual técnico digital.

Mas a evolução dos LLMs (Large Language Models) mostrou que esse pensamento estava incompleto.

Hoje, ferramentas como Claude, ChatGPT, Gemini e outras deixaram de ser apenas sistemas de perguntas e respostas. Elas estão se transformando em plataformas completas de desenvolvimento, capazes de compreender projetos inteiros, escrever código, revisar arquitetura, automatizar tarefas, conectar-se a sistemas externos e colaborar como verdadeiros membros de uma equipe de engenharia.

Recentemente, circulou um infográfico chamado "100 Claude Tips in One Page", reunindo cem dicas organizadas em dez categorias. À primeira vista, parece apenas uma lista de atalhos. No entanto, ao analisá-lo com atenção, percebemos algo muito maior: ele descreve uma nova forma de trabalhar com IA.

Para quem vem do universo IBM Mainframe, isso pode soar familiar.

Durante décadas aprendemos que escrever um programa COBOL era apenas uma pequena parte do trabalho. Antes dele existiam JCLs, bibliotecas, catálogos, RACF, CICS, DB2, schedulers, padrões corporativos e processos de mudança.

Da mesma forma, usar um LLM de maneira profissional envolve muito mais do que escrever um prompt.

Neste artigo vamos explorar cada uma dessas ideias sob a ótica de um Programador COBOL Padawan, criando paralelos entre a engenharia tradicional do IBM Z e a nova engenharia baseada em Inteligência Artificial.

Pegue seu café.

A conversa de hoje promete.


O erro que quase todo iniciante comete

Imagine um desenvolvedor júnior chegando ao ambiente z/OS e perguntando:

"Onde eu escrevo meu COBOL?"

O analista sorri e responde:

"Antes disso precisamos criar o dataset, definir o PROC, configurar o JCL, preparar as bibliotecas, verificar o compilador e garantir as permissões RACF."

O novato fica surpreso.

Ele pensava que programar era apenas escrever código.

Com IA acontece exatamente o mesmo.

A maioria das pessoas faz algo assim:

Explique Docker.

Recebe uma resposta.

Abre outra conversa.

Pergunta novamente.

Tudo começa do zero.

Isso equivale a reinicializar um mainframe antes de cada JOB.

É desperdício.

Os usuários avançados trabalham de maneira completamente diferente.


Conversar não é trabalhar

Existe uma enorme diferença entre conversar com uma IA e trabalhar utilizando IA.

Veja dois cenários.

Usuário comum

Pergunta

↓

Resposta

↓

Nova pergunta

↓

Nova resposta

Cada conversa é isolada.

Nada é reaproveitado.

Todo contexto precisa ser reconstruído.


Usuário avançado

Projeto

↓

Documentação

↓

Memória

↓

Arquivos

↓

Ferramentas

↓

MCP

↓

Claude Code

↓

Subagentes

↓

Resultado Final

Agora existe continuidade.

Existe contexto.

Existe engenharia.

Esse é exatamente o conceito por trás das 100 dicas do Claude.


Categoria 1 — Setup: Preparando o Ambiente

Todo programador Mainframe sabe que um bom ambiente vale mais do que horas de retrabalho.

Antes de executar um programa precisamos preparar:

  • Bibliotecas

  • DDNAMEs

  • Catálogos

  • PROCs

  • Variáveis

  • Ambientes de teste

  • Permissões

No Claude acontece algo semelhante.

A preparação inicial define toda a qualidade das respostas futuras.

Escolhendo o modelo correto

Nem toda tarefa exige o modelo mais poderoso.

É como escolher entre:

  • IEBGENER

  • DFSORT

  • IDCAMS

Todos resolvem problemas diferentes.

Da mesma forma:

Um modelo rápido pode resumir documentos.

Outro modelo mais inteligente pode projetar uma arquitetura distribuída.

Saber quando utilizar cada um é uma habilidade importante.


Memória

Um dos recursos mais interessantes.

A memória não serve para armazenar documentos.

Ela serve para armazenar preferências.

Por exemplo:

Sempre explique utilizando exemplos IBM Mainframe.

Utilize linguagem técnica.

Evite excesso de marketing.

Faça analogias com COBOL.

Após algum tempo, Claude passa a produzir respostas muito mais alinhadas ao seu estilo.

É como possuir um analista que já conhece seu jeito de trabalhar.


Projects

Imagine criar um projeto chamado:

Bellacosa Mainframe

Dentro dele existem:

COBOL

JCL

DB2

IMS

VSAM

REXX

CICS

RACF

Arquitetura

Normas

Documentação

Sempre que iniciar uma conversa nesse projeto, Claude já conhece todo esse universo.

É semelhante a abrir um PDS contendo toda a documentação corporativa.


Categoria 2 — Prompt Engineering

Prompt Engineering talvez seja o equivalente moderno da especificação funcional.

Quanto melhor a especificação...

Melhor será a implementação.

Considere dois exemplos.

Prompt simples

Explique CICS.

Resultado?

Uma resposta genérica.

Agora veja este.

Explique CICS para um programador COBOL de banco.

Compare com Batch.

Utilize diagramas ASCII.

Mostre vantagens.

Mostre limitações.

Inclua exemplos reais.

Finalize com um resumo executivo.

A diferença é enorme.


Definindo papéis

Uma técnica extremamente poderosa.

Você pode pedir:

Atue como:

Arquiteto IBM

Professor Universitário

Sysprog

DBA

Especialista DevOps

Especialista em Segurança

Cada persona muda completamente a forma da resposta.

É semelhante a pedir opiniões para profissionais diferentes dentro da mesma empresa.


Definindo restrições

Claude trabalha melhor quando possui limites claros.

Exemplo:

Até 800 palavras.

Português técnico.

Sem emojis.

Markdown.

Inclua tabelas.

Não invente informações.

Sempre cite vantagens e riscos.

Curiosamente, limitar produz respostas melhores.


Categoria 3 — Claude Code

Agora começamos a entrar no território da engenharia de software.

Claude Code não é apenas um editor.

Ele pode:

  • Ler projetos inteiros

  • Executar testes

  • Refatorar código

  • Criar documentação

  • Gerenciar Git

  • Atualizar dependências

Imagine dizer:

Leia este projeto.

Encontre duplicações.

Refatore.

Execute os testes.

Atualize README.

Faça commit.

Isso está muito além de responder perguntas.


Plan Mode

Uma funcionalidade fantástica.

Antes de alterar qualquer arquivo, Claude pode apresentar um plano.

Semelhante ao CAB (Change Advisory Board).

Primeiro ele analisa.

Depois identifica riscos.

Depois propõe mudanças.

Somente então executa.

Isso reduz bastante erros.


Categoria 4 — CLAUDE.md

Se existe um recurso que lembra o mundo corporativo, é este.

CLAUDE.md funciona como um conjunto permanente de normas.

Por exemplo:

Sempre escreva testes.

Nunca utilize jQuery.

Explique arquitetura.

Comente funções públicas.

Use TypeScript.

Priorize Clean Code.

É semelhante aos padrões corporativos existentes em grandes bancos.

Todo projeto passa a seguir as mesmas regras automaticamente.


Categoria 5 — Artifacts

Artifacts representam uma mudança de paradigma.

Antes:

Explique como criar um dashboard.

Agora:

Crie um dashboard funcional.

Em vez de responder...

Claude gera:

  • HTML

  • CSS

  • JavaScript

  • SVG

  • React

  • Mermaid

  • Diagramas

  • Simuladores

É como pedir um programa COBOL e receber também o JCL, a documentação e os testes.


Versionamento

Cada alteração cria versões.

Quase um Git interno.

Isso permite experimentar ideias sem medo.


Categoria 6 — MCP — Model Context Protocol

Talvez a inovação mais importante dos últimos anos.

MCP pode ser comparado aos drivers universais da IA.

Sem MCP:

Claude

↓

Texto

Com MCP:

Claude

↓

GitHub

↓

Google Drive

↓

SQL

↓

Filesystem

↓

Slack

↓

ERP

↓

CRM

↓

APIs

Agora Claude deixa de conversar.

Ele passa a executar trabalho.


Pensando como um profissional IBM

Imagine um MCP para:

  • SDSF

  • JES2

  • RMF

  • SMF

  • DB2

  • IMS

  • CICS

  • RACF

Você poderia perguntar:

Qual JOB falhou ontem?

Mostre o LOG.

Analise o ABEND.

Explique a causa.

Sugira correções.

O potencial é gigantesco.


Categoria 7 — Cowork e Agentes

Aqui a IA deixa de ser individual.

Imagine criar especialistas.

Agente 1

Arquiteto

Agente 2

Programador COBOL

Agente 3

DBA DB2

Agente 4

Especialista RACF

Agente 5

Revisor Técnico

Todos colaborando.

É praticamente uma equipe virtual.


Categoria 8 — Power User

Chegamos ao nível avançado.

Aqui encontramos recursos que poucos usuários exploram.

Subagentes

Em vez de uma IA resolver tudo sozinha...

Ela divide o problema.

Projeto

↓

Arquitetura

↓

Backend

↓

Frontend

↓

Testes

↓

Documentação

↓

Integração

Cada agente trabalha de forma especializada.

Depois os resultados são consolidados.

Isso lembra muito o paralelismo do IBM Z.


Hooks

Hooks funcionam como gatilhos.

Sempre que determinada ação ocorrer...

Outra ação é executada automaticamente.

Exemplo:

Salvar código

↓

Executar testes

↓

Atualizar documentação

↓

Verificar segurança

↓

Executar lint

↓

Atualizar CHANGELOG

É automação pura.


A filosofia por trás das 100 dicas

O maior ensinamento desse infográfico não é ensinar comandos.

É ensinar mentalidade.

A pergunta deixa de ser:

"Como faço uma pergunta melhor?"

E passa a ser:

"Como construo um ambiente onde a IA trabalhe continuamente ao meu lado?"

Essa mudança é profunda.


Paralelos com o IBM Mainframe

Vamos resumir essa comparação.

IBM MainframeClaude
JCLPrompt estruturado
PROCTemplates
DatasetContexto
PDSProjects
SYSINPrompt
JES2Orquestração
SchedulerAutomação
RACFPermissões
DB2Conhecimento estruturado
UtilitiesFerramentas
Change ManagementPlan Mode
Normas CorporativasCLAUDE.md
Equipe TécnicaAgentes

Perceba que praticamente todos os conceitos clássicos continuam existindo.

Mudou apenas a interface.

Agora ela é conversacional.


O impacto para um Programador COBOL Padawan

Durante muitos anos ouvimos que o COBOL seria substituído.

Depois disseram que o Mainframe desapareceria.

Mais recentemente, passaram a afirmar que a Inteligência Artificial substituiria os programadores.

Nenhuma dessas previsões se concretizou da forma anunciada.

O que realmente aconteceu foi uma evolução das ferramentas.

Assim como um compilador COBOL evoluiu, os ambientes de desenvolvimento evoluíram e os pipelines de integração contínua se tornaram padrão, os LLMs estão se tornando mais uma camada da engenharia de software.

Para o Programador COBOL Padawan, isso representa uma oportunidade extraordinária.

Imagine acelerar tarefas como:

  • geração de documentação técnica;

  • explicação de programas legados;

  • criação de casos de teste;

  • revisão de código COBOL;

  • análise de JCLs;

  • conversão de layouts Copybook para JSON;

  • criação de APIs REST para sistemas CICS;

  • preparação de apresentações técnicas;

  • produção de artigos, treinamentos e material didático.

A IA não elimina o conhecimento do especialista. Pelo contrário, amplia sua capacidade de produzir e compartilhar conhecimento.

Quem domina fundamentos de arquitetura, modelagem de dados, sistemas transacionais e processos críticos — características típicas do ecossistema IBM Z — possui uma vantagem significativa ao trabalhar com essas novas ferramentas. Afinal, a IA precisa de contexto, critérios e boas decisões, e esses elementos continuam sendo responsabilidade do profissional.


Conclusão — O verdadeiro diferencial está na engenharia, não na ferramenta

As "100 Claude Tips" são muito mais do que uma coleção de atalhos. Elas representam um mapa de maturidade para quem deseja extrair valor real da Inteligência Artificial.

No início, usamos a IA como uma calculadora sofisticada.

Depois, como um mecanismo de busca conversacional.

Em seguida, como um assistente de programação.

Mas o próximo passo já está acontecendo: transformar a IA em um ambiente integrado de engenharia, capaz de compreender projetos, seguir padrões corporativos, colaborar com equipes, acessar ferramentas externas, automatizar processos e participar ativamente do ciclo de desenvolvimento.

Para quem vive o universo IBM Mainframe, essa evolução não é estranha. Há décadas trabalhamos com orquestração, padronização, bibliotecas compartilhadas, controle de mudanças, segurança, automação e integração entre sistemas. Os conceitos permanecem os mesmos; o que muda é a interface, agora baseada em linguagem natural.

O Programador COBOL Padawan que compreender essa mudança deixará de enxergar o Claude apenas como um chatbot. Passará a vê-lo como um novo membro da equipe: um analista que nunca se cansa de revisar código, um arquiteto que ajuda a avaliar alternativas, um redator técnico incansável, um testador disciplinado e um parceiro de aprendizado contínuo.

No fim das contas, o maior segredo não está em conhecer as cem dicas individualmente. Está em entender que elas formam um ecossistema. Memória, Projects, Prompt Engineering, Claude Code, CLAUDE.md, Artifacts, MCP, Agentes e automações são peças de uma mesma arquitetura.

E arquiteturas bem projetadas sempre foram a especialidade dos profissionais de Mainframe.

Talvez seja por isso que nós, veteranos do IBM Z, estejamos tão bem posicionados para liderar essa nova era da Inteligência Artificial.

Porque, no fundo, continuamos fazendo o que sempre fizemos: projetar sistemas confiáveis, organizar conhecimento e transformar complexidade em soluções elegantes. A diferença é que, agora, temos um novo colega de trabalho sentado ao nosso lado — e ele atende pelo nome de Claude.

☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

 

Bellacosa Mainframe divida tecnica decisões erradas que pagamos até hoje


☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

Existe uma lenda antiga nos CPDs.

Ela diz que, em algum lugar do ambiente de produção, existe um programa COBOL que ninguém entende.

Ninguém sabe quem escreveu.

Ninguém sabe por que funciona.

Ninguém sabe o que acontece se ele parar.

Mas todos sabem de uma coisa:

ninguém tem coragem de mexer nele.

Se você trabalha em Mainframe há algum tempo, provavelmente já encontrou um desses.

Talvez ele tenha 30 mil linhas.

Talvez possua 700 GO TO.

Talvez utilize arquivos VSAM que nem aparecem mais na documentação.

Talvez tenha comentários escritos por alguém que já se aposentou há vinte anos.

E talvez ele continue processando milhões de reais por dia.

Parabéns.

Você acabou de encontrar um dos sintomas mais clássicos da dívida técnica.


O QUE É DÍVIDA TÉCNICA?

O termo foi criado por Ward Cunningham.

A ideia é simples.

Você faz uma escolha rápida hoje para ganhar velocidade.

Em troca, aceita que precisará corrigir aquilo futuramente.

É exatamente igual a um empréstimo bancário.

Você recebe um benefício imediato.

Mas depois paga juros.

No software, os juros aparecem na forma de:

  • retrabalho;

  • manutenção mais lenta;

  • defeitos;

  • incidentes;

  • dificuldade de evolução;

  • dependência de especialistas.

O problema é que muitas empresas pegam esse empréstimo todos os dias.

E quase nunca pagam.


O DIA EM QUE O SISTEMA COMEÇA A COBRAR JUROS

Imagine um programador COBOL júnior.

Recebe uma demanda urgente.

Precisa incluir um novo código de operação.

O correto seria:

  • revisar regras;

  • criar módulo reutilizável;

  • atualizar documentação;

  • executar testes.

Mas o prazo está apertado.

Então ele faz:

IF COD-OPER = '99'
   MOVE 'S' TO FLAG-ESPECIAL
END-IF.

Entrega.

Funciona.

Todos ficam felizes.

Seis meses depois surge:

Operação 98.

Depois 97.

Depois 96.

Quando alguém percebe, existe:

IF COD-OPER = '99'
OR COD-OPER = '98'
OR COD-OPER = '97'
OR COD-OPER = '96'

O programa continua funcionando.

Mas ficou pior.

Essa diferença entre funcionar e ser saudável é onde mora a dívida técnica.


COMO IDENTIFICAR DÍVIDA TÉCNICA

Os sinais são sempre parecidos.

1. Programas gigantes

Quando um COBOL possui:

  • 10 mil linhas;

  • 20 mil linhas;

  • 50 mil linhas;

ninguém consegue compreender tudo.

Complexidade gera risco.


2. Dependência de uma única pessoa

Quando você ouve:

"Somente o João conhece esse sistema."

Acenda o alerta vermelho.

O João pode tirar férias.

O João pode mudar de empresa.

O João pode se aposentar.

O sistema precisa sobreviver sem heróis.


3. Medo de alterar

Se toda mudança gera receio:

"Vamos torcer para não derrubar produção."

Existe dívida técnica.


4. Muitas correções

Quando a equipe passa mais tempo corrigindo do que evoluindo.

O sistema está pagando juros elevados.


AS PRINCIPAIS MÉTRICAS

Métricas transformam sensação em informação.

Sem métricas ninguém sabe se está melhorando.


1. LEAD TIME

Tempo entre solicitação e entrega.

Exemplo:

Pedido feito em:

01/06

Produção:

10/06

Lead Time = 9 dias

Quanto menor melhor.


2. CYCLE TIME

Tempo efetivamente gasto desenvolvendo.

Exemplo:

Demanda recebida.

Ficou parada cinco dias.

Desenvolvimento levou dois dias.

Cycle Time = 2 dias.


3. CHANGE FAILURE RATE

Percentual de mudanças que causam problemas.

Exemplo:

100 implantações.

10 causaram incidentes.

Taxa:

10%

Quanto menor melhor.


4. MTTR

Mean Time To Recovery.

Tempo médio para recuperar produção.

Exemplo:

ABEND às 10h.

Sistema normal às 11h.

MTTR = 1 hora.


5. REWORK

Retrabalho.

Mede quanto esforço foi gasto corrigindo erros.

Imagine:

100 horas trabalhadas.

25 horas corrigindo problemas.

Rework:

25%

Muito alto.


6. REFATORAÇÃO

Esforço dedicado a melhorar código existente.

Uma equipe saudável normalmente reserva tempo para:

  • limpeza;

  • reorganização;

  • modularização.


ENTENDENDO O GRÁFICO DA LINEARB

Imagine:

59% Novo Trabalho

17% Refatoração

24% Retrabalho

Significa:

A cada 100 horas:

59 horas criam valor.

17 horas melhoram qualidade.

24 horas apagam incêndios.

Quase um quarto da energia da equipe foi desperdiçada.


COMO REDUZIR DÍVIDA TÉCNICA

Agora chegamos ao ponto mais importante.


PASSO 1 — MAPEAR O PROBLEMA

Não tente resolver tudo.

Primeiro descubra:

  • quais programas mudam mais;

  • quais causam mais incidentes;

  • quais possuem maior complexidade.

Faça uma planilha simples.

ProgramaAlteraçõesIncidentes
FIN00112015
FIN002100
FIN0039512

Comece pelos maiores problemas.


PASSO 2 — CRIAR BACKLOG TÉCNICO

Muitas empresas possuem backlog funcional.

Poucas possuem backlog técnico.

Crie itens como:

  • remover código morto;

  • modularizar rotina;

  • eliminar duplicação;

  • documentar interfaces.

Essas atividades precisam ser visíveis.


PASSO 3 — REFATORAR PEQUENO

Erro clássico:

"Vamos reescrever tudo."

Não faça isso.

Melhore gradualmente.

Hoje:

  • extrair um parágrafo.

Amanhã:

  • eliminar duplicação.

Depois:

  • criar módulo reutilizável.

Pequenas vitórias acumulam grandes resultados.


PASSO 4 — DOCUMENTAR

Documentação não precisa ser um livro.

Basta responder:

  • o que faz;

  • entradas;

  • saídas;

  • dependências.

Já ajuda enormemente.


PASSO 5 — REVISÃO DE CÓDIGO

Mesmo no Mainframe.

Principalmente no Mainframe.

Checklist simples:

✓ Nome adequado

✓ Lógica clara

✓ Tratamento de erro

✓ Performance

✓ Documentação

✓ Testes


PASSO 6 — TESTES

O segredo dos sistemas modernos.

Sem testes:

refatorar é perigoso.

Com testes:

refatorar é seguro.

Mesmo em COBOL.

Ferramentas como:

  • IBM Debug Tool

  • IBM Application Discovery

  • IBM ZUnit

  • Micro Focus Unit Testing

ajudam muito.


PASSO 7 — REDUZIR COMPLEXIDADE

Pergunta mágica:

"Existe uma forma mais simples?"

Sempre existe.

Quanto mais simples:

  • menor risco;

  • menor manutenção;

  • menor custo.


FERRAMENTAS ÚTEIS

IBM Application Discovery

Mapeia dependências.

Mostra:

  • programas;

  • copybooks;

  • arquivos;

  • fluxos.

Excelente para arqueologia de sistemas.


SonarQube

Analisa qualidade.

Detecta:

  • duplicação;

  • complexidade;

  • vulnerabilidades.


Git

Mesmo para Mainframe.

Ajuda a controlar mudanças.


Jira

Controle de backlog técnico.


ServiceNow

Correlação entre incidentes e sistemas.


O SEGREDO QUE NINGUÉM CONTA

A maioria das dívidas técnicas não nasce do código.

Nasce da organização.

Promessas irreais.

Prazos impossíveis.

Mudanças constantes.

Prioridades conflitantes.

O código apenas reflete o ambiente em que foi criado.


EASTER EGG MAINFRAME

Existe um teste simples.

Abra um programa COBOL.

Role até o final.

Se encontrar:

GO TO FIM-PROGRAMA

não se assuste.

Se encontrar:

GO TO INICIO

fique atento.

Se encontrar:

GO TO PARAGRAFO-XYZ

que chama outro GO TO que chama outro GO TO...

Parabéns.

Você encontrou uma relíquia arqueológica do período Jurássico dos sistemas corporativos.


O CAMINHO DE EVOLUÇÃO DO PROGRAMADOR JÚNIOR

Nível 1:

Faz funcionar.

Nível 2:

Faz funcionar corretamente.

Nível 3:

Faz funcionar de forma simples.

Nível 4:

Faz funcionar de forma sustentável.

Nível 5:

Melhora o sistema toda vez que toca nele.

É nesse último estágio que nasce o verdadeiro arquiteto de sistemas.


A GRANDE LIÇÃO

O programador iniciante acredita que seu trabalho é escrever código.

O programador experiente descobre que seu trabalho é reduzir complexidade.

Código novo gera valor.

Mas código limpo preserva valor.

A dívida técnica não explode como um ABEND.

Ela cresce silenciosamente.

Linha após linha.

Workaround após workaround.

Correção após correção.

Até o dia em que uma mudança de cinco minutos passa a exigir três semanas.

Nesse momento os juros finalmente chegaram.

E como qualquer empréstimo antigo, quanto mais tempo você esperar para pagar, mais caro ficará.


segunda-feira, 1 de junho de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Full Fine-Tuning, LoRA, QLoRA, SFT, DPO e RLHF na Era da Inteligência Artificial

 

Bellacosa Mainframe e o fine tuning de llm

☕ Um Café no Bellacosa Mainframe

Fine-Tuning de LLMs Descomplicado

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Full Fine-Tuning, LoRA, QLoRA, SFT, DPO e RLHF na Era da Inteligência Artificial

"No Mainframe aprendemos cedo que não se recompila um sistema bancário inteiro para corrigir uma única regra de negócio. Então por que tantas pessoas fazem exatamente isso com modelos de Inteligência Artificial?" 


Introdução

Se você trabalha há algum tempo com IBM Mainframe, provavelmente já participou de alguma situação parecida.

O banco precisava alterar apenas uma regra tributária.

A alteração estava concentrada em um único programa COBOL.

Mesmo assim alguém sugeriu:

"Vamos recompilar tudo."

A reação de qualquer analista experiente seria imediata.

Para quê?

Afinal, recompilar centenas de programas significa consumir CPU, aumentar riscos, gerar mais testes, envolver homologação, aumentar o tempo de deploy e, principalmente, criar possibilidades de novos erros.

No mundo dos Large Language Models (LLMs), acontece exatamente a mesma coisa.

Muitos profissionais ouvem falar em Fine-Tuning e imaginam que exista apenas uma maneira de "ensinar" algo novo para uma IA.

Na prática, existem diversas estratégias.

Algumas alteram bilhões de parâmetros.

Outras modificam apenas alguns milhões.

Outras nem sequer alteram o modelo.

É exatamente essa diferença que separa projetos de milhares de dólares de projetos que podem ser treinados em uma única GPU doméstica.

Neste café vamos entender toda essa arquitetura utilizando comparações que fazem muito sentido para quem já viveu anos trabalhando com COBOL, CICS, DB2, VSAM e JCL.

Pegue seu café.

Hoje vamos abrir a tampa do motor da Inteligência Artificial.


Antes de falar em Fine-Tuning precisamos entender um Transformer

Imagine um programa COBOL enorme.

Não estamos falando de 3.000 linhas.

Imagine um sistema bancário com:

  • milhares de programas

  • centenas de COPYBOOKs

  • dezenas de módulos

  • chamadas CICS

  • SQL para DB2

  • VSAM

  • MQ

  • APIs REST

Agora imagine que tudo isso fosse compactado em um único conjunto gigantesco de matrizes matemáticas.

Esse conjunto é o modelo.

Um Transformer moderno possui dezenas ou centenas de camadas (Layers).

Visualmente podemos imaginar algo assim:

Entrada

↓

Embedding

↓

Layer 1

↓

Layer 2

↓

Layer 3

↓

...

↓

Layer 80

↓

Saída

Cada Layer possui milhões de parâmetros.

Juntos eles representam o conhecimento aprendido.


O que são parâmetros?

Se você nunca estudou Redes Neurais, imagine um enorme arquivo VSAM contendo bilhões de pequenos números.

Cada número representa um ajuste aprendido durante o treinamento.

Exemplo:

0.834829

↓

0.834841

A diferença parece insignificante.

Mas quando bilhões desses valores são alterados ao mesmo tempo...

O comportamento inteiro do modelo muda.

Esses números são chamados de pesos (weights).

Treinar uma IA significa simplesmente alterar esses pesos.

Nada mais.

Nada menos.


Pense como um Programador COBOL

Imagine um sistema bancário.

Você possui:

  • Programa COBOL

  • COPYBOOKS

  • CICS

  • DB2

  • JCL

Agora alguém pede:

"Ensine esse sistema a emitir PIX internacional."

Você possui diversas opções.

Pode alterar somente um COPYBOOK.

Pode alterar apenas um módulo.

Pode criar um novo programa.

Ou pode reescrever absolutamente tudo.

No universo dos LLMs acontece exatamente a mesma coisa.


O espectro do Fine-Tuning

Muitos iniciantes acreditam que Fine-Tuning é uma técnica.

Na realidade ele é um conjunto de técnicas.

Podemos organizar assim:

Prompt Engineering

↓

RAG

↓

SFT

↓

LoRA

↓

QLoRA

↓

Full Fine-Tuning

↓

DPO

↓

RLHF

Quanto mais descemos...

Maior o custo.

Maior o consumo de GPU.

Maior a complexidade.

Maior o tempo de treinamento.


Prompt Engineering

É a primeira ferramenta.

E curiosamente...

É a mais barata.

Você não altera absolutamente nada no modelo.

É como escrever uma JCL melhor.

O programa continua exatamente igual.

Você apenas fornece instruções mais inteligentes.

Exemplo:

Você é um especialista em COBOL IBM Enterprise COBOL 6.5.

Explique COMP-3.

Utilize exemplos bancários.

Responda em português.

Nenhum parâmetro foi alterado.

Nenhum peso foi modificado.

Mesmo assim a qualidade melhora bastante.


RAG

Agora imagine outra situação.

Seu programa COBOL precisa consultar um novo cadastro.

Você faria o quê?

Reescreveria todo o sistema?

Claro que não.

Bastaria consultar um novo banco de dados.

É exatamente isso que faz o RAG.

Pergunta

↓

Busca documentos

↓

Envia ao LLM

↓

Resposta

O modelo continua congelado.

Quem muda é apenas o conhecimento disponível durante a consulta.

Por isso dizemos:

RAG adiciona memória.

Não inteligência.


Quando NÃO devemos fazer Fine-Tuning

Esse talvez seja o maior erro da indústria.

Imagine que sua empresa possui:

  • manuais

  • normas

  • PDFs

  • contratos

  • documentação interna

Alguém diz:

"Vamos treinar um LLM com tudo isso."

Provavelmente está desperdiçando dinheiro.

RAG resolve praticamente todos esses casos.


Full Fine-Tuning

Agora chegamos ao método clássico.

Todos os parâmetros são atualizados.

Visualmente:

Layer 1

Treina

↓

Layer 2

Treina

↓

Layer 3

Treina

↓

...

↓

Layer N

Treina

Nada permanece congelado.

Tudo muda.


Por que isso é tão caro?

Vamos imaginar um modelo de 70 bilhões de parâmetros.

Todos eles precisarão:

  • armazenar gradientes

  • calcular derivadas

  • atualizar pesos

  • salvar checkpoints

Isso exige dezenas de GPUs profissionais.

Em muitos casos:

Centenas.


Analogia Mainframe

É como recompilar:

  • COBOL

  • PL/I

  • Natural

  • CICS

  • MQ

  • DB2

  • JCL

  • COPYBOOKS

Tudo.

Mesmo que apenas um programa precisasse mudar.

Faz sentido?

Na maioria das vezes...

Não.


Onde Full Fine-Tuning ainda faz sentido?

Modelos médicos.

Modelos militares.

Modelos científicos.

Modelos jurídicos extremamente especializados.

Ou quando estamos criando um novo modelo base.

Fora isso...

Existem alternativas melhores.


A Revolução Chamada LoRA

Em 2021 surgiu uma ideia brilhante.

E se...

Em vez de alterar bilhões de parâmetros...

Nós adicionássemos pequenas correções?

Foi exatamente isso que o artigo LoRA propôs.

O modelo original permanece intacto.

Quem aprende são pequenos adaptadores.


Visualmente:

Modelo Original

↓

Congelado

+

Adaptadores

↓

Aprendem

O que significa Low Rank?

Aqui entra um pouco de matemática.

Imagine uma matriz enorme:

4096 x 4096

Em vez de aprender tudo isso...

LoRA aprende duas matrizes muito menores.

4096 x 16

+

16 x 4096

A multiplicação das duas aproxima a alteração necessária.

Resultado?

Muito menos parâmetros.

Muito menos memória.

Muito menos GPU.


Analogia COBOL

Imagine um programa de 40.000 linhas.

Você não altera tudo.

Você cria uma rotina adicional.

Algo parecido com um módulo externo.

Na execução...

O sistema utiliza:

Programa Original

Nova Rotina

Essa nova rotina corresponde ao adaptador LoRA.


Vantagens do LoRA

Economia.

Rapidez.

Facilidade.

Possibilidade de possuir dezenas de especializações diferentes para o mesmo modelo.

Imagine um único Llama.

E vários LoRAs.

Llama

↓

LoRA Jurídico

↓

LoRA Médico

↓

LoRA COBOL

↓

LoRA DevOps

↓

LoRA SAP

Todos compartilham exatamente o mesmo modelo base.


QLoRA

Agora vem outra inovação.

E se...

Além de congelar o modelo...

Nós comprimíssemos sua memória?

É isso que faz o QLoRA.

O modelo base é armazenado em apenas 4 bits.

Mas atenção.

Esse é um detalhe extremamente importante.

Os adaptadores continuam treinando normalmente em maior precisão, como FP16 ou BF16.

Isso evita perda excessiva de qualidade durante o aprendizado.


Quantização

Imagine uma fotografia.

Original:

16 milhões de cores.

Depois:

256 cores.

Ela ocupa muito menos espaço.

Com os modelos acontece algo semelhante.

Menos bits.

Menos memória.

Mais eficiência.


Analogia Mainframe

É como compactar um dataset utilizando um formato extremamente eficiente.

O conteúdo continua disponível.

Mas ocupa muito menos disco.


SFT – Supervised Fine-Tuning

Aqui começamos a ensinar comportamento.

Não conhecimento.

A diferença é enorme.

Imagine um professor.

Ele entrega:

Pergunta.

Resposta correta.

Pergunta.

Resposta correta.

Pergunta.

Resposta correta.

O modelo aprende imitando.

Exemplo:

Pergunta

Explique VSAM.

↓

Resposta ideal.

↓

Treinamento.

Onde usamos SFT?

Chatbots corporativos.

Assistentes técnicos.

Documentação.

Atendimento.

Programação.

Explicações.

Tudo isso normalmente começa com SFT.


DPO – Direct Preference Optimization

Imagine que existam duas respostas.

Resposta A.

Resposta B.

Um especialista diz:

"A ficou muito melhor."

O DPO aprende exatamente isso.

Ele não precisa calcular recompensas complexas.

Ele apenas aprende qual saída deve ser preferida.

É extremamente elegante.


Analogia COBOL

Imagine dois programas.

Os dois compilam.

Os dois executam.

Mas apenas um segue corretamente a especificação do banco.

O DPO aprende a favorecer esse comportamento.


RLHF

Agora chegamos ao método mais sofisticado.

Reinforcement Learning from Human Feedback.

O fluxo é enorme.

Modelo

↓

Respostas

↓

Humanos avaliam

↓

Reward Model

↓

PPO

↓

Novo treinamento

Existe inclusive um segundo modelo.

O Reward Model.

Ele aprende a dar notas.

Depois outro algoritmo utiliza essas notas para melhorar o modelo principal.

É poderoso.

Mas extremamente caro.


Por que DPO ficou tão popular?

Porque elimina boa parte dessa complexidade.

Em muitos cenários.

SFT + DPO produz resultados muito próximos ao RLHF.

Com muito menos custo.


O maior erro das empresas

Muitas organizações ainda pensam assim:

Preciso melhorar o modelo.

↓

Fine-Tuning.

Essa pergunta está errada.

A pergunta correta é:

"O que realmente precisa mudar?"

Talvez apenas o prompt.

Talvez apenas o RAG.

Talvez um LoRA.

Talvez um SFT.

Talvez nenhum treinamento.


O que a imagem não mostra

O universo de PEFT (Parameter Efficient Fine-Tuning) vai muito além do LoRA.

Hoje existem técnicas como:

  • AdaLoRA

  • DoRA

  • IA³

  • Prefix Tuning

  • Prompt Tuning

  • P-Tuning v2

  • VeRA

  • LoKr

  • LoHa

  • OFT

  • BOFT

Todas elas têm o mesmo objetivo:

Treinar menos.

Aprender mais.

Consumir menos GPU.


Misturando Adaptadores

Outra grande vantagem.

Você pode carregar múltiplos adaptadores.

Imagine:

Modelo Base

↓

LoRA Financeiro

↓

LoRA RH

↓

LoRA Jurídico

↓

LoRA Mainframe

Dependendo da tarefa...

Você ativa apenas o adaptador correspondente.

É como carregar módulos diferentes em uma aplicação COBOL sem alterar o núcleo do sistema.


Catastrophic Forgetting

No Full Fine-Tuning existe um risco importante.

Ao aprender demais um novo domínio...

O modelo pode esquecer conhecimentos antigos.

É o chamado Catastrophic Forgetting.

Como o LoRA preserva o modelo original congelado, esse problema tende a ser muito menor.


O Futuro

A tendência da indústria é clara.

Pouquíssimas empresas treinam modelos gigantes do zero.

A maioria utiliza modelos abertos como:

  • Llama

  • Mistral

  • Qwen

  • Gemma

  • DeepSeek

Depois aplica:

  • Prompt Engineering

  • RAG

  • LoRA

  • QLoRA

  • SFT

  • DPO

Conseguindo resultados excelentes com custos muito menores.


O Café do Bellacosa ☕

Quando comecei minha carreira em Mainframe, aprendi uma lição que continua verdadeira décadas depois.

O melhor engenheiro não é aquele que modifica mais código.

É aquele que modifica apenas o necessário.

Essa filosofia aparece em praticamente tudo que fazemos em TI.

No COBOL, evitamos recompilar aplicações inteiras para uma pequena mudança de negócio.

No DB2, preferimos ajustar um índice ou um plano de acesso antes de reescrever consultas complexas.

No CICS, alteramos uma transação ou um programa específico, não toda a região.

No z/OS, aplicamos um PTF em vez de reinstalar o sistema operacional.

Na Inteligência Artificial, a lógica é exatamente a mesma.

Nem todo problema exige Full Fine-Tuning.

Nem todo projeto precisa de RLHF.

Muitas vezes, um bom Prompt Engineering resolve o problema. Em outras, um RAG bem construído fornece o conhecimento necessário. Quando o desafio é adaptar o comportamento do modelo, LoRA ou QLoRA costumam oferecer uma relação extraordinária entre custo e benefício. Se o objetivo é ensinar exemplos de respostas ideais, o SFT é o caminho natural. E quando precisamos alinhar preferências de forma eficiente, o DPO surge como uma alternativa elegante ao complexo pipeline do RLHF.

O verdadeiro arquiteto de IA não escolhe a ferramenta mais sofisticada.

Escolhe a ferramenta mais adequada.

Assim como um bom programador COBOL sabe que nem toda alteração exige recompilar milhares de programas, um bom engenheiro de IA entende que o segredo não está em treinar mais, mas em treinar melhor.

No fim das contas, Fine-Tuning não é uma única técnica. É um conjunto de estratégias, cada uma com objetivos, custos e impactos diferentes. Compreender o que realmente está sendo atualizado dentro do modelo é a diferença entre um projeto sustentável e um desperdício de GPUs, tempo e dinheiro.

E talvez essa seja a maior lição deste café: a evolução da Inteligência Artificial não elimina os princípios da Engenharia de Software que aprendemos no Mainframe. Pelo contrário, ela os reforça. Planejamento, eficiência, reutilização, modularidade e otimização continuam sendo as bases dos grandes sistemas — apenas mudaram de cenário.

Porque, seja ajustando um programa COBOL em um IBM Z ou adaptando um LLM de bilhões de parâmetros, a pergunta continua a mesma:

"O que realmente precisa ser alterado?"

Quando você sabe responder a essa pergunta, deixa de apenas usar Inteligência Artificial e passa a projetá-la com a mesma disciplina e maturidade que fizeram do Mainframe a plataforma mais confiável da história da computação.

Reconhecimento pelos 5 anos no DIO Global - Digital Innovation One

 

Bellacosa Mainframe DIO Global 5 anos

O DIO Global faz 5 anos esse mês. E quando a gente olhar para essa data de verdade, o que aparece não é um número. São rostos. 

São mais de 50.000 profissionais que foram contratados em empresas de tecnologia através da DIO. Pessoas que estavam em transição de carreira, que buscavam a primeira vaga, que precisavam do inglês certo para competir com qualquer profissional do mundo. Que tinham talento, mas precisavam de um caminho. 

Você ajudou a construir esse caminho

O conteúdo que você produziu chegou a profissionais que mudaram de vida por conta do que aprenderam. Isso é raro. A maioria das pessoas passa anos trabalhando sem saber ao certo o impacto do que faz. Você sabe. 

Cinco anos é tempo suficiente para olhar para trás e ter clareza sobre quem construiu isso junto. E o seu nome está nessa lista

Em anexo você encontra um reconhecimento de gratidão da DIO pelo que você fez pela educação e pela carreira de tanta gente que confiou nesse projeto.  
 
Nosso agradecimento e reconhecimento por você ter impactado milhares de pessoas por meio da educação e empregabilidade. 
 
Obrigada pela sua contribuição.


DIO
Learning & Curriculum Lead

---------------------------------------------------------------------------------------------------------------------------------

Gratidão

Alcançar cinco anos de participação na DIO (Digital Innovation One) representa muito mais do que uma marca temporal. É o reconhecimento de uma trajetória construída por meio de aprendizado contínuo, troca de experiências e desenvolvimento profissional dentro de uma das maiores comunidades de tecnologia do Brasil.

Ao longo desse período, milhares de profissionais utilizaram a plataforma para expandir conhecimentos em áreas como programação, computação em nuvem, inteligência artificial, ciência de dados, segurança da informação, DevOps, arquitetura de sistemas e diversas outras especialidades do mercado tecnológico. A DIO tornou-se uma ponte entre conhecimento e oportunidades, aproximando estudantes, profissionais e empresas.

Receber um reconhecimento pelos cinco anos de jornada simboliza dedicação, persistência e compromisso com a evolução constante. Em um setor que se transforma diariamente, manter-se atualizado é um diferencial fundamental para enfrentar novos desafios e acompanhar as mudanças do mercado.

Além dos cursos e certificações, a experiência envolve participação em comunidades, eventos, bootcamps e iniciativas colaborativas que fortalecem o networking e o compartilhamento de conhecimento.

Esse marco também representa uma oportunidade para olhar para trás e perceber o quanto foi conquistado ao longo dos anos. Mais do que um certificado ou homenagem, os cinco anos na DIO refletem uma trajetória de crescimento, aprendizado contínuo e paixão pela tecnologia, valores essenciais para quem constrói uma carreira sólida na área de TI.

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

 

Bellacosa Mainframe e o monstro da divida tecnica 

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

"O sistema funciona perfeitamente. Só ninguém sabe como."

Se você trabalha com Mainframe há algum tempo, provavelmente já ouviu frases como:

  • "Não mexe nisso que funciona."

  • "Esse programa está em produção há 20 anos."

  • "Só o João sabe alterar esse módulo."

  • "Depois a gente documenta."

  • "Precisamos entregar hoje."

Parabéns.

Você acabou de encontrar alguns dos maiores sintomas de uma das doenças mais comuns da tecnologia moderna:

A Dívida Técnica.

E não, ela não acontece apenas em Java, Python ou aplicações web modernas.

Na verdade, muitos dos maiores casos de dívida técnica do planeta estão rodando neste exato momento em sistemas COBOL responsáveis por bancos, seguradoras, governos, companhias aéreas e bolsas de valores.

Vamos entender o que é, como identificar, controlar e principalmente como sobreviver a ela.


O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida Técnica é o custo futuro gerado quando escolhemos uma solução rápida hoje em vez da melhor solução possível.

Imagine que você recebeu uma demanda urgente.

O gerente aparece correndo:

"Precisamos colocar essa alteração em produção amanhã."

Você sabe que o correto seria:

  • revisar a arquitetura;

  • atualizar documentação;

  • criar casos de teste;

  • revisar impactos;

  • atualizar fluxogramas.

Mas o prazo não permite.

Então você faz um ajuste rápido.

Entrega.

Todo mundo feliz.

Até que seis meses depois alguém precisa alterar novamente aquele trecho.

Agora ninguém entende mais nada.

A dívida venceu.

E os juros começaram a ser cobrados.


A ANALOGIA COM O CARTÃO DE CRÉDITO

A comparação mais famosa é com uma dívida financeira.

Quando você compra algo parcelado:

Você ganha agora.

Mas paga depois.

Na dívida técnica acontece exatamente o mesmo.

Você ganha:

  • velocidade;

  • prazo;

  • entrega rápida.

Mas paga depois com:

  • bugs;

  • retrabalho;

  • manutenção cara;

  • incidentes de produção.

Quanto mais tempo passa, maiores ficam os juros.


O COBOL NÃO CRIA DÍVIDA TÉCNICA

Essa é uma das maiores injustiças da informática.

Muitos dizem:

"Cobol é dívida técnica."

Errado.

COBOL não é dívida técnica.

COBOL mal mantido é dívida técnica.

Existem programas COBOL escritos há 30 anos que continuam:

  • legíveis;

  • documentados;

  • organizados;

  • eficientes.

E existem aplicações modernas escritas há seis meses que já parecem um filme de terror.

A linguagem não é o problema.

A disciplina é.


COMO A DÍVIDA TÉCNICA NASCE

Ela normalmente surge de quatro formas.

1. Pressão por prazo

O caso mais comum.

"Entrega primeiro."

"Arruma depois."

O problema é que o depois quase nunca chega.


2. Falta de documentação

O desenvolvedor conhece tudo.

Então ele pensa:

"Não preciso documentar."

Dois anos depois ele muda de empresa.

Agora ninguém entende o programa.


3. Correções emergenciais

Produção caiu.

Cliente está ligando.

Diretoria está nervosa.

O objetivo vira apenas:

"Faça voltar."

Nesse momento quase ninguém pensa em qualidade.


4. Sistemas legados

Bibliotecas antigas.

COPYBOOKs herdados.

Macros esquecidas.

JCLs copiados durante décadas.

Tudo isso acumula dívida.


EXEMPLO REAL DE DÍVIDA TÉCNICA EM COBOL

Imagine um cálculo de desconto.

Versão original:

IF CLIENTE-VIP
   COMPUTE DESCONTO = VALOR * 0.15
END-IF

Simples.

Legível.

Agora passam dez anos.

Novas regras surgem.

Resultado:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...

Mais tarde:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
ELSE
IF REGIAO = 'S'
...

Depois de centenas de mudanças:

Ninguém sabe mais como o cálculo funciona.

O programa funciona.

Mas ninguém entende.

Isso é dívida técnica.


OS SINTOMAS MAIS PERIGOSOS

Se você encontrar estes sinais, ligue o alerta.

Programas gigantes

Mais de 10.000 linhas.

COPYBOOKs duplicados

A mesma estrutura em vários lugares.

JCLs clonados

Mudam apenas o nome do JOB.

Falta de comentários

Tudo depende da memória dos analistas.

Testes manuais

Ninguém consegue validar rapidamente.

Dependência de uma pessoa

"O Carlos sabe."

Quando você ouve isso, existe dívida técnica.


O EFEITO JUROS COMPOSTOS

Aqui está a parte assustadora.

Dívida técnica cresce de forma parecida com juros compostos.

Um bug gera:

  • remendo;

  • novo remendo;

  • ajuste do remendo;

  • correção da correção.

Depois de alguns anos ninguém consegue alterar sem medo.

O custo explode.


COMO MAPEAR DÍVIDA TÉCNICA

Primeiro passo:

Pare de adivinhar.

Crie um inventário.

Faça uma planilha simples.

Colunas:

  • Sistema

  • Programa

  • Problema

  • Impacto

  • Complexidade

  • Prioridade

Exemplo:

ProgramaProblemaImpacto
COBCLI01Sem documentaçãoAlto
COBFAT0212.000 linhasAlto
COBPAG03Sem testesMédio

Agora a dívida virou algo visível.


MÉTRICAS IMPORTANTES

Um programador júnior deve aprender a medir.

Algumas métricas úteis:

Número de ABENDs

Se cresce continuamente:

há algo errado.


Tempo de correção

Quanto tempo leva para corrigir um incidente?

Quanto maior, maior a dívida.


Quantidade de módulos sem documentação

Métrica simples e poderosa.


Cobertura de testes

Quanto mais baixa, maior o risco.


FERRAMENTAS ÚTEIS NO MAINFRAME

Muitos iniciantes acham que Mainframe não possui ferramentas modernas.

Possui.

E muitas.

IBM Application Discovery

Mapeia dependências.

Excelente para sistemas gigantes.


IBM ADDI

Application Discovery and Delivery Intelligence.

Mostra relacionamentos entre:

  • COBOL

  • JCL

  • DB2

  • CICS


IBM Debug Tool

Ajuda a entender comportamento de programas complexos.


IBM Fault Analyzer

Investiga ABENDs.


IBM File Manager

Analisa arquivos rapidamente.


IBM Dependency Based Build

Automação moderna para pipelines Mainframe.


COMO REDUZIR A DÍVIDA

Agora vem a parte prática.


Passo 1 – Pare de criar dívida nova

Antes de pagar a antiga.

Evite criar mais.

Parece óbvio.

Mas é onde tudo começa.


Passo 2 – Refatore pequenos trechos

Não tente reescrever tudo.

Ataque pequenas áreas.

Exemplo:

  • nomes ruins;

  • IFs excessivos;

  • parágrafos gigantes.


Passo 3 – Documente enquanto aprende

Cada descoberta vira documentação.

Não espere um projeto oficial.


Passo 4 – Automatize testes

Mesmo testes simples ajudam.

Menos medo de alterar.

Mais velocidade.


Passo 5 – Padronize

Defina padrões.

Por exemplo:

  • nomenclatura;

  • comentários;

  • estrutura de programas;

  • organização de COPYBOOKs.


O ERRO MAIS COMUM DOS JUNIORES

Achar que refatorar significa reescrever tudo.

Não.

Refatoração significa melhorar sem alterar comportamento.

Você limpa.

Organiza.

Simplifica.

Sem mudar resultado.


O SEGREDO DOS ANALISTAS SENIORES

Muitos iniciantes acreditam que profissionais experientes sabem tudo.

Não sabem.

A diferença é que eles:

  • documentam mais;

  • investigam melhor;

  • evitam atalhos perigosos;

  • controlam a dívida técnica.

O conhecimento não está apenas no código.

Está na disciplina.


EASTER EGG DOS MAINFRAMEIROS

Se encontrar um comentário parecido com:

* NÃO REMOVER
* FUNCIONA ASSIM DESDE 1994

Você provavelmente encontrou um artefato arqueológico corporativo.

Trate com respeito.

Mas investigue.

Porque muitas vezes ele esconde uma dívida técnica histórica.


A REGRA DOS 5 MINUTOS

Uma dica poderosa.

Se você gastou cinco minutos para entender algo complicado:

documente.

O próximo desenvolvedor agradecerá.

E talvez esse próximo desenvolvedor seja você daqui a seis meses.


COMO EVOLUIR NA CARREIRA ATRAVÉS DA DÍVIDA TÉCNICA

Os melhores profissionais não são os que criam mais código.

São os que reduzem complexidade.

Quando você aprende a:

  • mapear problemas;

  • documentar;

  • simplificar;

  • automatizar;

  • refatorar;

você deixa de ser apenas um programador.

Você passa a ser um engenheiro de software.


CONCLUSÃO

Dívida técnica não é um bug.

Não é um ABEND.

Não é um programa COBOL antigo.

Ela é o resultado de decisões acumuladas ao longo do tempo.

Algumas são necessárias.

Outras são perigosas.

O segredo não é eliminar toda dívida técnica.

Isso é impossível.

O segredo é conhecê-la, monitorá-la e pagá-la antes que ela assuma o controle do sistema.

Porque, no final das contas, o verdadeiro problema não é aquele programa COBOL de 1987.

O problema é ninguém mais entender por que ele ainda funciona.

E quando esse dia chega...

o próximo chamado de produção costuma acontecer às 03:17 da manhã de um domingo.

Aproveite e conheça BACKLOG

https://eljefemidnightlunch.blogspot.com/2025/01/backlog-o-arquivo-secreto-que-separa-um.html

Backlog


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