Translate

Mostrar mensagens com a etiqueta bancos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta bancos. Mostrar todas as mensagens

sábado, 13 de junho de 2026

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

 

Bellacosa Mainframe e a crise silenciosa do COBOL

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

"O problema não é que os sistemas COBOL vão parar amanhã. O problema é que, quando precisarmos deles depois de amanhã, talvez não haja gente suficiente para entendê-los."


Introdução: O paradoxo que desafia a lógica

Existe uma frase repetida há décadas no mundo da tecnologia:

"COBOL está morrendo."

Curiosamente, essa frase é tão antiga que já deveria ter morrido antes do próprio COBOL.

Nos anos 1980 diziam isso.

Nos anos 1990 também.

Nos anos 2000 então, parecia inevitável.

Veio Java.

Veio .NET.

Veio Python.

Veio Cloud.

Vieram Microservices.

Vieram Containers.

Vieram APIs.

Veio Inteligência Artificial.

E o COBOL continua processando bilhões de transações diariamente.

Mas há algo diferente acontecendo agora.

Pela primeira vez na história, o risco não é tecnológico.

O risco é humano.

Não estamos falando da morte da linguagem.

Estamos falando da aposentadoria das pessoas que sabem usá-la.

E isso muda completamente a discussão.


O grande erro dos anos 90

Durante os anos 1990 aconteceu um fenômeno curioso.

Universidades do mundo inteiro decidiram que COBOL não fazia mais sentido.

Os currículos migraram para:

  • C++

  • Java

  • Redes

  • Sistemas Distribuídos

  • Orientação a Objetos

Naquele momento parecia uma decisão racional.

A internet estava explodindo.

O mundo falava sobre websites.

Empresas de tecnologia surgiam diariamente.

Tudo indicava que os sistemas legados seriam substituídos rapidamente.

Mas havia um detalhe que ninguém percebeu.

Substituir um sistema crítico não é como trocar um aplicativo de celular.


O mito da reescrita fácil

Imagine um sistema bancário criado em 1975.

Durante cinquenta anos ele recebeu:

  • correções

  • adaptações

  • mudanças regulatórias

  • novos produtos

  • fusões bancárias

  • ajustes tributários

  • exceções operacionais

Hoje esse sistema possui milhões de linhas de código.

Mas o código é apenas a ponta do iceberg.

O verdadeiro patrimônio é o conhecimento de negócio embutido nele.

Muitas regras não estão documentadas.

Elas vivem no código.

E pior.

Muitas vezes nem o próprio negócio sabe que elas existem.


Exemplo real

Uma seguradora decidiu migrar um sistema COBOL para Java.

Projeto estimado:

  • 2 anos

  • US$ 20 milhões

Resultado:

  • 7 anos

  • mais de US$ 100 milhões

E ainda assim precisaram manter parte do sistema original funcionando.

Por quê?

Porque descobriram regras escondidas no código que ninguém conhecia.

Uma delas calculava benefícios de clientes antigos utilizando uma legislação que já nem existia mais.

Mas aqueles contratos continuavam válidos.

Remover a regra geraria processos judiciais.


O COBOL virou infraestrutura invisível

Hoje ninguém acorda pensando em COBOL.

Da mesma forma que ninguém acorda pensando em:

  • rede elétrica

  • abastecimento de água

  • sistema de esgoto

Mas todos percebem quando param de funcionar.

O COBOL tornou-se uma camada invisível da sociedade moderna.


Quando você faz um PIX

Existe grande chance de algum processamento acabar passando por sistemas mainframe.

Quando usa cartão de crédito

Mainframe.

Quando recebe aposentadoria

Mainframe.

Quando paga imposto

Mainframe.

Quando consulta benefícios governamentais

Mainframe.

Quando uma companhia aérea processa reservas

Mainframe.


Muitas pessoas acreditam que esses sistemas foram substituídos.

Na realidade, na maioria dos casos, eles foram encapsulados.

Colocou-se uma API na frente.

Um aplicativo bonito.

Uma interface moderna.

Mas atrás continua existindo um programa COBOL executando a lógica crítica.


O IRS e o sistema de 60 anos

Um dos exemplos mais famosos é o Internal Revenue Service (IRS) dos Estados Unidos.

Quando falamos do IRS estamos falando do órgão responsável pela arrecadação federal americana.

Grande parte da infraestrutura principal foi construída durante os anos 1960.

Pense nisso.

Quando parte desses sistemas nasceu:

  • o homem ainda não havia chegado à Lua;

  • a internet não existia;

  • computadores ocupavam salas inteiras;

  • discos rígidos tinham capacidade ridícula para os padrões atuais.

Mesmo assim esses sistemas continuam funcionando.

Isso não é apenas impressionante.

É quase inacreditável.


O custo da modernização

Existe outra ilusão comum.

A ideia de que basta investir dinheiro para resolver o problema.

Se fosse verdade, ele já estaria resolvido.

Governos e bancos gastaram bilhões tentando modernizar sistemas legados.

Alguns tiveram sucesso.

Muitos não.


O motivo

A dificuldade não está em programar.

A dificuldade está em entender.

Imagine receber um programa COBOL escrito em 1978.

O programador original já morreu.

O analista de negócios aposentou-se.

A documentação desapareceu.

Os requisitos originais não existem.

Agora descubra exatamente o que ele faz.

Sem errar.

Porque um erro pode impactar:

  • milhões de aposentados;

  • bilhões de dólares;

  • benefícios sociais;

  • arrecadação tributária.


A aposentadoria em massa

Aqui está o ponto mais preocupante.

O profissional COBOL médio não tem 25 anos.

Nem 35.

Nem 45.

Em muitos lugares ele já ultrapassou os 55 anos.

Isso significa que estamos diante de uma transição geracional gigantesca.

Imagine uma empresa com:

  • 100 especialistas COBOL

Se 10% se aposentam por ano:

Ano 1:
100 → 90

Ano 5:
90 → 59

Ano 10:
59 → 35

Ano 15:
35 → 20

Ano 20:
20 → 12

O conhecimento evapora rapidamente.


O conhecimento que não está nos livros

Aqui existe algo ainda mais perigoso.

Muitas pessoas confundem saber COBOL com saber sistemas COBOL.

São coisas completamente diferentes.

Aprender COBOL pode levar semanas.

Dominar um ambiente corporativo pode levar décadas.


Exemplo

Um desenvolvedor pode aprender:

ADD A TO B GIVING C.

em poucos minutos.

Mas compreender:

  • JES2

  • CICS

  • DB2

  • IMS

  • RACF

  • VSAM

  • MQ

  • JCL

  • SMF

  • DFSORT

e a integração entre todos eles...

isso pode exigir anos.


O verdadeiro gargalo não é COBOL

Essa é uma observação que faço frequentemente.

As manchetes falam:

"Faltam programadores COBOL."

Mas essa frase é simplista.

O que realmente falta são profissionais capazes de entender ecossistemas corporativos complexos.


Porque um especialista de verdade entende:

  • negócio

  • arquitetura

  • operação

  • performance

  • segurança

  • recuperação de desastres

Ele não é apenas programador.

Ele é guardião do conhecimento institucional.


A inteligência artificial vai resolver?

Pergunta inevitável em 2026.

A resposta é:

Sim.

E não.


Onde a IA ajuda

Hoje a IA consegue:

  • explicar código COBOL;

  • converter COBOL para Java;

  • gerar documentação;

  • identificar dependências;

  • acelerar manutenção.

Isso é extraordinário.


Onde a IA não resolve

A IA não sabe:

  • por que determinada regra existe;

  • qual acordo político gerou aquela exceção;

  • qual legislação de 1987 originou um cálculo;

  • qual cliente depende daquela lógica.

Esse conhecimento continua humano.


O caso brasileiro

Como brasileiro e profissional de mainframe, vejo um cenário interessante.

O Brasil está em posição melhor do que muitos países.

Por quê?

Porque nunca abandonou completamente a formação em tecnologias corporativas.

Temos profissionais atuando em:

  • bancos;

  • seguradoras;

  • governo;

  • telecomunicações.

Instituições como:

  • Banco do Brasil

  • Caixa

  • Bradesco

  • Itaú

  • Santander

  • Serpro

  • Dataprev

continuam mantendo grandes ambientes mainframe.

Isso criou uma continuidade geracional que muitos países perderam.


O erro estratégico das empresas

Durante anos muitas organizações enxergaram o mainframe apenas como custo.

E isso gerou decisões perigosas.

Redução de equipes.

Pouco treinamento.

Ausência de sucessão.

Falta de documentação.

Perda de conhecimento.


O resultado?

Quando um especialista se aposenta, descobre-se que ele era o único que compreendia determinado processo crítico.

Já vi situações em que uma única pessoa entendia completamente um sistema responsável por movimentar bilhões.

Quando ela saiu, a empresa entrou em pânico.


O mito do profissional velho

Existe também um preconceito silencioso.

Muita gente associa COBOL a tecnologia ultrapassada.

Logo associa seus profissionais a algo ultrapassado.

Isso é um erro monumental.

Os melhores especialistas que conheci dominavam:

  • COBOL

  • Java

  • APIs

  • Linux

  • Cloud

  • Containers

  • DevOps

Eles simplesmente entendiam também a camada que sustenta o mundo.


O que deveria estar acontecendo

As organizações mais inteligentes já perceberam o problema.

Elas estão investindo em:

Mentoria reversa

Veteranos treinando jovens.

Pair Programming

Transferência contínua de conhecimento.

Documentação moderna

Captura do conhecimento tácito.

IA aplicada ao legado

Aceleração da curva de aprendizado.

Programas universitários

Retorno do ensino de COBOL.


Uma comparação com a engenharia civil

Imagine uma ponte construída há 60 anos.

Ela continua suportando milhões de veículos.

Ninguém diria:

"Vamos demolir porque é antiga."

Primeiro analisamos:

  • estabilidade;

  • manutenção;

  • custo;

  • risco.

Sistemas COBOL deveriam ser vistos da mesma forma.

A idade não é o problema.

A capacidade de manutenção é.


O verdadeiro risco para o futuro

A pergunta não é:

"Quando o COBOL vai acabar?"

A pergunta correta é:

"Quem vai entender os sistemas quando os especialistas atuais não estiverem mais aqui?"

Essa é uma questão muito mais séria.

Porque linguagens podem ser aprendidas.

Conhecimento institucional não pode ser recriado facilmente.


A visão Bellacosa Mainframe

Depois de décadas observando o mundo corporativo, cheguei a uma conclusão simples.

O futuro não será COBOL versus IA.

Nem Mainframe versus Cloud.

Nem Legado versus Modernização.

O futuro pertence à integração.

Os vencedores serão aqueles capazes de unir:

  • conhecimento histórico;

  • arquitetura moderna;

  • inteligência artificial;

  • plataformas corporativas.

O profissional mais valioso da próxima década não será aquele que conhece apenas a tecnologia nova.

Nem aquele que conhece apenas a tecnologia antiga.

Será aquele que consegue traduzir um mundo para o outro.


Conclusão: a crise silenciosa é real

A grande ironia da história é que o COBOL nunca foi tão invisível e tão importante ao mesmo tempo.

Ele está escondido atrás de aplicativos modernos, APIs elegantes e interfaces digitais sofisticadas.

Mas continua sustentando partes fundamentais da economia global.

O verdadeiro desafio não é técnico.

É humano.

A cada aposentadoria, perde-se mais do que um programador.

Perde-se contexto.

Perde-se história.

Perde-se conhecimento acumulado ao longo de décadas.

E conhecimento não pode ser recompilado.

A crise silenciosa do COBOL não é sobre uma linguagem criada em 1959.

É sobre a transferência de conhecimento de uma geração para outra.

Se governos, bancos e grandes corporações não tratarem isso como prioridade estratégica, poderão descobrir tarde demais que substituir hardware é fácil, substituir software é difícil, mas substituir experiência é quase impossível.

E talvez essa seja a maior lição que o mundo da tecnologia ainda não compreendeu.

O problema nunca foi o COBOL envelhecer. O problema é que seus especialistas envelheceram primeiro. ☕🚀💻🏦


quinta-feira, 4 de junho de 2026

A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS


O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

  • 28.000 linhas

  • 134 COPYBOOKS

  • 742 parágrafos

  • Comentários da época do Plano Real

  • Um PERFORM THRU que ninguém entende

  • Um campo chamado WK-AREA1

  • Outro chamado WK-AREA2

  • Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica


O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

  • principal

  • juros

  • correção

  • multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.


EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

  • 3.000 agências

  • dezenas de fusões

  • múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.


COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.


Frase 2

"É só uma correção rápida."

Nunca é.


Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.


Frase 4

"Não mexe porque funciona."

O terror dos bancos.


OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

  • GOTO excessivo

  • PERFORM THRU gigantes

  • variáveis sem significado

  • duplicação


2. Arquitetura

Problemas maiores.

Exemplos:

  • sistemas monolíticos

  • dependências excessivas

  • integrações frágeis


3. Dados

Muito comum em bancos.

Exemplos:

  • arquivos VSAM redundantes

  • tabelas DB2 duplicadas

  • dados inconsistentes


4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

  • deploy manual

  • testes manuais

  • documentação inexistente


COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.


Sintoma 1

Mudanças simples levam semanas.


Sintoma 2

Toda alteração gera incidente.


Sintoma 3

Poucas pessoas entendem o sistema.


Sintoma 4

Ninguém quer mexer.


Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.


MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.


1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

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

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

  • mais difícil testar

  • mais difícil manter

  • maior risco

Meta saudável:

  • abaixo de 10 excelente

  • até 20 aceitável

  • acima de 30 perigoso


2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

  • 500 linhas → simples

  • 5.000 linhas → atenção

  • 20.000 linhas → investigação


3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

  • cadastro

  • empréstimo

  • cartão

  • investimentos

Quando muda uma regra:

quatro programas precisam mudar.


4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.


5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.


6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?


FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.


IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

  • dependências

  • impacto

  • análise de código

Mostra relacionamentos invisíveis.


IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

  • DevOps

  • testes

  • integração


SONARQUBE

Uma das mais famosas.

Analisa:

  • complexidade

  • duplicação

  • vulnerabilidades

Possui suporte para COBOL.


TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

  • visualização

  • debugging

  • análise


ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.


GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.


COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.


PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

  • onde está

  • quanto existe

  • qual impacto


PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.


PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.


PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.


PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.


PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.


PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.


O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.


CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.


A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

  • melhorar nomes

  • remover comentários obsoletos

  • eliminar duplicações

Pequenas melhorias acumulam enormes resultados.


O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

  • processar pagamentos

  • movimentar bilhões

  • atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.


O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"


☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

  • Internet Banking

  • Aplicativos móveis

  • Chatbots

  • APIs

  • Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.


O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

  • Portais Web

  • Gateways API

  • Aplicativos móveis

  • Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.


O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

  • Processos manuais escondidos

  • Dependência excessiva de funcionários específicos

  • Sistemas sem escalabilidade

  • Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.


☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.


O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

  • Comprar servidores

  • Instalar servidores

  • Configurar servidores

Meses de trabalho.


NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.


A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.


RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.


O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.


O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.


👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.


O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.


O DIA DO DESASTRE

Essa pessoa:

  • aposenta

  • muda de empresa

  • entra em férias

Pronto.

Agora existe um risco operacional.


O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.


O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

  • Git

  • APIs

  • DevOps

  • Cloud

  • Automação

  • CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.


O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.


UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

  • Git

  • VS Code

  • Zowe

  • APIs REST

  • Jenkins

  • SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.


UM COBOL ANTIGO É REPELENTE

Agora imagine:

  • documentação inexistente

  • deploy manual

  • FTP

  • planilhas Excel

  • mudanças sem controle

O problema não é COBOL.

É a cultura.


O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

  • hardware

  • software

  • licenças

Mas esquecem:

  • turnover

  • treinamento

  • conhecimento perdido

Esses custos podem superar os custos tecnológicos.


O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.


O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

  • agilidade

  • automação

  • integração

  • APIs

  • escalabilidade

  • experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

  • pessoas

  • conhecimento

  • processos

  • documentação

  • cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.


CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

  • documentação

  • testes

  • APIs

  • observabilidade

  • versionamento

  • arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.


domingo, 18 de agosto de 2024

Inteligência Artificial na Segurança Bancária sem Mistérios

Bellacosa Mainframe e a inteligencia artificial na seguranca bancaria


☕ Um Café no Bellacosa Mainframe

Inteligência Artificial na Segurança Bancária sem Mistérios

O Guia do Programador COBOL Padawan para Entender Biometria, Fraudes, Autenticação Contínua e os Escudos Digitais da Frota Estelar

Imagine, jovem programador COBOL Padawan, que você está sentado diante de um terminal 3270 em uma madrugada silenciosa.

Ao lado do teclado, uma caneca de café ainda quente. Na tela verde, um programa aparentemente simples processa uma transferência bancária. Ele recebe uma conta de origem, uma conta de destino, um valor e uma data. Depois de algumas validações, o sistema autoriza ou rejeita a operação.

Durante décadas, essa lógica pareceu suficiente.

O cliente informava a senha correta, o saldo era consultado, os limites eram verificados e a transação seguia seu caminho pelos corredores eletrônicos do banco.

Mas a galáxia financeira mudou.

Hoje, o usuário pode estar acessando o banco por um celular, conectado a uma rede pública, utilizando reconhecimento facial, fazendo um PIX para um novo destinatário e movimentando um valor muito diferente de seu padrão habitual.

Ao mesmo tempo, o criminoso pode possuir a senha verdadeira, o CPF, o número do telefone, documentos vazados, gravações da voz da vítima e até uma cópia artificial de seu rosto produzida por inteligência artificial.

A pergunta deixou de ser apenas:

“A senha está correta?”

Agora o banco precisa perguntar:

“Essa operação parece realmente estar sendo realizada pelo cliente?”

Essa mudança representa uma das maiores transformações na história da segurança bancária.

A segurança deixou de ser apenas um portão na entrada do sistema. Ela passou a acompanhar o cliente durante toda a jornada.

É como se os sistemas financeiros tivessem aprendido uma antiga lição da Frota Estelar:

Não basta identificar quem entrou na nave. É necessário observar o que essa pessoa faz depois de entrar.

Prepare o café, ajuste seu comunicador e abra uma nova sessão no TSO. Nossa missão será entender como inteligência artificial, biometria, autenticação multifator, análise comportamental, modelos de risco e mainframes trabalham juntos para proteger o sistema financeiro moderno.


1. O velho modelo: usuário, senha e confiança

Durante muito tempo, a segurança digital funcionou com uma lógica simples.

O usuário informava:

  • identificação;

  • senha;

  • eventualmente um código adicional.

Se tudo estivesse correto, o acesso era concedido.

Em pseudocódigo COBOL, poderíamos imaginar algo assim:

IF SENHA-INFORMADA = SENHA-CADASTRADA
    MOVE 'S' TO ACESSO-AUTORIZADO
ELSE
    MOVE 'N' TO ACESSO-AUTORIZADO
END-IF

A lógica é clara, objetiva e fácil de compreender.

O problema é que ela responde apenas a uma pergunta:

A credencial apresentada corresponde à credencial armazenada?

Ela não responde:

  • quem digitou a senha;

  • onde a senha foi digitada;

  • em qual dispositivo;

  • em qual horário;

  • em qual contexto;

  • com qual intenção;

  • se o comportamento é compatível com o histórico do cliente.

Se um criminoso roubar a senha verdadeira, o sistema tradicional poderá tratá-lo como usuário legítimo.

Esse é um dos princípios fundamentais para compreender a segurança moderna:

Uma credencial válida não significa necessariamente uma identidade legítima.

Senhas podem ser descobertas por phishing, engenharia social, vazamentos de dados, malware, observação física, reutilização em vários serviços ou manipulação psicológica.

Um cliente pode entregar voluntariamente um código de segurança acreditando estar falando com um funcionário do banco.

Nesse caso, tecnicamente, as informações estão corretas. Porém, a operação continua sendo fraudulenta.

A segurança bancária moderna precisou evoluir de uma validação estática para uma avaliação contínua de risco.


2. O criminoso não precisa arrombar a porta

Existe uma imagem clássica do invasor digital: alguém tentando quebrar uma senha, explorar uma falha ou invadir um servidor.

Esse tipo de ataque continua existindo.

Porém, muitos golpes atuais seguem um caminho mais silencioso.

O fraudador pode convencer a própria vítima a:

  • instalar um aplicativo;

  • compartilhar a tela;

  • fornecer um código;

  • transferir dinheiro;

  • cadastrar um novo dispositivo;

  • autorizar um pagamento;

  • entregar informações pessoais.

O criminoso não precisa destruir os escudos da nave.

Ele pode convencer o oficial de segurança a desativá-los.

Essa é a essência da engenharia social.

Os ataques modernos exploram não apenas sistemas, mas também emoções humanas:

  • medo;

  • urgência;

  • autoridade;

  • curiosidade;

  • ganância;

  • confiança;

  • pressão psicológica.

Uma mensagem pode dizer:

“Sua conta será bloqueada em dez minutos.”

Outra pode afirmar:

“Identificamos uma compra suspeita. Confirme seus dados agora.”

O cliente, preocupado, segue as instruções do próprio fraudador.

Por isso, proteger apenas a senha é insuficiente. O sistema precisa avaliar o contexto completo da operação.


3. A autenticação não termina no login

No modelo antigo, o login era considerado o grande momento da segurança.

A sequência era:

Identificação
      ↓
Senha
      ↓
Acesso autorizado

Depois do acesso, o sistema passava a confiar no usuário.

No modelo moderno, a sequência é muito mais ampla:

Identificação
      ↓
Senha ou credencial
      ↓
Biometria
      ↓
Dispositivo
      ↓
Localização
      ↓
Comportamento
      ↓
Análise de risco
      ↓
Monitoramento da sessão
      ↓
Reavaliação a cada operação

A autenticação tornou-se contínua.

Isso significa que uma sessão pode começar com baixo risco e, alguns minutos depois, apresentar sinais suspeitos.

Por exemplo:

  1. O cliente acessa o aplicativo em seu celular habitual.

  2. Consulta o saldo.

  3. Navega normalmente.

  4. Em seguida, cadastra um novo favorecido.

  5. Solicita um empréstimo.

  6. Transfere imediatamente todo o valor.

  7. O destino é uma conta nunca utilizada.

  8. O comportamento de digitação é diferente.

  9. O aparelho parece estar sendo controlado remotamente.

Cada ação, isoladamente, pode ser legítima.

Porém, o conjunto forma um padrão de alto risco.

A inteligência artificial consegue observar essa sequência em tempo real e recalcular a probabilidade de fraude.

Em outras palavras, o sistema deixa de perguntar apenas:

“Quem entrou?”

E passa a perguntar constantemente:

“O que está acontecendo agora?”


4. Zero Trust: nunca confiar automaticamente

Um dos conceitos mais importantes da segurança moderna é o chamado Zero Trust.

O nome pode parecer severo, mas sua lógica é bastante racional:

Nunca confie automaticamente. Sempre verifique.

Isso não significa tratar todos os clientes como criminosos.

Significa não depender de uma única prova de identidade.

Mesmo um usuário autenticado precisa continuar sendo avaliado.

Na Frota Estelar, possuir um uniforme não seria suficiente para acessar o núcleo de dobra. O sistema também verificaria:

  • identidade;

  • patente;

  • autorização;

  • localização;

  • horário;

  • missão;

  • contexto;

  • nível de risco.

No setor bancário, acontece algo semelhante.

Uma transferência pode exigir verificações adicionais conforme o risco.

Por exemplo:

EVALUATE NIVEL-RISCO
    WHEN 'BAIXO'
        PERFORM AUTORIZAR-TRANSACAO
    WHEN 'MEDIO'
        PERFORM SOLICITAR-SEGUNDO-FATOR
    WHEN 'ALTO'
        PERFORM BLOQUEAR-TRANSACAO
        PERFORM GERAR-ALERTA
    WHEN OTHER
        PERFORM ENCAMINHAR-ANALISE-MANUAL
END-EVALUATE

Esse exemplo mostra um ponto importante: segurança moderna não é apenas “permitir” ou “negar”.

Ela pode aplicar diferentes respostas:

  • liberar;

  • solicitar biometria;

  • solicitar token;

  • limitar valor;

  • atrasar a operação;

  • enviar alerta;

  • bloquear temporariamente;

  • encaminhar para análise humana.

O sistema adapta a proteção ao risco observado.


5. A IA não procura apenas criminosos

Muitas pessoas imaginam que a inteligência artificial possui uma lista de fraudadores conhecidos e compara cada usuário com essa lista.

Isso pode fazer parte do processo, mas é apenas uma pequena parte.

Na prática, a IA busca principalmente anomalias.

Uma anomalia é algo diferente do padrão esperado.

Considere um cliente que, durante vários anos:

  • acessa o aplicativo entre 7h e 22h;

  • utiliza sempre o mesmo celular;

  • mora no interior de São Paulo;

  • movimenta valores entre R$ 50 e R$ 1.000;

  • realiza pagamentos para poucos destinatários conhecidos.

Agora imagine a seguinte operação:

  • acesso às 3h17;

  • novo aparelho;

  • nova localização;

  • uso de VPN;

  • tentativa de empréstimo;

  • transferência de R$ 48.000;

  • destinatário recém-cadastrado.

Nenhum desses elementos, sozinho, prova uma fraude.

Um cliente pode viajar, trocar de celular ou realizar uma transferência elevada.

Mas o conjunto aumenta fortemente o risco.

A IA analisa dezenas ou centenas de sinais ao mesmo tempo.

Ela não pergunta simplesmente:

“Essa pessoa é criminosa?”

Ela pergunta:

“Esse comportamento é compatível com o histórico e o contexto esperado?”

Essa diferença é essencial.


6. Machine Learning: ensinando o sistema a reconhecer padrões

O aprendizado de máquina, ou Machine Learning, permite que sistemas identifiquem padrões a partir de grandes volumes de dados.

Um sistema antifraude pode aprender com:

  • transações legítimas;

  • fraudes confirmadas;

  • horários;

  • valores;

  • localização;

  • dispositivos;

  • destinatários;

  • canais utilizados;

  • comportamento de navegação;

  • velocidade das ações;

  • respostas a autenticações;

  • histórico de contestação.

Imagine milhões de transações sendo processadas diariamente.

Nenhum analista humano conseguiria revisar cada uma em tempo real.

A inteligência artificial consegue calcular rapidamente a probabilidade de uma operação ser legítima ou suspeita.

Um modelo simplificado poderia considerar:

Dispositivo conhecido: risco reduzido
Localização habitual: risco reduzido
Valor muito elevado: risco aumentado
Novo favorecido: risco aumentado
Horário incomum: risco aumentado
Biometria válida: risco reduzido
Aparelho comprometido: risco elevado

O resultado final pode ser transformado em um score.

Exemplo:

Score de risco: 12 de 100
Decisão: autorizar

Outro caso:

Score de risco: 87 de 100
Decisão: bloquear e solicitar validação

Para o programador COBOL iniciante, pense no score como um campo calculado a partir de várias condições.

MOVE ZERO TO SCORE-RISCO

IF DISPOSITIVO-NOVO = 'S'
    ADD 20 TO SCORE-RISCO
END-IF

IF LOCALIZACAO-INCOMUM = 'S'
    ADD 25 TO SCORE-RISCO
END-IF

IF VALOR-ACIMA-PADRAO = 'S'
    ADD 30 TO SCORE-RISCO
END-IF

IF BIOMETRIA-VALIDA = 'S'
    SUBTRACT 20 FROM SCORE-RISCO
END-IF

Os modelos reais são muito mais complexos, mas o princípio permanece semelhante: sinais são combinados para apoiar uma decisão.


7. Biometria: muito além da impressão digital

A biometria utiliza características humanas para validar a identidade.

As formas mais conhecidas incluem:

  • impressão digital;

  • reconhecimento facial;

  • voz;

  • íris;

  • geometria da mão.

A grande vantagem é que características biométricas são mais difíceis de compartilhar, esquecer ou digitar acidentalmente em um site falso.

Entretanto, biometria não deve ser tratada como solução mágica.

Uma fotografia pode ser roubada. Uma voz pode ser gravada. Um rosto pode ser reproduzido por deepfake.

Por isso, sistemas modernos utilizam mecanismos chamados de prova de vida, ou liveness detection.

A prova de vida tenta verificar se existe uma pessoa real diante do dispositivo.

Ela pode observar:

  • profundidade facial;

  • movimentos naturais;

  • reflexos;

  • textura da pele;

  • resposta a comandos;

  • movimentação dos olhos;

  • sincronização labial;

  • pequenas variações impossíveis em uma fotografia estática.

Um sistema pode pedir:

“Mova o rosto para a esquerda.”

Ou analisar silenciosamente características tridimensionais.

O objetivo é diferenciar uma pessoa real de:

  • fotografia;

  • vídeo;

  • máscara;

  • tela reproduzindo outro rosto;

  • conteúdo sintético.

Curiosidade de bordo: em histórias de ficção científica, scanners biométricos quase sempre reconhecem rostos instantaneamente. Na vida real, iluminação, câmera, ângulo, envelhecimento e qualidade do sensor tornam o problema muito mais complexo.


8. Biometria comportamental: a assinatura invisível

A biometria tradicional analisa características físicas.

A biometria comportamental analisa como uma pessoa interage com o sistema.

Ela pode observar:

  • ritmo de digitação;

  • tempo entre teclas;

  • força aplicada na tela;

  • velocidade do toque;

  • inclinação do aparelho;

  • forma de segurar o celular;

  • movimento do mouse;

  • padrão de rolagem;

  • tempo de leitura;

  • sequência de navegação.

Imagine duas pessoas digitando a mesma senha.

A primeira digita rapidamente, utilizando os dois polegares.

A segunda faz pausas, utiliza um dedo e pressiona determinadas teclas por mais tempo.

O texto é igual, mas o comportamento é diferente.

Essas diferenças formam uma espécie de assinatura invisível.

Outro exemplo:

O cliente legítimo normalmente abre o aplicativo, verifica o saldo, consulta o extrato e depois faz uma transferência.

O fraudador pode entrar diretamente na opção de empréstimo, contratar o valor máximo e transferir imediatamente.

O caminho percorrido dentro da aplicação também é um sinal.

A grande vantagem da biometria comportamental é que ela pode funcionar silenciosamente, sem exigir ações adicionais do usuário.

O cliente legítimo percebe menos fricção.

O fraudador encontra mais barreiras.


9. Autenticação contextual: onde, quando, como e com quê

A autenticação contextual analisa as circunstâncias da operação.

Entre os sinais avaliados estão:

  • localização;

  • endereço IP;

  • operadora;

  • rede Wi-Fi;

  • horário;

  • idioma;

  • fuso horário;

  • modelo do dispositivo;

  • versão do sistema;

  • navegador;

  • resolução da tela;

  • presença de VPN;

  • histórico do aparelho.

Imagine um cliente que mora em Campinas e acessa o banco às 14h.

Cinco minutos depois, ocorre outro acesso a partir de outro continente.

Fisicamente, isso seria impossível.

Esse tipo de evento pode ser classificado como viagem impossível.

O sistema pode bloquear a nova sessão ou solicitar validação adicional.

Outro exemplo:

Um cliente sempre utiliza o aplicativo em um aparelho Android específico. De repente, ocorre um acesso em um emulador, com sistema modificado e ferramentas de automação.

Esse contexto aumenta o risco, mesmo que a senha esteja correta.

A autenticação contextual não substitui a senha ou a biometria. Ela adiciona mais evidências.

É como uma investigação vulcana: nenhuma conclusão é baseada em uma única pista.


10. Token e autenticação multifator

A autenticação multifator combina diferentes tipos de prova.

Os fatores costumam ser divididos em três categorias:

Algo que você sabe

  • senha;

  • PIN;

  • resposta secreta.

Algo que você possui

  • celular;

  • cartão;

  • token físico;

  • aplicativo autenticador.

Algo que você é

  • rosto;

  • impressão digital;

  • voz;

  • íris.

Usar dois ou mais fatores reduz o risco de uma única credencial comprometida permitir acesso completo.

Porém, até a autenticação multifator pode ser atacada.

Códigos podem ser interceptados. Usuários podem ser convencidos a aprovar notificações. Chips podem ser clonados ou transferidos ilegalmente.

Por isso, o setor caminha para uma combinação mais ampla:

Senha
+
Dispositivo
+
Biometria
+
Contexto
+
Comportamento
+
Análise de risco

Quanto mais coerentes forem os sinais, maior a confiança.

Quanto mais contraditórios, maior a necessidade de verificação.


11. A luta contra falsos positivos

Bloquear fraudes é importante.

Mas bloquear clientes legítimos também causa problemas.

Imagine um cliente tentando pagar uma cirurgia, comprar uma passagem ou transferir dinheiro em uma emergência. Se o banco bloquear a operação sem necessidade, a experiência será péssima.

Isso é chamado de falso positivo.

Um falso positivo ocorre quando uma operação legítima é classificada como fraude.

Já um falso negativo ocorre quando uma fraude é classificada como legítima.

O grande desafio é equilibrar os dois.

Se o sistema for rígido demais, bloqueia clientes honestos.

Se for permissivo demais, deixa passar fraudes.

A inteligência artificial ajuda a encontrar um equilíbrio mais preciso.

Em vez de criar uma regra fixa como:

Toda transferência acima de R$ 10.000 deve ser bloqueada.

O sistema pode analisar:

  • renda do cliente;

  • histórico;

  • destinatário;

  • horário;

  • dispositivo;

  • localização;

  • motivo;

  • frequência;

  • comportamento.

Para um cliente, R$ 10.000 pode ser altamente incomum.

Para outro, pode ser uma operação diária.

A análise precisa ser contextual.


12. Aprendizado contínuo: o inimigo também evolui

Fraudadores testam constantemente novas técnicas.

Quando os bancos melhoram a autenticação, surgem novos golpes de engenharia social.

Quando os sistemas detectam determinados padrões, os criminosos tentam imitá-los.

Quando a biometria facial avança, aparecem deepfakes mais sofisticados.

É uma corrida permanente.

Por isso, modelos antifraude precisam ser atualizados continuamente.

O ciclo pode ser representado assim:

Fraude acontece
      ↓
Caso é investigado
      ↓
Padrão é identificado
      ↓
Modelo é ajustado
      ↓
Novas transações são protegidas
      ↓
Resultados são monitorados

Esse processo exige participação humana.

Analistas investigam alertas, confirmam fraudes, corrigem classificações e ajudam a melhorar os modelos.

A inteligência artificial não elimina o especialista.

Ela amplia sua capacidade.

Um analista que antes revisava cem casos pode concentrar-se nos casos mais críticos, enquanto o sistema automatiza a triagem inicial.


13. Inteligência artificial generativa na segurança bancária

Além dos modelos tradicionais de Machine Learning, a inteligência artificial generativa também pode apoiar equipes de segurança.

Ela pode:

  • resumir alertas;

  • explicar motivos de bloqueio;

  • organizar evidências;

  • gerar relatórios;

  • auxiliar investigações;

  • consultar políticas internas;

  • traduzir documentos;

  • correlacionar eventos;

  • apoiar equipes de atendimento.

Imagine um analista recebendo milhares de logs.

Uma IA pode produzir um resumo:

“A operação foi classificada como alto risco devido a novo dispositivo, localização incomum, valor 14 vezes superior à média e cadastramento recente do beneficiário.”

Isso reduz o tempo necessário para entender o caso.

Porém, decisões críticas não devem depender cegamente de uma resposta gerada.

Modelos generativos podem cometer erros, interpretar dados incorretamente ou produzir explicações convincentes, porém falsas.

Por isso, devem operar com:

  • dados confiáveis;

  • limites claros;

  • revisão humana;

  • rastreabilidade;

  • controle de acesso;

  • monitoramento.

Na ponte da nave, a IA pode ser um excelente oficial científico. Mas o comando final ainda exige responsabilidade.


14. LGPD, privacidade e governança

Quanto mais dados são analisados, maior a responsabilidade.

Sistemas antifraude podem processar:

  • identidade;

  • localização;

  • comportamento;

  • dispositivo;

  • histórico financeiro;

  • biometria;

  • dados de navegação.

Essas informações são extremamente sensíveis.

No Brasil, a LGPD estabelece princípios para o tratamento de dados pessoais.

Os bancos precisam considerar:

  • finalidade;

  • necessidade;

  • transparência;

  • segurança;

  • prevenção;

  • responsabilização;

  • direitos do titular.

Não basta dizer:

“Usamos muitos dados porque segurança é importante.”

A instituição precisa demonstrar:

  • por que os dados são necessários;

  • como são protegidos;

  • quem pode acessá-los;

  • por quanto tempo são mantidos;

  • como decisões são tomadas;

  • como incidentes são tratados.

Também existem exigências relacionadas a:

  • prevenção à lavagem de dinheiro;

  • conhecimento do cliente;

  • monitoramento de operações;

  • auditoria;

  • gestão de riscos;

  • identidade digital;

  • controles internos.

A segurança precisa proteger o cliente sem transformar o sistema em uma máquina de vigilância sem limites.

Esse equilíbrio é um dos maiores desafios éticos e regulatórios da era da IA.


15. IA explicável e responsabilidade

Imagine receber a seguinte mensagem:

“Sua transação foi bloqueada pela inteligência artificial.”

Isso não explica nada.

Em sistemas críticos, decisões precisam ser auditáveis.

O banco deve conseguir responder:

  • qual modelo tomou a decisão;

  • qual versão estava em uso;

  • quais dados foram considerados;

  • quais sinais aumentaram o risco;

  • quem revisou o caso;

  • qual política foi aplicada.

Esse campo é conhecido como Explainable AI, ou IA explicável.

Nem todo modelo complexo é fácil de explicar. Porém, instituições financeiras precisam buscar formas de tornar decisões compreensíveis e rastreáveis.

Um relatório pode mostrar:

Motivos principais do bloqueio:

1. Novo dispositivo.
2. Localização incompatível.
3. Transferência 20 vezes superior à média.
4. Beneficiário cadastrado há menos de cinco minutos.
5. Comportamento de navegação fora do padrão.

Isso ajuda:

  • analistas;

  • auditores;

  • reguladores;

  • atendimento;

  • clientes;

  • equipes jurídicas.

A responsabilidade não pode ser transferida para a máquina.

Dizer “o algoritmo decidiu” não encerra a discussão.


16. Onde entra o mainframe?

Agora chegamos ao território familiar do programador COBOL Padawan.

Muitos grandes bancos continuam utilizando mainframes para processar operações críticas.

O IBM Z pode participar de funções como:

  • manutenção de contas;

  • atualização de saldos;

  • processamento de cartões;

  • liquidação;

  • crédito;

  • cadastro;

  • movimentação financeira;

  • auditoria;

  • processamento em lote;

  • integração com redes externas.

A inteligência artificial não necessariamente substitui esses sistemas.

Ela pode atuar ao redor deles ou integrada a eles.

Uma arquitetura simplificada poderia ser:

Aplicativo móvel
      ↓
API de autenticação
      ↓
Biometria e análise de dispositivo
      ↓
Motor antifraude com IA
      ↓
Score de risco
      ↓
API bancária
      ↓
CICS / IMS / Db2 / COBOL
      ↓
Autorização ou rejeição

O programa COBOL pode receber um indicador de risco.

Exemplo:

01  DADOS-TRANSACAO.
    05 CONTA-ORIGEM        PIC 9(10).
    05 CONTA-DESTINO       PIC 9(10).
    05 VALOR-TRANSACAO     PIC 9(11)V99.
    05 SCORE-RISCO         PIC 9(03).
    05 STATUS-BIOMETRIA    PIC X.
    05 DISPOSITIVO-NOVO    PIC X.

IF SCORE-RISCO GREATER THAN 80
    MOVE 'B' TO STATUS-TRANSACAO
    PERFORM REGISTRAR-BLOQUEIO
ELSE
    PERFORM PROCESSAR-TRANSFERENCIA
END-IF

Esse é apenas um exemplo didático.

Em uma arquitetura real, a decisão pode envolver motores especializados, regras, APIs, filas, eventos, banco de dados, monitoração e aprovação humana.

O ponto principal é:

O mainframe não está separado da inteligência artificial. Ele pode ser parte central da cadeia de decisão.

A IA funciona como sensor e oficial de análise.

O core bancário funciona como motor transacional.

Ambos precisam conversar de maneira rápida, confiável e segura.


17. Passo a passo de uma transação moderna

Vamos acompanhar uma transferência do início ao fim.

Passo 1 — O cliente abre o aplicativo

O sistema identifica:

  • modelo do aparelho;

  • versão do sistema;

  • endereço IP;

  • localização aproximada;

  • integridade do dispositivo;

  • histórico de uso.

Passo 2 — O cliente autentica

Pode utilizar:

  • senha;

  • PIN;

  • impressão digital;

  • reconhecimento facial;

  • token.

Passo 3 — O comportamento é observado

O sistema analisa:

  • velocidade de navegação;

  • forma de digitação;

  • sequência de telas;

  • padrão de toque;

  • tempo de resposta.

Passo 4 — A transferência é criada

São coletados:

  • valor;

  • destinatário;

  • banco;

  • horário;

  • frequência;

  • histórico entre as contas.

Passo 5 — A IA calcula o risco

O modelo compara a operação com:

  • padrão do cliente;

  • padrões de fraude;

  • comportamento de contas semelhantes;

  • alertas recentes;

  • reputação do dispositivo;

  • sinais de comprometimento.

Passo 6 — O motor de decisão atua

A operação pode ser:

  • aprovada;

  • aprovada com limite;

  • submetida a biometria;

  • submetida a segundo fator;

  • colocada em espera;

  • bloqueada;

  • enviada para análise.

Passo 7 — O core bancário processa

O sistema transacional verifica:

  • saldo;

  • limite;

  • situação da conta;

  • regras financeiras;

  • disponibilidade;

  • consistência.

Passo 8 — Tudo é registrado

Logs e trilhas de auditoria armazenam:

  • decisão;

  • horário;

  • modelo;

  • score;

  • fatores utilizados;

  • resultado final.

Passo 9 — O sistema aprende

Se a operação for confirmada como fraude, o caso pode alimentar melhorias futuras.

Se o cliente confirmar que era legítima, o sistema também aprende.

Esse ciclo acontece milhões de vezes.


18. Dicas para o programador COBOL Padawan

Mesmo que você não trabalhe diretamente com IA, existem conhecimentos importantes para sua carreira.

Entenda a origem dos dados

Pergunte sempre:

  • quem gerou o score;

  • quando foi calculado;

  • qual o formato;

  • qual a validade;

  • o que fazer se estiver ausente.

Nunca confie cegamente em um campo externo

Um score recebido por API precisa ser validado.

IF SCORE-RISCO NOT NUMERIC
    PERFORM TRATAR-ERRO
END-IF

Registre decisões importantes

Operações críticas precisam de auditoria.

Não basta bloquear. É necessário registrar por quê.

Trate indisponibilidade

O que acontece se o motor de IA estiver fora do ar?

O sistema deve:

  • bloquear tudo;

  • liberar operações de baixo valor;

  • usar regras locais;

  • encaminhar para contingência?

Essa decisão precisa ser definida antecipadamente.

Evite decisões sem explicação

Um campo “RISCO-ALTO” pode ser insuficiente.

Sempre que possível, receba códigos de motivo.

01 — Dispositivo novo
02 — Valor anormal
03 — Localização suspeita
04 — Beneficiário recente

Proteja dados sensíveis

Logs não devem expor:

  • senha;

  • token;

  • biometria;

  • número completo de cartão;

  • informações pessoais desnecessárias.

Pense em performance

Uma análise antifraude não pode levar vários segundos durante uma compra.

Tempo de resposta é parte da experiência e da arquitetura.

Conheça o fluxo completo

O programador não deve enxergar apenas o programa COBOL.

Ele deve compreender:

  • canal digital;

  • API;

  • mensageria;

  • motor de risco;

  • CICS;

  • Db2;

  • logs;

  • monitoração;

  • atendimento;

  • auditoria.

É assim que um Padawan se transforma em arquiteto da Frota.


19. Curiosidades da galáxia antifraude

Curiosidade 1 — Seu jeito de usar o celular pode identificá-lo

A forma como você inclina o aparelho, toca a tela e digita pode compor um padrão comportamental.

Curiosidade 2 — Uma transação legítima pode parecer suspeita

Comprar uma passagem internacional, trocar de telefone e fazer uma transferência elevada no mesmo dia pode gerar alertas, mesmo sendo legítimo.

Curiosidade 3 — Fraude não é apenas invasão de conta

Também pode envolver:

  • abertura de conta falsa;

  • documentos adulterados;

  • crédito obtido ilegalmente;

  • lavagem de dinheiro;

  • uso de contas de terceiros;

  • identidades sintéticas.

Curiosidade 4 — O cliente pode estar autenticado e ainda assim ser vítima

Em golpes de falsa central, a própria vítima realiza a operação sob orientação do criminoso.

Nesse caso, senha, biometria e dispositivo podem estar corretos.

A análise comportamental e contextual torna-se ainda mais importante.

Curiosidade 5 — Regras antigas ainda têm valor

A IA não elimina regras tradicionais.

Muitas arquiteturas combinam:

  • regras fixas;

  • modelos estatísticos;

  • Machine Learning;

  • listas de bloqueio;

  • análise humana.

A melhor defesa costuma ser híbrida.


20. Easter egg para quem chegou até aqui

Em algum ponto desta missão, talvez você tenha percebido que o sistema antifraude se comporta como o computador da USS Enterprise.

Ele observa milhares de sensores, compara padrões, calcula probabilidades e alerta a tripulação quando algo foge do esperado.

Mas existe uma diferença importante.

Nos episódios clássicos, o computador frequentemente anunciava:

“Intruder alert.”

Nos bancos modernos, o alerta pode ser muito mais discreto.

Talvez o cliente apenas receba uma solicitação de biometria adicional.

Talvez a transferência seja atrasada por alguns segundos.

Talvez um analista receba uma notificação.

Talvez um programa COBOL execute um simples:

MOVE 'N' TO TRANSACAO-AUTORIZADA

Por trás desse único caractere podem existir:

  • milhões de registros;

  • dezenas de algoritmos;

  • centenas de sinais;

  • decisões regulatórias;

  • motores de risco;

  • APIs;

  • mainframes;

  • criptografia;

  • auditoria;

  • análise humana.

O humilde MOVE 'N' pode ser o último escudo antes de uma fraude milionária.

Essa é a beleza invisível dos sistemas corporativos.


Conclusão: os novos escudos da Frota Financeira

A segurança bancária não pode mais depender apenas de senhas.

O cenário moderno exige uma combinação de:

  • inteligência artificial;

  • biometria;

  • autenticação multifator;

  • análise comportamental;

  • contexto;

  • tokens;

  • monitoramento contínuo;

  • governança;

  • auditoria;

  • intervenção humana.

A IA permite analisar enormes volumes de transações em tempo real, identificar comportamentos anormais, calcular riscos e responder antes que o prejuízo aconteça.

A biometria ajuda a validar identidade.

A análise comportamental observa como o cliente interage.

A autenticação contextual avalia onde, quando e em qual dispositivo a operação ocorre.

O mainframe garante que a transação seja processada com consistência, disponibilidade e segurança.

Nenhuma dessas tecnologias funciona perfeitamente sozinha.

A verdadeira força está na integração.

Assim como uma nave da Frota Estelar depende de sensores, escudos, computadores, motores, oficiais e protocolos, um banco moderno depende de várias camadas trabalhando em conjunto.

Para o programador COBOL iniciante, a principal lição é clara:

O código que processa uma transação é apenas uma parte de uma missão muito maior.

Por trás de cada autorização existem decisões de segurança, dados, modelos, regras, APIs, auditoria e responsabilidade.

Aprender COBOL continua sendo importante.

Mas compreender o ecossistema ao redor do COBOL é o que transforma um simples programador em um profissional preparado para os sistemas financeiros do futuro.

Quando você encontrar no código um campo chamado SCORE-RISCO, STATUS-BIOMETRIA, IND-FRAUDE ou COD-MOTIVO-BLOQUEIO, não o veja apenas como mais uma variável.

Veja-o como uma mensagem enviada pelos sensores da nave.

Analise.

Valide.

Registre.

Proteja.

E nunca se esqueça da principal diretriz da segurança moderna:

Confiança não é um estado permanente. É uma conclusão que precisa ser reavaliada continuamente.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que os escudos permaneçam ativos em todas as transações da galáxia financeira.


terça-feira, 10 de maio de 2022

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Erros de Programação, Git, Extensões de Arquivos e Inteligência Artificial para Construir Sistemas que Sobrevivem ao Tempo

 

Bellacosa Mainframe emtemdemdo erros

☕ Um Café no Bellacosa Mainframe

Muito Além da Sintaxe

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Erros de Programação, Git, Extensões de Arquivos e Inteligência Artificial para Construir Sistemas que Sobrevivem ao Tempo

"Aprender uma linguagem é importante. Aprender como os computadores pensam é o que realmente transforma um programador em um engenheiro de software."

Existe uma frase muito conhecida entre desenvolvedores experientes:

"Programar não é escrever código. Programar é resolver problemas."

E, curiosamente, quanto mais experiência um profissional adquire, menos tempo ele passa escrevendo código e mais tempo ele dedica a entender erros, interpretar logs, analisar requisitos, versionar alterações, revisar código, automatizar processos e estudar novas tecnologias.

Esse é um choque para muitos iniciantes.

O Programador COBOL Padawan costuma imaginar que a carreira será composta principalmente por escrever comandos MOVE, IF, PERFORM, READ, WRITE e EXEC SQL.

Mas basta entrar em um grande banco, uma seguradora ou uma empresa aérea para descobrir uma realidade completamente diferente.

Ali existem milhares de programas.

Milhões de linhas de código.

Centenas de desenvolvedores.

Diversas linguagens convivendo lado a lado.

COBOL.

PL/I.

Assembler.

Java.

Python.

JavaScript.

Go.

Rust.

SQL.

JCL.

REXX.

E, cada vez mais, Inteligência Artificial auxiliando todas essas equipes.

Nesse ambiente, conhecer apenas a sintaxe de uma linguagem é como saber dirigir um carro sem entender placas de trânsito, mecânica ou regras de circulação.

É por isso que as cinco listas apresentadas anteriormente representam muito mais do que simples curiosidades.

Na prática, elas resumem alguns dos pilares da Engenharia de Software moderna.

Vamos conversar sobre cada um deles.

Pegue seu café.


O computador nunca faz "o que você quis"

Uma das maiores descobertas de todo programador é perceber que computadores não possuem bom senso.

Eles fazem exatamente aquilo que foi programado.

Nem mais.

Nem menos.

Se existir uma pequena falha lógica, o computador executará essa falha com perfeição matemática.

É por isso que um erro aparentemente insignificante pode movimentar milhões de reais incorretamente.

No IBM Z isso acontece diariamente.

Não porque o mainframe seja ruim.

Muito pelo contrário.

Ele é extremamente confiável.

O problema sempre foi — e sempre será — o ser humano.


Existem erros... e existem erros

Quando alguém começa a aprender programação, normalmente acredita que erro significa apenas aquela mensagem vermelha que aparece na tela.

Na realidade existem diversas categorias.

Cada uma possui causas completamente diferentes.

Cada uma exige uma forma diferente de investigação.

É exatamente isso que diferencia um programador júnior de um engenheiro de software.


Syntax Error

O primeiro erro da carreira.

O compilador simplesmente não consegue entender o que você escreveu.

Imagine escrever em português:

Eu mercado fui ontem.

As palavras existem.

Mas a estrutura está incorreta.

O compilador pensa exatamente assim.

Em COBOL:

IF SALDO > 100
DISPLAY "OK"

Faltou o END-IF.

O compilador interrompe tudo.

Nada será executado.

Esse tipo de erro normalmente é simples.

O compilador informa linha, coluna e descrição.


Runtime Error

Agora a situação muda.

O programa compilou perfeitamente.

Foi para produção.

Começou a executar.

Depois...

ABEND.

No universo Mainframe, poucos termos assustam tanto quanto esse.

Um ABEND (Abnormal End) significa que alguma condição inesperada ocorreu durante a execução.

Alguns exemplos clássicos:

S0C1

S0C4

S0C7

S0CB

S322

SB37

SE37

SD37

Cada um deles conta uma história diferente.

Por exemplo...

Dividir por zero em Python gera:

ZeroDivisionError

No COBOL, dependendo do contexto, isso normalmente resulta em um S0CB.

Já acessar memória inválida pode gerar um S0C4, um dos ABENDs mais conhecidos entre programadores COBOL.

Por isso, aprender apenas a programar não basta.

É necessário aprender a investigar.

Ler dumps.

Interpretar mensagens.

Consultar SYSOUT.

Analisar o JES.

Entender SDSF.

Essa habilidade vale ouro.


O erro mais perigoso não gera mensagem

Esse é o famoso Logical Error.

O programa funciona.

Não apresenta erro.

Não gera dump.

Não gera ABEND.

Mas calcula errado.

Imagine um banco calculando juros de 1,59% quando deveria calcular 1,95%.

O programa executa normalmente.

Nenhum operador percebe.

Nenhum monitor dispara alerta.

Somente semanas depois alguém descobre um prejuízo milionário.

Esse tipo de erro explica por que testes automatizados, revisão de código e homologação são tão importantes.


Tipos de dados existem por um motivo

Quando o COBOL foi criado, muitos acreditavam que sua enorme quantidade de definições era exagerada.

Hoje entendemos que não era.

Cada tipo de dado existe para evitar erros.

Em Python podemos escrever:

idade = "30"

Visualmente parece correto.

Mas...

idade + 5

gera erro.

Em COBOL:

PIC 9(03)

é completamente diferente de

PIC X(03)

Essa rigidez é justamente o que torna sistemas bancários tão confiáveis.


Overflow e Underflow

Imagine um campo:

PIC 999

Ele aceita apenas três dígitos.

Se alguém tentar gravar:

1000

algo precisa acontecer.

Dependendo da situação ocorrerá truncamento, exceção ou erro de execução.

Já o Underflow acontece principalmente em cálculos científicos quando números extremamente pequenos perdem precisão.

Embora seja raro em aplicações comerciais, ele é muito comum em computação de alto desempenho e modelos de Inteligência Artificial.


Arquivos são muito mais importantes do que parecem

Outro assunto frequentemente ignorado pelos iniciantes são as extensões de arquivos.

".py"

".java"

".json"

".xml"

".sql"

Muitos acreditam que isso serve apenas para organizar arquivos.

Na realidade, cada extensão representa um ecossistema inteiro.

Quando você vê um arquivo ".java", imediatamente sabe que existe uma JVM envolvida.

Ao encontrar um ".sql", entende que haverá interação com um banco de dados.

Um ".json" normalmente representa troca de informações entre sistemas.

No IBM Mainframe a situação é um pouco diferente.

Grande parte do código está armazenada em membros de PDS ou PDSE.

Não existe necessariamente uma extensão visível.

Mesmo assim, cada biblioteca possui um propósito muito bem definido.

Um membro pode conter COBOL.

Outro JCL.

Outro PROC.

Outro REXX.

Outro COPYBOOK.

Outro DCLGEN.

A organização continua existindo.

Apenas mudou de formato.


O mundo moderno conversa em JSON

Durante décadas o XML dominou integrações corporativas.

SOAP.

Web Services.

Mensagens estruturadas.

Hoje a maior parte das APIs REST utiliza JSON.

Exemplo:

{
   "cliente":"Maria",
   "saldo":3500.90
}

É simples.

Leve.

Legível.

O COBOL moderno já possui suporte para JSON PARSE e JSON GENERATE, permitindo que programas tradicionais conversem diretamente com aplicações web e microsserviços.

Isso demonstra como o ecossistema IBM Z continua evoluindo.


Git mudou a Engenharia de Software

Antigamente, equipes compartilhavam código copiando arquivos.

Imagine dez programadores alterando o mesmo programa COBOL.

Caos.

Hoje isso seria impensável.

O Git resolveu esse problema.

Na prática, o Git funciona como uma máquina do tempo.

Cada Commit registra exatamente o que mudou.

Quem mudou.

Quando mudou.

E por quê.

Se um erro aparecer meses depois, basta consultar o histórico.

Essa rastreabilidade é indispensável em ambientes regulados, como bancos e seguradoras.


Commit não é backup

Esse é um erro comum entre iniciantes.

Commit significa registrar uma alteração lógica.

Um bom commit deve representar uma unidade de trabalho.

Exemplo ruim:

Correções

Exemplo excelente:

Corrige cálculo de IOF para operações acima de R$ 50.000

Percebe a diferença?

O histórico passa a contar uma história.


Branches são universos paralelos

Imagine que a produção está funcionando.

Você precisa desenvolver uma nova funcionalidade.

Não faz sentido quebrar o código principal.

Então cria-se uma Branch.

Ali você trabalha livremente.

Quando tudo estiver pronto, ocorre o Merge.

Essa ideia revolucionou o desenvolvimento colaborativo.


Conflitos fazem parte da profissão

Todo desenvolvedor, cedo ou tarde, encontrará um Merge Conflict.

Isso acontece quando duas pessoas alteram a mesma região do mesmo arquivo.

O Git não consegue decidir automaticamente.

Então pergunta ao ser humano.

Resolver conflitos é uma habilidade importante.

Não é um sinal de incompetência.

É consequência natural do trabalho em equipe.


O Git também chegou ao Mainframe

Durante décadas o versionamento em ambientes IBM Z foi realizado por ferramentas como Endevor, Changeman, Librarian, Panvalet e SCLM.

Hoje o cenário mudou.

Zowe.

Git.

GitHub.

GitLab.

Azure DevOps.

Pipeline CI/CD.

Tudo isso já faz parte da realidade do IBM Z.

O desenvolvedor COBOL moderno trabalha tanto no ISPF quanto no VS Code.


Inteligência Artificial começa pelos dados

Quando ouvimos falar em IA, pensamos imediatamente em ChatGPT.

Mas antes de existir qualquer modelo existe algo muito mais importante.

Dados.

Sem dados não existe aprendizado.

É por isso que Machine Learning começa pelo Dataset.

Imagine ensinar uma criança a reconhecer gatos.

Você mostra milhares de fotografias.

Ela aprende padrões.

Modelos de IA fazem exatamente isso.


Features são as pistas

Suponha um sistema bancário que detecta fraude.

Cada operação possui informações como:

Valor.

Cidade.

Horário.

Dispositivo.

Cliente.

Canal.

Cada uma dessas características recebe o nome de Feature.

Quanto melhores forem as Features, melhor tende a ser o modelo.


Labels representam a resposta correta

Em aprendizado supervisionado existe um professor.

Cada exemplo já possui a resposta.

Operação fraudulenta?

Sim.

Não.

Essas respostas são chamadas de Labels.

O algoritmo tenta aprender a relação entre Features e Labels.


Treinar não é decorar

Aqui surge um dos conceitos mais importantes da IA.

Overfitting.

Imagine um aluno que decorou todas as respostas da apostila.

Na prova, qualquer pergunta diferente o confunde.

Foi exatamente isso que aconteceu com o modelo.

Ele decorou.

Não aprendeu.

No extremo oposto está o Underfitting.

O aluno nem conseguiu compreender o conteúdo.

O modelo é simples demais.

Também falha.

O objetivo sempre é encontrar o equilíbrio.


Accuracy nem sempre significa qualidade

Imagine um banco com um milhão de operações.

Apenas mil são fraudulentas.

Um algoritmo responde sempre:

Não é fraude.

Resultado:

999 mil acertos.

Accuracy de 99,9%.

Parece excelente.

Mas encontrou exatamente zero fraudes.

Por isso profissionais utilizam outras métricas.

Precision.

Recall.

F1-Score.

ROC-AUC.

Cada métrica responde uma pergunta diferente.


Redes neurais não pensam

Esse é um dos maiores equívocos atuais.

Uma Rede Neural não possui consciência.

Ela ajusta milhões ou bilhões de pesos matemáticos.

O comportamento impressionante dos grandes modelos de linguagem surge da enorme quantidade de dados, parâmetros e capacidade computacional.

Ainda assim, continuam sendo modelos estatísticos.


O futuro do COBOL não é competir com a IA

É trabalhar junto dela.

Hoje um desenvolvedor pode utilizar IA para:

  • explicar programas COBOL antigos;

  • gerar documentação técnica;

  • criar testes automatizados;

  • sugerir refatorações;

  • converter layouts de arquivos;

  • produzir exemplos em Java ou Python;

  • revisar SQL;

  • explicar ABENDs;

  • auxiliar na escrita de JCL e REXX;

  • acelerar a compreensão de sistemas legados.

A IA não substitui o conhecimento do negócio.

Ela amplia a produtividade de quem já conhece o ambiente.


O verdadeiro diferencial continua sendo o raciocínio

Ferramentas mudam.

Linguagens surgem.

Frameworks desaparecem.

Mas alguns fundamentos permanecem praticamente inalterados desde os primórdios da computação.

Entender algoritmos.

Conhecer estruturas de dados.

Interpretar erros.

Versionar corretamente.

Escrever código legível.

Documentar alterações.

Testar antes de entregar.

Compreender o domínio do negócio.

Esses princípios continuam válidos para COBOL, Java, Python, Go, Rust, JavaScript ou qualquer outra tecnologia.


O Programador COBOL Padawan e a Jornada para se Tornar um Mestre

Todo grande profissional já foi iniciante.

Ninguém nasce sabendo interpretar um S0C4, resolver um conflito de Git, entender uma métrica de Machine Learning ou projetar uma arquitetura distribuída.

Essas habilidades são construídas com estudo, prática e curiosidade.

O Programador COBOL Padawan deve enxergar cada erro como uma oportunidade de aprendizado, cada commit como um registro da sua evolução, cada extensão de arquivo como a porta de entrada para um novo ecossistema e cada conceito de Inteligência Artificial como uma ferramenta que amplia sua capacidade de resolver problemas.

No Bellacosa Mainframe, costumamos dizer que o objetivo não é formar apenas programadores que saibam escrever código. Queremos formar profissionais capazes de compreender sistemas inteiros, conversar com equipes multidisciplinares, integrar tecnologias clássicas e modernas e tomar decisões técnicas conscientes.

A jornada começa com um simples DISPLAY "HELLO WORLD".

Depois evolui para programas COBOL, JCLs, consultas SQL, integrações REST, pipelines DevOps, versionamento com Git, observabilidade, automação e, mais recentemente, Inteligência Artificial aplicada ao desenvolvimento.

O segredo nunca foi decorar comandos.

O segredo é compreender os fundamentos que atravessam gerações de tecnologias.

Quem domina esses fundamentos consegue aprender qualquer linguagem, adaptar-se a qualquer plataforma e continuar relevante mesmo quando novas ferramentas surgem.

E talvez essa seja a maior lição desta conversa: o COBOL Padawan que aprende a pensar como engenheiro de software não fica preso ao passado; ele usa a solidez do legado para construir o futuro.

Porque, no fim das contas, linguagens mudam, frameworks envelhecem, bibliotecas são substituídas e paradigmas evoluem. Mas a capacidade de analisar problemas, entender sistemas complexos e entregar soluções confiáveis continuará sendo o maior patrimônio de qualquer profissional de tecnologia.

Então, da próxima vez que encontrar uma mensagem de erro, criar uma nova branch, analisar um arquivo JSON ou ouvir falar de Machine Learning, lembre-se: você não está estudando assuntos isolados. Está construindo a base que sustentará toda a sua carreira como desenvolvedor.

E essa é uma jornada que vale cada linha de código.