Bellacosa Mainframe e historia da IBM em resumo

IBM 115 Anos: A Empresa que Ajudou a Construir o Mundo Digital

Uma viagem pela história, curiosidades, desafios e segredos da gigante que ainda move bilhões de transações por dia

16 de junho.

Para muitos, apenas mais um dia no calendário.

Para quem trabalha com Mainframe, COBOL, z/OS, CICS, DB2 e tecnologia corporativa, é uma data especial: o aniversário da IBM, uma das empresas mais influentes da história da humanidade.

Em 16 de junho de 1911 nasceu uma organização que sobreviveria a duas guerras mundiais, à Grande Depressão, à Guerra Fria, ao surgimento do computador pessoal, à internet, ao smartphone, à computação em nuvem e agora à Inteligência Artificial.

Poucas empresas conseguem permanecer relevantes durante cinco anos.

Algumas sobrevivem vinte.

Raríssimas chegam aos cinquenta.

A IBM chegou aos 115 anos.

E continua ajudando a processar boa parte do dinheiro que circula no planeta.

Para um Desenvolvedor COBOL Jr., compreender a história da IBM é entender a própria história da computação.

---

Bellacosa Mainframe e os 115 anos da IBM

Antes da IBM Existia um Problema

Imagine o mundo em 1890.

Não havia computadores.

Não havia bancos de dados.

Não havia internet.

Não havia sequer calculadoras eletrônicas.

Governos precisavam contar milhões de pessoas manualmente.

Empresas precisavam processar montanhas de documentos em papel.

Folhas de pagamento eram calculadas à mão.

Erros eram frequentes.

Processos demoravam meses.

Foi nesse cenário que apareceu Herman Hollerith.

---

O Homem que Criou o Conceito de Processamento de Dados

Herman Hollerith era um engenheiro americano que observou um problema gigantesco:

O censo dos Estados Unidos de 1880 demorou quase oito anos para ser concluído.

Se nada mudasse, o próximo censo demoraria mais do que o intervalo entre censos.

Era matematicamente impossível continuar daquele jeito.

Sua solução foi revolucionária.

Ele criou cartões perfurados capazes de armazenar informações.

Cada furo representava um dado.

Máquinas eletromecânicas liam esses cartões e realizavam contagens automaticamente.

Pela primeira vez na história, uma máquina processava dados em larga escala.

Nascia o conceito que décadas depois evoluiria para os computadores modernos.

---

O Verdadeiro Nascimento da IBM

Em 1911 várias empresas se fundiram para formar a:

Computing-Tabulating-Recording Company (CTR)

O nome era enorme.

Pouco elegante.

Pouco memorável.

Em 1924, Thomas J. Watson decidiu mudar tudo.

A empresa passou a se chamar:

International Business Machines

Ou simplesmente:

IBM

Uma mudança que parece simples, mas que carregava uma visão ousada.

Watson acreditava que as máquinas de processamento de dados teriam alcance mundial.

Na década de 1920 isso parecia exagero.

Hoje sabemos que ele estava certo.

---

O Primeiro Easter Egg da IBM

A famosa frase:

"THINK"

foi criada por Thomas Watson Sr.

Ela surgiu em uma reunião onde um executivo perguntou:

"Como resolveremos este problema?"

Watson respondeu:

"Think."

A palavra virou slogan oficial.

Décadas depois inspirou o nome do notebook ThinkPad.

Até hoje a cultura IBM incentiva seus profissionais a pensarem antes de agir.

Uma filosofia simples.

Mas extremamente poderosa.

---

A IBM e a Segunda Guerra Mundial

Durante os anos 1940 a IBM cresceu enormemente.

Suas máquinas de tabulação eram usadas para processar informações em velocidade inédita para a época.

A guerra acelerou a necessidade de automação.

Governos precisavam controlar:

• Estoques

• Logística

• Produção industrial

• Recursos militares

A IBM tornou-se referência mundial em processamento de informações.

Mas a verdadeira revolução ainda estava por vir.

---

O Computador Entra em Cena

Na década de 1950 o mundo testemunhou o nascimento dos computadores eletrônicos.

Grandes máquinas ocupavam salas inteiras.

Consumiam energia absurda.

Possuíam menos capacidade computacional que um relógio inteligente moderno.

Mesmo assim representavam um salto gigantesco.

A IBM rapidamente percebeu que o futuro estava nos computadores.

Surgiram máquinas históricas como:

IBM 650

IBM 701

IBM 704

IBM 7070

Cada uma delas ajudou a criar os alicerces da computação corporativa.

---

A Maior Aposta da História da Computação

Em 1964 a IBM tomou uma decisão considerada loucura por muitos analistas.

Ela investiu aproximadamente 5 bilhões de dólares no desenvolvimento de uma nova arquitetura.

A aposta recebeu um nome simples:

System/360

Hoje parece apenas mais um produto.

Na época foi uma revolução.

---

Bellacosa Mainframe e a evolução historica do logotipo IBM

Por Que o System/360 Mudou o Mundo?

Antes do System/360 cada computador era praticamente incompatível com os demais.

Trocar de equipamento significava reescrever programas.

Refazer processos.

Treinar equipes novamente.

A IBM propôs algo radical.

Uma família inteira de computadores compatíveis entre si.

O programa escrito para um modelo poderia funcionar em outro.

Esse conceito influenciou praticamente toda a indústria.

Windows.

Linux.

Unix.

Cloud.

Todos herdaram, direta ou indiretamente, ideias introduzidas pelo System/360.

---

O Nascimento do Mainframe Moderno

Quando um profissional fala em Mainframe hoje, está falando do descendente direto do System/360.

A linha evoluiu:

System/360

System/370

390

zSeries

System z

IBM Z

z16

z17

Existe uma linha evolutiva contínua de mais de sessenta anos.

Pouquíssimas tecnologias possuem essa continuidade.

---

Onde Entra o COBOL?

Em 1959 surgiu o COBOL.

Seu objetivo era simples:

Permitir que pessoas de negócios compreendessem programas.

Por isso comandos como:

ADD

SUBTRACT

MOVE

READ

WRITE

são tão próximos da linguagem humana.

A IBM adotou COBOL massivamente.

Bancos.

Seguradoras.

Governos.

Empresas aéreas.

Todos começaram a construir sistemas corporativos usando COBOL.

Muitos desses sistemas continuam funcionando até hoje.

---

O Grande Mito Sobre COBOL

Você provavelmente já ouviu:

"COBOL está morto."

Curiosamente essa frase existe desde os anos 1980.

Mas o COBOL continua processando:

• Folhas de pagamento

• Cartões de crédito

• PIX

• TED

• DOC

• Seguros

• Aposentadorias

• Impostos

Na prática, ele sobrevive porque resolve muito bem problemas de negócios.

Tecnologia não vence porque é nova.

Vence porque funciona.

---

A Curiosidade Que Surpreende Todo Iniciante

Muitos aplicativos modernos dependem de COBOL sem que seus usuários saibam.

Quando alguém usa:

• Aplicativo bancário

• Caixa eletrônico

• Portal de investimentos

• Sistema de previdência

Existe uma chance enorme de uma transação COBOL estar participando do processo.

O aplicativo bonito do smartphone frequentemente é apenas a ponta do iceberg.

A parte invisível muitas vezes roda em Mainframe.

---

O Mainframe Nunca Foi Embora

Existe uma narrativa popular de que Mainframes desapareceram.

Isso nunca aconteceu.

O que aconteceu foi algo diferente.

Eles ficaram invisíveis.

Ninguém vê o Mainframe.

Mas todos usam.

Quando você passa um cartão.

Quando faz PIX.

Quando compra uma passagem aérea.

Quando consulta um seguro.

Quando paga impostos.

Existe uma grande probabilidade de um Mainframe estar envolvido.

---

O Desafio dos Anos 2000

Um dos maiores momentos da história da IBM foi o famoso Bug do Milênio.

Muitos sistemas armazenavam anos usando apenas dois dígitos.

Exemplo:

99

00

Quando chegasse o ano 2000, milhões de programas poderiam interpretar:

00

como 1900.

O mundo inteiro entrou em pânico.

Governos contrataram milhares de programadores COBOL.

Muitos profissionais construíram carreiras inteiras trabalhando nesse projeto.

O curioso?

Grande parte do sucesso ocorreu justamente porque Mainframes eram sistemas extremamente bem documentados.

---

O Segundo Easter Egg

Existe uma brincadeira antiga no mundo Mainframe:

"Mainframe é a única tecnologia que os jornais só mencionam quando para."

Quando tudo funciona, ninguém fala.

Quando um banco fica indisponível por dez minutos, vira manchete nacional.

Isso mostra o quanto esses sistemas se tornaram essenciais.

---

A Era da Internet

Quando a internet surgiu, muitos especialistas declararam o fim do Mainframe.

Aconteceu exatamente o contrário.

A internet aumentou a demanda por processamento.

Mais acessos.

Mais transações.

Mais clientes.

Mais integrações.

O Mainframe tornou-se ainda mais importante.

---

O Nascimento do DB2

Outro capítulo fundamental da IBM foi o DB2.

Criado a partir das pesquisas de Edgar F. Codd sobre bancos relacionais.

O DB2 ajudou a transformar a forma como empresas armazenam dados.

Hoje conceitos como:

SELECT

JOIN

INDEX

TABLE

são comuns.

Mas houve uma época em que tudo isso era revolucionário.

---

A Revolução do CICS

Outro herói pouco conhecido é o CICS.

Customer Information Control System.

Ele permitiu que sistemas deixassem de ser exclusivamente batch.

Agora usuários podiam interagir online.

Em tempo real.

Caixas eletrônicos.

Terminais bancários.

Consultas instantâneas.

Tudo isso foi potencializado pelo CICS.

---

O Que Um COBOL Jr Deve Aprender Com a História da IBM?

Primeira lição:

Tecnologia é uma maratona.

Não uma corrida de cem metros.

A IBM não sobreviveu 115 anos perseguindo modismos.

Ela sobreviveu resolvendo problemas reais.

---

Segunda lição:

Confiabilidade vale ouro.

Uma aplicação pode ser bonita.

Pode usar a linguagem da moda.

Pode ter milhões de downloads.

Mas se não for confiável, não sobrevive.

---

Terceira lição:

Fundamentos importam.

COBOL.

JCL.

VSAM.

DB2.

CICS.

Datasets.

Esses conceitos parecem antigos.

Mas continuam sustentando operações críticas.

---

O Futuro Chegou

Hoje a IBM investe pesadamente em:

• Inteligência Artificial

• WatsonX

• Quantum Computing

• Cloud Híbrida

• OpenShift

• Red Hat

• Automação

Mas existe algo interessante.

Ela não abandonou o Mainframe.

Pelo contrário.

Ela o integrou ao futuro.

O IBM Z moderno executa:

• Containers

• APIs REST

• Java

• Python

• Node.js

• COBOL

• IA

Tudo no mesmo ecossistema.

---

O Maior Easter Egg de Todos

Existe uma ironia divertida na história da tecnologia.

Muitos desenvolvedores passam anos tentando criar sistemas escaláveis.

Altamente disponíveis.

Seguros.

Auditáveis.

Transacionais.

E acabam redescobrindo conceitos que o Mainframe já utilizava há décadas.

Controle transacional.

Alta disponibilidade.

Particionamento.

Segurança centralizada.

Recuperação automática.

Observabilidade.

Governança.

Tudo isso já fazia parte do universo IBM muito antes da maioria das plataformas modernas existir.

---

Conclusão

Quando comemoramos os 115 anos da IBM, não estamos celebrando apenas uma empresa.

Estamos celebrando uma parte importante da história da computação.

Dos cartões perfurados de Hollerith ao IBM z17.

Do COBOL ao WatsonX.

Do System/360 à Inteligência Artificial.

A IBM ajudou a construir a infraestrutura invisível que move a economia global.

E para você, Desenvolvedor COBOL Jr., existe uma mensagem importante nessa história:

Aprenda as tecnologias modernas.

Explore IA.

Conheça Cloud.

Estude APIs.

Mas nunca subestime os fundamentos.

Porque enquanto o mundo muda de linguagem a cada poucos anos, os sistemas críticos continuam exigindo aquilo que sempre importou:

Confiabilidade.

Performance.

Segurança.

Disponibilidade.

E é exatamente nesse ponto que o Mainframe e a IBM construíram um legado que atravessa gerações.

Parabéns, IBM.

115 anos conectando passado, presente e futuro.

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Bellacosa Mainframe e o incidente informatico do Nubank

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Introdução

Em junho de 2026, um episódio incomum chamou a atenção do mercado financeiro brasileiro, dos profissionais de tecnologia e dos especialistas em gestão de riscos. Clientes do Nubank receberam comunicações oficiais informando que a instituição teria entrado em processo de liquidação. A mensagem, enviada por canais legítimos da empresa, parecia autêntica, utilizava terminologia regulatória correta e mencionava procedimentos relacionados ao Fundo Garantidor de Créditos (FGC).

O problema era simples e ao mesmo tempo alarmante: a informação era falsa.

Em poucas horas, a notícia se espalhou pelas redes sociais, grupos de investidores, fóruns especializados e veículos de imprensa. O Banco Central precisou esclarecer que não existia qualquer procedimento de liquidação em andamento. O Nubank confirmou que se tratava de um erro operacional decorrente de uma falha em processos internos.

À primeira vista, o incidente parece apenas um erro de comunicação. Entretanto, uma análise mais profunda revela um caso clássico de falha sistêmica envolvendo automação, governança, gestão de mudanças, segregação de ambientes e controles de produção.

Mais importante ainda: o episódio oferece uma oportunidade rara para discutir um tema frequentemente negligenciado em empresas digitais modernas — a diferença entre construir sistemas rápidos e construir sistemas confiáveis.

---

O que aconteceu

Segundo informações divulgadas publicamente, um fluxo responsável por notificações relacionadas a processos de liquidação institucional teria sido acionado indevidamente.

A comunicação foi distribuída para clientes reais utilizando canais oficiais.

Do ponto de vista do usuário final, todos os elementos indicavam legitimidade:

• origem oficial;

• identidade visual correta;

• linguagem regulatória compatível;

• referência ao FGC;

• comunicação direta da instituição.

Em segurança da informação existe um princípio fundamental:

O usuário não possui mecanismos para diferenciar uma mensagem legítima de uma mensagem enviada legitimamente por engano.

Essa frase resume a gravidade do incidente.

Quando uma comunicação falsa vem de um atacante externo, o cliente pode desconfiar.

Quando a mesma comunicação vem do próprio banco, a confiança desaparece como mecanismo de defesa.

---

O erro informático por trás do incidente

Embora os detalhes técnicos completos não tenham sido divulgados, a descrição pública permite inferir algumas hipóteses plausíveis.

O problema parece ter ocorrido em uma combinação de:

• automação de mensagens;

• parametrização inadequada;

• ausência de validações obrigatórias;

• insuficiência de mecanismos de aprovação.

Em engenharia de software, isso é conhecido como um erro de "guard rails", ou seja, ausência de barreiras que impeçam uma ação perigosa.

Imagine um sistema com a seguinte lógica:

Evento:
Liquidação Institucional

Instituição:
[NOME_DO_BANCO]

Ação:
Enviar comunicação aos clientes

Se o campo da instituição estiver vazio, o sistema deveria interromper imediatamente o processo.

No entanto, em muitos sistemas corporativos existem valores padrão.

Exemplo:

if banco == null:
    banco = "Nubank"

Ou ainda:

if banco == "":
    utilizar_instituicao_padrao()

Pequenos atalhos criados durante desenvolvimento, testes ou homologação podem se transformar em bombas-relógio quando chegam à produção.

---

Quando ambientes de teste contaminam a produção

Uma das hipóteses mais discutidas é a existência de um fluxo originalmente criado para testes.

Esse cenário é extremamente comum.

Empresas desenvolvem sistemas utilizando ambientes distintos:

Desenvolvimento

Local onde programadores criam funcionalidades.

Homologação

Ambiente utilizado para validações.

Produção

Sistema real utilizado por clientes.

Na teoria, esses ambientes são completamente isolados.

Na prática, muitas organizações acabam criando atalhos.

Exemplos comuns:

• cópia de bases produtivas;

• reutilização de configurações;

• compartilhamento de APIs;

• uso de dados reais em homologação.

Quando isso acontece, uma fronteira crítica desaparece.

O resultado é que ações originalmente pensadas para teste passam a ter impacto real.

---

A armadilha da automação

O setor financeiro moderno depende de automação em larga escala.

Bancos digitais enviam diariamente:

• notificações;

• alertas;

• extratos;

• avisos regulatórios;

• comunicações de segurança.

Uma única plataforma pode disparar milhões de mensagens por hora.

O benefício é evidente:

• redução de custos;

• velocidade operacional;

• escalabilidade.

O problema é que a automação amplifica erros.

Um funcionário que envia uma mensagem errada manualmente afeta algumas pessoas.

Um sistema automatizado pode afetar milhões.

Existe uma máxima conhecida em operações de TI:

A automação não elimina erros humanos. Ela multiplica seus efeitos.

O incidente ilustra perfeitamente esse princípio.

---

O papel dos controles de mudança

Toda alteração em sistemas críticos deveria seguir um processo formal.

Esse processo normalmente inclui:

Revisão técnica

Validação por outros desenvolvedores.

Aprovação operacional

Análise dos impactos.

Aprovação de negócio

Validação da área responsável.

Testes

Verificação funcional.

Plano de rollback

Capacidade de reversão rápida.

Quando qualquer uma dessas etapas falha, o risco aumenta exponencialmente.

A questão não é impedir erros.

Erros são inevitáveis.

A questão é impedir que erros individuais alcancem clientes.

---

O conceito de “blast radius”

Engenheiros de confiabilidade utilizam o conceito de blast radius.

Traduzindo livremente:

"raio de explosão".

A pergunta é simples:

Se algo der errado, quantas pessoas serão afetadas?

Sistemas modernos devem ser projetados para minimizar esse impacto.

Exemplo:

Em vez de enviar uma comunicação para toda a base de clientes, o sistema deveria:

1. enviar para um grupo piloto;

2. validar resultados;

3. liberar gradualmente;

4. expandir para toda a população.

Essa técnica é utilizada por empresas como:

• Google;

• Amazon;

• Microsoft;

• Netflix.

Caso o disparo incorreto tivesse sido submetido a um rollout progressivo, o incidente provavelmente teria sido detectado nos primeiros minutos.

---

O problema dos dados reais em testes

Outro aprendizado importante envolve o uso de dados produtivos.

Muitas empresas utilizam bases reais para reproduzir cenários complexos.

Isso facilita testes.

Também aumenta riscos.

Dados reais possuem características imprevisíveis:

• relacionamentos existentes;

• integrações ativas;

• gatilhos automáticos;

• usuários legítimos.

Uma rotina criada para laboratório pode encontrar condições inesperadas quando executada em produção.

É por isso que organizações maduras investem em:

• anonimização;

• mascaramento de dados;

• ambientes sintéticos.

O objetivo é reproduzir a realidade sem colocar clientes reais em risco.

---

O fator psicológico do incidente

Existe um aspecto pouco discutido.

O dano não foi apenas tecnológico.

Foi psicológico.

O sistema financeiro funciona baseado em confiança.

Quando um banco afirma que está sendo liquidado, o cliente não realiza uma análise técnica.

Ele reage emocionalmente.

As perguntas surgem imediatamente:

• Meu dinheiro está seguro?

• Preciso sacar recursos?

• Minha conta continuará funcionando?

• Meu cartão será cancelado?

• Vou perder investimentos?

Em poucos minutos pode surgir um fenômeno conhecido como corrida informacional.

Não necessariamente uma corrida bancária tradicional.

Mas uma corrida por esclarecimentos.

Milhares de pessoas acessam simultaneamente:

• aplicativo;

• central de atendimento;

• redes sociais;

• imprensa.

O volume gerado pode se tornar um problema operacional por si só.

---

O impacto no mercado

Embora o incidente tenha sido rapidamente esclarecido, ele produziu repercussões relevantes.

Mercados financeiros são altamente sensíveis à informação.

Especialmente quando envolve:

• liquidez;

• solvência;

• regulação.

Investidores institucionais monitoram continuamente sinais de risco.

Uma notícia sobre liquidação, ainda que falsa, pode provocar:

• volatilidade;

• aumento de dúvidas;

• especulação;

• pressão reputacional.

Mesmo após o esclarecimento, permanece uma questão:

Como um mecanismo tão crítico conseguiu ser acionado incorretamente?

Essa pergunta interessa mais ao mercado do que o próprio erro.

Porque ela trata da maturidade operacional da organização.

---

O custo invisível da reputação

Empresas costumam medir:

• receita;

• lucro;

• crescimento;

• número de clientes.

Poucas conseguem medir confiança.

Entretanto, confiança é um dos ativos mais valiosos do setor financeiro.

Uma instituição pode gastar bilhões em marketing.

Mas basta um único incidente de credibilidade para comprometer anos de construção de marca.

A reputação é semelhante a um sistema distribuído:

Leva muito tempo para convergir.

Pode ser afetada em segundos.

---

O que empresas podem aprender

O incidente produz diversas lições para organizações digitais.

1. Sistemas críticos precisam de múltiplas aprovações

Nenhuma comunicação regulatória deveria depender de uma única ação.

Princípio dos quatro olhos:

duas pessoas precisam validar.

2. Produção deve ser protegida contra operadores

O objetivo não é desconfiar das pessoas.

É reconhecer que erros acontecem.

Sistemas precisam impedir ações perigosas.

3. Rollouts graduais reduzem impacto

Nenhum disparo massivo deveria ocorrer instantaneamente.

4. Testes precisam ser isolados

Ambientes de homologação devem permanecer separados da produção.

5. Alertas precisam monitorar comportamentos anormais

Se uma mensagem de liquidação for enviada, alarmes automáticos deveriam disparar imediatamente.

---

O paradoxo dos bancos digitais

O caso revela um paradoxo interessante.

Os bancos digitais são extraordinariamente eficientes.

Conseguem:

• abrir contas em minutos;

• aprovar cartões rapidamente;

• processar milhões de transações.

Mas velocidade e confiabilidade nem sempre evoluem no mesmo ritmo.

À medida que organizações crescem, seus sistemas tornam-se mais complexos.

Mais integrações.

Mais automações.

Mais dependências.

Mais pontos de falha.

O desafio deixa de ser construir funcionalidades.

Passa a ser controlar complexidade.

---

A maturidade dos sistemas modernos

Os maiores incidentes tecnológicos raramente acontecem por falhas sofisticadas.

Na maioria das vezes eles surgem de:

• configurações incorretas;

• permissões inadequadas;

• processos incompletos;

• validações ausentes.

A história da tecnologia está repleta de exemplos semelhantes.

Falhas milionárias já foram causadas por:

• campos vazios;

• scripts de manutenção;

• comandos executados no ambiente errado;

• parâmetros incorretos.

O problema não é a tecnologia.

O problema é a interação entre tecnologia, pessoas e processos.

---

Conclusão

O episódio envolvendo a falsa comunicação de liquidação do Nubank não deve ser interpretado apenas como um erro operacional isolado.

Ele representa um estudo de caso sobre os desafios da engenharia moderna em sistemas de missão crítica.

O incidente demonstrou como um único evento pode atravessar múltiplas camadas organizacionais:

• tecnologia;

• governança;

• comunicação;

• segurança;

• reputação;

• mercado financeiro.

Mais importante, revelou uma verdade frequentemente esquecida em ambientes digitais:

A confiabilidade não nasce da ausência de erros.

Ela nasce da capacidade de impedir que erros inevitáveis se transformem em crises.

Em um mundo onde bancos são plataformas de software, cada linha de código, cada configuração e cada processo operacional participa diretamente da construção da confiança do cliente.

E confiança, diferentemente do software, não pode ser restaurada simplesmente com um novo deploy.

Ela precisa ser reconquistada.

Para ir mais longe

Bellacosa Mainframe e o incidente do nubank

nubank-diz-que-mensagem-sobre-liquidacao-extrajudicial-enviada-a-clientes-foi-erro-tecnico-pontual

https://www.cnnbrasil.com.br/economia/macroeconomia/cofundadora-do-nubank-diz-que-mensagem-sobre-liquidacao-foi-erro-bizarro/

https://www.tecmundo.com.br/mercado/413858-erro-de-desenvolvedor-disparou-mensagens-de-liquidacao-extrajudicial-do-nubank.htm

https://comunidade.nubank.com.br/discussoes/post/email-de-liquidacao-judicial-Ii0ygNNm8mD5Qxr

☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Bellacosa Mainframe e a internet cada vez mais restrista e insonsa

 ☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Durante uma conversa recente me peguei lembrando de uma ferramenta que muitos profissionais mais jovens provavelmente nunca ouviram falar.

O nome era Copernic.

Para quem viveu a internet dos anos 1990 e início dos anos 2000, o Copernic era quase mágico.

Você digitava uma pesquisa.

Ele consultava diversos motores de busca simultaneamente.

AltaVista.

Lycos.

Excite.

HotBot.

Infoseek.

Yahoo.

Depois consolidava os resultados e apresentava aquilo que considerava mais relevante.

Na época parecia algo revolucionário.

Hoje parece uma relíquia arqueológica.

Mas aquela lembrança me levou a uma reflexão muito maior.

A internet ficou maior ou menor?

A resposta parece óbvia.

Maior.

Muito maior.

Milhões de vezes maior.

Mas talvez essa resposta esteja errada.

☕ A INTERNET QUE PROMETIA CONHECIMENTO INFINITO

Quem começou a navegar na internet durante os anos 1990 provavelmente lembra da sensação.

Cada clique parecia abrir uma porta para um universo desconhecido.

Você começava pesquisando COBOL.

Terminava lendo sobre arqueologia romana.

Depois encontrava um PDF perdido de um professor australiano.

Mais tarde descobria uma apostila digitalizada em 1987.

Era uma experiência de exploração.

A internet era um continente selvagem.

Cheio de trilhas.

Cheio de mapas incompletos.

Cheio de descobertas inesperadas.

O objetivo principal dos mecanismos de busca era simples:

Encontrar informação.

Não importava se ela estava em uma universidade.

Num servidor pessoal.

Num fórum obscuro.

Ou numa página criada por um entusiasta usando HTML rudimentar.

O importante era que ela existia.

☕ O GOOGLE QUE MUDOU O MUNDO

Quando o Google surgiu, ele parecia resolver um problema impossível.

Enquanto outros buscadores dependiam principalmente de palavras-chave, o Google utilizava uma ideia brilhante.

O PageRank.

Em vez de perguntar apenas:

"Quantas vezes esta palavra aparece?"

O sistema perguntava:

"Quantas páginas apontam para esta página?"

A lógica era elegante.

Links funcionavam como votos.

Quanto mais votos de qualidade uma página recebesse, mais relevante ela provavelmente seria.

Os resultados eram impressionantes.

Muitas vezes os primeiros resultados eram exatamente aquilo que procurávamos.

Não porque o Google nos conhecia.

Mas porque compreendia melhor a estrutura da web.

☕ QUANDO O USUÁRIO VIROU O PRODUTO

Com o passar dos anos, algo começou a mudar.

O Google deixou de ser apenas um mecanismo de busca.

Transformou-se em uma plataforma de publicidade.

Isso não é necessariamente uma crítica.

Foi o modelo econômico que financiou boa parte da internet moderna.

Mas a mudança trouxe consequências.

O objetivo deixou de ser apenas encontrar informação.

Agora era necessário:

• Maximizar receita publicitária.

• Combater spam.

• Combater manipulação de SEO.

• Reduzir desinformação.

• Personalizar resultados.

• Aumentar retenção.

A busca deixou de ser um problema puramente técnico.

Passou a ser um problema econômico.

☕ O FIM DA WEB ARTESANAL

Talvez a maior vítima dessa transformação tenha sido a web artesanal.

Quem trabalhou com tecnologia nas décadas passadas certamente conhece esse tipo de conteúdo.

Um especialista mantinha um site simples.

Visual horrível.

HTML básico.

Fundo cinza.

Talvez alguns GIFs piscando.

Mas o conteúdo era extraordinário.

Anos de experiência condensados em dezenas de páginas.

Hoje esse material frequentemente desaparece dos resultados.

Não porque perdeu qualidade.

Mas porque perdeu relevância algorítmica.

O algoritmo prefere:

• Grandes portais.

• Sites otimizados.

• Plataformas com autoridade.

• Conteúdo constantemente atualizado.

O conhecimento continua existindo.

Mas tornou-se invisível.

☕ A DEEP WEB QUE NÃO É CRIMINOSA

Quando ouvimos o termo Deep Web, muitas pessoas pensam imediatamente em mercados ilegais, hackers ou atividades criminosas.

Mas essa é apenas uma pequena parte da história.

Originalmente, Deep Web significa simplesmente conteúdo não indexado.

E essa categoria inclui:

• Bancos de dados acadêmicos.

• Arquivos históricos.

• Fóruns antigos.

• Grupos privados.

• Repositórios técnicos.

• Coleções digitais.

Existe uma quantidade gigantesca de conhecimento que simplesmente não aparece nas buscas tradicionais.

Ele não foi destruído.

Ele não foi censurado.

Ele apenas deixou de ser encontrado.

E do ponto de vista prático, existe pouca diferença entre algo destruído e algo impossível de localizar.

☕ O PARADOXO DA ABUNDÂNCIA

Aqui encontramos um fenômeno fascinante.

A internet produz mais conteúdo do que nunca.

Mas os usuários acessam uma parcela cada vez menor desse conteúdo.

Pense no seu comportamento diário.

Quantos sites diferentes você visita regularmente?

Provavelmente:

• Google

• YouTube

• Wikipedia

• Reddit

• LinkedIn

• Algumas redes sociais

A web aberta continua existindo.

Mas boa parte dela está escondida atrás de plataformas gigantes.

É como morar numa cidade com milhões de ruas e caminhar sempre pelas mesmas dez.

☕ A MORTE DA SERENDIPIDADE

Existe uma palavra pouco conhecida chamada serendipidade.

Ela descreve descobertas valiosas feitas por acaso.

A internet antiga era uma máquina de serendipidade.

Você procurava uma coisa.

Encontrava dez outras.

Hoje os algoritmos tentam ser eficientes.

Eles querem prever seus interesses.

Querem antecipar suas necessidades.

Querem entregar exatamente aquilo que você procura.

Parece maravilhoso.

Mas existe um efeito colateral.

Você encontra menos surpresas.

Menos desvios.

Menos acidentes intelectuais.

Menos descobertas inesperadas.

A eficiência mata a exploração.

☕ O EFEITO BOLHA

Outro fenômeno importante é a personalização.

Os algoritmos aprendem quem somos.

Aprendem nossas preferências.

Nossos hábitos.

Nossos interesses.

Isso melhora a experiência?

Muitas vezes sim.

Mas também cria bolhas.

Quanto mais o sistema aprende sobre você, mais ele entrega versões de você mesmo.

Você gosta de determinado tema.

Recebe mais daquele tema.

Você gosta de determinada opinião.

Recebe mais daquela opinião.

Você gosta de determinado conteúdo.

Recebe mais daquele conteúdo.

A internet que prometia expandir horizontes frequentemente acaba reforçando horizontes já existentes.

☕ A PUBLICIDADE QUE NOS PERSEGUE

Existe algo quase cômico no modelo atual.

Você pesquisa uma cadeira.

Durante semanas recebe anúncios de cadeiras.

Compra a cadeira.

Continua recebendo anúncios de cadeiras.

O sistema supostamente inteligente não percebe que o problema já foi resolvido.

Isso acontece porque o objetivo não é compreender perfeitamente o usuário.

O objetivo é maximizar a probabilidade de uma compra.

Somos constantemente observados.

Segmentados.

Classificados.

Modelados.

Transformados em perfis estatísticos.

A economia digital moderna depende disso.

☕ O CONHECIMENTO INVISÍVEL

Talvez a consequência mais preocupante seja outra.

Estamos produzindo uma quantidade absurda de conhecimento.

Mas encontrar esse conhecimento tornou-se cada vez mais difícil.

Não porque ele não exista.

Mas porque está enterrado.

Sob camadas de algoritmos.

Publicidade.

SEO.

Priorizações automáticas.

Curadorias invisíveis.

A informação não desapareceu.

Ela foi soterrada.

☕ O ARQUEÓLOGO DIGITAL DE 2526

Imagine um historiador vivendo daqui a 500 anos.

Ele descobre que a humanidade possuía acesso ao maior repositório de conhecimento já criado.

Bilhões de páginas.

Bilhões de documentos.

Bilhões de pessoas conectadas.

Então ele faz uma pergunta simples:

"Se havia tanto conhecimento disponível, por que as pessoas consultavam sempre os mesmos poucos sites?"

Talvez essa seja uma das grandes ironias do século XXI.

Nunca produzimos tanto conhecimento.

Nunca tivemos tanta capacidade de compartilhá-lo.

E, ao mesmo tempo, nunca dependemos tanto de um pequeno conjunto de algoritmos para decidir o que merece ser visto.

☕ CONCLUSÃO

Quando lembro do Copernic, do AltaVista ou dos primeiros anos do Google, não sinto apenas nostalgia tecnológica.

Sinto nostalgia de uma filosofia diferente.

A filosofia da descoberta.

A sensação de que a internet era um território a ser explorado.

Não um ambiente cuidadosamente organizado para maximizar engajamento.

Talvez a internet não tenha ficado menor.

Talvez ela tenha ficado tão grande que precisou de guias.

O problema é que esses guias passaram a decidir quais caminhos merecem ser percorridos.

E quando isso acontece, surge uma pergunta inquietante.

O que está sendo escondido?

Não por censura.

Não por conspiração.

Mas simplesmente porque ninguém mais consegue encontrá-lo.

Porque às vezes a forma mais eficiente de tornar algo invisível não é destruí-lo.

É apenas enterrá-lo sob uma montanha de informações mais lucrativas.

E essa talvez seja uma das histórias mais importantes da era digital.

 

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. ☕🚀💻🏦

Guard Rails, COBOL, Mainframe, Engenharia de Software, Desenvolvimento COBOL, Sistemas Críticos, Confiabilidade, Governança de TI, DevOps, Arquitetura de Software, Batch Processing, Segurança da Informação, SRE, Boas Práticas, Tecnologia Bancária

 

Bellacosa Mainframe e o guard rails em desenvolvimento de software

Guard Rails: A Arte de Impedir que um Desenvolvedor Derrube o Banco

Uma conversa que todo desenvolvedor COBOL deveria ter

Imagine a seguinte situação.

Você acabou de entrar em uma instituição financeira.

É seu terceiro mês como desenvolvedor COBOL.

Depois de semanas corrigindo pequenos bugs, finalmente recebe uma tarefa importante.

Uma rotina responsável pelo envio de notificações para clientes.

O gerente explica:

— Precisamos incluir um novo tipo de comunicação.

Você faz a alteração.

Compila.

Executa os testes.

Tudo parece funcionar.

A mudança é promovida para produção.

Horas depois, milhares de clientes recebem uma mensagem errada.

O call center entra em colapso.

O aplicativo registra picos de acesso.

O time de negócios inicia uma reunião de emergência.

A diretoria quer explicações.

E então surge a pergunta:

Como isso foi possível?

A resposta geralmente não é:

"Porque o desenvolvedor errou."

A resposta correta costuma ser:

"Porque o sistema permitiu que um erro chegasse à produção."

É exatamente nesse ponto que surge um dos conceitos mais importantes da engenharia moderna:

Guard Rails.

---

O que são Guard Rails?

A tradução literal seria:

"trilhos de proteção".

A inspiração vem das rodovias.

Quando um carro sai da pista, existe uma barreira metálica para impedir que ele caia de um penhasco.

O guard rail não evita o erro do motorista.

Ele reduz as consequências.

Na engenharia de software acontece exatamente a mesma coisa.

Os desenvolvedores inevitavelmente cometerão erros.

Os analistas inevitavelmente esquecerão requisitos.

Os operadores inevitavelmente clicarão em algo errado.

Os administradores inevitavelmente executarão comandos incorretos.

O objetivo não é eliminar o erro humano.

O objetivo é impedir que o erro se transforme em desastre.

---

O erro é inevitável

Desenvolvedores juniores costumam acreditar que sistemas caem porque alguém não sabia programar.

Essa visão desaparece rapidamente em ambientes corporativos.

Os maiores incidentes da história da tecnologia não foram causados por programadores incompetentes.

Foram causados por profissionais experientes trabalhando sob pressão.

Pessoas excelentes.

Pessoas inteligentes.

Pessoas treinadas.

Pessoas humanas.

A questão nunca foi:

"Quem errou?"

A questão sempre foi:

"Por que o sistema permitiu?"

Essa diferença muda completamente a forma de construir software.

---

Um exemplo COBOL simples

Considere um programa que realiza transferência bancária.

Versão sem Guard Rails:

IF SALDO-CONTA > 0
   SUBTRACT VALOR FROM SALDO-CONTA
END-IF.

Parece correto.

Mas existe um problema.

Suponha:

Saldo = 100

Transferência = 1000

O programa permitirá saldo negativo.

Agora uma versão mais segura.

IF VALOR > SALDO-CONTA
   DISPLAY "TRANSFERENCIA NEGADA"
   GO TO FIM-PROGRAMA
END-IF.

O sistema agora protege o negócio.

Isso é um Guard Rail.

---

Guard Rail não é regra de negócio

Esse é um erro comum.

Muitos desenvolvedores confundem os dois conceitos.

Regra de negócio:

"O cliente não pode sacar mais que possui."

Guard Rail:

"Mesmo que alguém esqueça a regra, o sistema impedirá a operação."

Uma regra define comportamento.

Um Guard Rail protege comportamento.

---

A filosofia do mainframe

Durante décadas, os ambientes mainframe desenvolveram uma cultura diferente do mundo moderno.

Em startups existe uma frase famosa:

Move fast.

Nos bancos existe outra:

Don't break production.

A razão é simples.

Um erro em rede social gera reclamações.

Um erro bancário gera prejuízo.

Por isso o mundo COBOL sempre valorizou:

• validação;

• redundância;

• auditoria;

• segregação;

• rastreabilidade.

Sem perceber, os ambientes mainframe implementavam Guard Rails muito antes do conceito ganhar popularidade.

---

O caso clássico do JCL

Todo profissional de mainframe já ouviu histórias de horror envolvendo JCL.

Imagine um dataset:

CLIENTES.PRODUCAO

Agora imagine um utilitário de exclusão.

DELETE CLIENTES.PRODUCAO

Um comando simples.

Um erro simples.

Um desastre gigantesco.

Por isso empresas maduras criam Guard Rails.

Por exemplo:

• confirmação obrigatória;

• aprovação dupla;

• ambiente segregado;

• backup automático.

A exclusão continua possível.

Mas torna-se muito mais difícil.

---

O princípio do “Are You Sure?”

Existe uma categoria inteira de Guard Rails baseada em confirmação.

Exemplo.

Você tenta apagar um arquivo.

O sistema pergunta:

"Tem certeza?"

Parece algo trivial.

Mas essa simples pergunta já evitou milhões de erros ao longo da história da computação.

Em sistemas financeiros essa ideia evolui.

Em vez de uma confirmação:

• duas confirmações;

• dois operadores;

• dois gestores;

• duas aprovações.

Chamamos isso de Four Eyes Principle.

Princípio dos quatro olhos.

---

Guard Rails em processamento batch

O universo COBOL vive cercado de batches.

Folha de pagamento.

Compensação bancária.

Fechamento contábil.

Liquidação financeira.

Imagine um programa que processa:

10.000 registros

Normal.

Agora imagine:

100 milhões de registros

Algo está errado.

Sem Guard Rails o programa continua.

Com Guard Rails ele interrompe:

IF QTDE-REGISTROS > LIMITE-MAXIMO
   DISPLAY "PROCESSAMENTO ANORMAL"
   ABEND
END-IF.

Esse simples teste pode evitar horas de caos operacional.

---

O conceito de Fail Fast

Existe um princípio muito importante:

Fail Fast.

Falhe rapidamente.

Muitos sistemas tentam continuar funcionando mesmo após identificar inconsistências.

Isso parece inteligente.

Na prática costuma piorar tudo.

Se um dado crítico estiver errado, o melhor comportamento é parar imediatamente.

Exemplo:

IF CODIGO-CLIENTE = SPACES
   ABEND
END-IF.

Parar cedo é melhor do que produzir milhões de registros incorretos.

---

Guard Rails contra desenvolvedores

Esse é um tema que incomoda iniciantes.

Ninguém gosta de ouvir:

"O sistema precisa proteger a empresa de você."

Mas essa é a realidade.

Um Guard Rail existe justamente porque até profissionais excelentes erram.

Imagine um comando SQL.

Sem proteção:

DELETE FROM CLIENTES;

Com proteção:

DELETE FROM CLIENTES
WHERE ID = :CLIENTE;

Ou ainda melhor.

Permissão somente leitura em produção.

O desenvolvedor continua competente.

O ambiente apenas se torna mais seguro.

---

O incidente do Nubank e os Guard Rails

O caso do falso aviso de liquidação tornou-se um exemplo interessante.

Independentemente dos detalhes internos, uma pergunta surgiu:

Como uma comunicação tão crítica chegou aos clientes?

A resposta provavelmente envolve ausência ou falha de Guard Rails.

Por exemplo:

• validação insuficiente;

• aprovação inadequada;

• rollout inexistente;

• testes incompletos.

Nenhum sistema deveria conseguir informar a liquidação de um banco sem múltiplas camadas de proteção.

---

Rollout gradual

Imagine um envio para:

50 milhões de clientes

Sem Guard Rail:

envio imediato.

Com Guard Rail:

1% da base.

Validação.

5%.

Validação.

10%.

Validação.

100%.

Empresas como Google, Amazon e Netflix utilizam esse modelo constantemente.

O objetivo é reduzir o raio da explosão.

---

Blast Radius

Todo arquiteto experiente faz uma pergunta.

Se isso falhar, quantas pessoas serão afetadas?

Chamamos isso de Blast Radius.

Raio de explosão.

Exemplo.

Erro em um batch:

Impacto:

500 clientes.

Blast Radius pequeno.

Erro em compensação nacional:

Impacto:

50 milhões de clientes.

Blast Radius enorme.

Guard Rails existem para reduzir esse raio.

---

Observabilidade também é Guard Rail

Muitos desenvolvedores acreditam que Guard Rails são apenas validações.

Não.

Monitoramento também é proteção.

Imagine:

Processamento esperado:

1000 transações por minuto

Sistema detecta:

500.000 transações por minuto

Algo claramente está errado.

Um bom sistema dispara alarmes.

Isso também é Guard Rail.

---

O conceito de Circuit Breaker

Em sistemas distribuídos modernos existe outro Guard Rail famoso.

Circuit Breaker.

Inspirado nos disjuntores elétricos.

Se uma dependência começa a falhar:

o sistema corta a conexão.

Em vez de derrubar tudo.

No mundo mainframe encontramos equivalentes há décadas:

• limites operacionais;

• interrupções controladas;

• filas protegidas;

• rejeições automáticas.

A ideia é a mesma.

Conter danos.

---

O erro mais caro é o silencioso

Existe uma frase conhecida entre engenheiros de confiabilidade:

Sistemas barulhentos são irritantes.

Sistemas silenciosamente errados são perigosos.

Um programa que falha imediatamente chama atenção.

Um programa que produz dados incorretos durante três dias pode gerar prejuízos gigantescos.

Por isso Guard Rails modernos privilegiam transparência.

Tudo deve ser:

• registrado;

• monitorado;

• auditado;

• rastreável.

---

A maturidade profissional

Existe um momento na carreira em que o desenvolvedor deixa de pensar:

"Meu código funciona."

E começa a pensar:

"O que acontece quando ele falhar?"

Essa mudança separa programadores iniciantes de engenheiros experientes.

O foco deixa de ser funcionalidade.

Passa a ser confiabilidade.

---

O que um desenvolvedor COBOL Jr deve fazer

Sempre pergunte:

O que pode dar errado?

Quem será impactado?

Existe limite operacional?

Existe validação?

Existe rollback?

Existe auditoria?

Existe monitoramento?

Existe aprovação?

Existe segregação?

Existe plano de contingência?

Se alguma resposta for "não sei", continue investigando.

---

A grande lição

Guard Rails não existem porque desenvolvedores são ruins.

Eles existem porque sistemas são complexos.

Quanto maior a empresa, mais perigoso se torna assumir que ninguém cometerá erros.

O verdadeiro papel da engenharia não é criar sistemas perfeitos.

É criar sistemas resilientes.

Sistemas que sobrevivam a erros humanos.

Sistemas que sobrevivam a falhas operacionais.

Sistemas que sobrevivam a decisões equivocadas.

No universo bancário, onde bilhões de reais transitam diariamente por programas COBOL escritos ao longo de décadas, essa diferença não é apenas uma questão técnica.

É uma questão de sobrevivência operacional.

E talvez a principal lição para qualquer desenvolvedor COBOL Jr seja esta:

Seu trabalho não é apenas fazer o programa funcionar.

Seu trabalho é impedir que ele cause danos quando inevitavelmente algo der errado.

Esse é o verdadeiro significado de Guard Rails.

 

Bellacosa Mainframe e o blast radius em desenvolvimento de software

Blast Radius: Por Que um Pequeno Erro Pode Derrubar um Banco Inteiro

Uma das perguntas mais importantes da engenharia moderna

Imagine que você acabou de entrar em uma grande instituição financeira.

Você é um desenvolvedor COBOL Jr.

Recebe uma tarefa aparentemente simples.

Alterar uma rotina de validação em um programa batch.

O código possui apenas algumas linhas.

A mudança é pequena.

O teste passou.

O deploy foi aprovado.

Tudo parece sob controle.

Dois dias depois surge uma reunião de crise.

Executivos estão reunidos.

Gerentes estão nervosos.

Equipes de infraestrutura trabalham durante a madrugada.

Milhões de registros foram processados incorretamente.

O prejuízo é enorme.

E então alguém faz uma pergunta que todo arquiteto experiente conhece:

Qual era o Blast Radius dessa mudança?

Essa pergunta vale mais do que qualquer revisão de código.

Mais do que qualquer ferramenta de monitoramento.

Mais do que qualquer framework moderno.

Porque ela determina o tamanho potencial do desastre.

---

O que significa Blast Radius?

A tradução literal seria:

Raio de Explosão.

O termo vem do universo militar.

Quando ocorre uma explosão, existe uma área diretamente afetada.

Quanto maior a explosão, maior o raio de destruição.

A engenharia de software adotou exatamente a mesma ideia.

Quando um sistema falha, uma pergunta precisa ser respondida:

Quantas pessoas, sistemas, operações ou clientes serão impactados?

Essa área de impacto é chamada Blast Radius.

---

O erro que afeta um cliente

Imagine um programa COBOL responsável por atualizar dados cadastrais.

Um erro afeta:

1 cliente

Problema?

Sim.

Crise?

Provavelmente não.

O impacto é localizado.

O Blast Radius é pequeno.

---

O erro que afeta um banco inteiro

Agora imagine um programa responsável pela compensação financeira nacional.

Um erro afeta:

30 milhões de clientes

Mesma quantidade de linhas alteradas.

Mesmo programador.

Mesmo tipo de erro.

Resultado completamente diferente.

Por quê?

Porque o Blast Radius mudou.

---

A pergunta que diferencia um programador de um engenheiro

O desenvolvedor iniciante normalmente pergunta:

Meu código funciona?

O engenheiro experiente pergunta:

O que acontece se ele falhar?

Essa mudança de mentalidade é uma das maiores evoluções na carreira de tecnologia.

Porque sistemas críticos não são avaliados apenas pelo sucesso.

Eles são avaliados pela forma como falham.

---

O mito do pequeno erro

Existe uma crença perigosa em ambientes corporativos.

"Foi só uma alteração pequena."

O tamanho do código raramente determina o tamanho do impacto.

Um único caractere já derrubou sistemas inteiros.

Um único parâmetro incorreto já gerou perdas milionárias.

Uma única configuração errada já interrompeu operações globais.

O impacto depende do Blast Radius.

Não da quantidade de código.

---

O universo COBOL e o poder invisível

Desenvolvedores COBOL trabalham em uma situação peculiar.

Muitas vezes manipulam sistemas que movimentam bilhões de reais diariamente.

Mas a interface parece simples.

Uma tela verde.

Alguns arquivos.

JCLs.

Datasets.

Rotinas batch.

Tudo parece tranquilo.

Até que alguém descobre que aquele programa processa:

• contas correntes;

• cartões;

• empréstimos;

• investimentos;

• liquidações;

• compensações.

De repente o código ganha outra dimensão.

---

O efeito dominó

Imagine uma falha em um cadastro.

Cliente incorreto.

Esse dado alimenta:

• CRM;

• antifraude;

• cobrança;

• compliance;

• atendimento;

• relatórios regulatórios.

Agora uma pequena falha inicial se transforma em dezenas de falhas secundárias.

Isso é amplificação de Blast Radius.

---

O conceito de dependências

Sistemas modernos não vivem isolados.

Um programa chama outro.

Que chama outro.

Que alimenta outro.

Que gera arquivos para outro.

O resultado é uma rede gigantesca.

Quando um componente falha, o impacto se propaga.

Como peças de dominó.

---

O exemplo do CPF inválido

Imagine uma rotina simples.

Um CPF inválido passa pela validação.

O erro parece pequeno.

Mas esse dado segue adiante.

Abre conta.

Gera cartão.

Produz relatórios.

Entra em auditorias.

Alimenta modelos analíticos.

Meses depois ninguém sabe mais onde o problema começou.

O Blast Radius cresceu silenciosamente.

---

O incidente do Nubank como estudo de caso

O episódio envolvendo o falso aviso de liquidação trouxe uma lição interessante.

Independentemente dos detalhes internos, a pergunta arquitetural é:

Qual era o Blast Radius daquele processo?

Se a mensagem atingisse:

10 clientes

O incidente seria pequeno.

Se atingir milhões:

O cenário muda completamente.

A mesma falha produz consequências exponencialmente maiores.

---

Blast Radius e ambientes de produção

Uma regra simples:

Quanto mais próximo da produção, maior o Blast Radius.

Ambiente de desenvolvimento:

Impacto quase zero.

Homologação:

Impacto limitado.

Produção:

Impacto real.

Produção financeira:

Impacto potencialmente gigantesco.

É por isso que instituições financeiras possuem tantos controles.

Não por burocracia.

Mas porque o custo do erro é enorme.

---

O perigo dos batches

O mundo COBOL é dominado por processamento em massa.

Um programa pode executar durante horas.

Processando milhões de registros.

O problema é simples.

Se houver um erro:

Ele será repetido milhões de vezes.

Um erro individual torna-se um erro industrializado.

---

O erro multiplicado

Imagine:

1 registro incorreto

Sem batch:

impacto pequeno.

Agora imagine:

50 milhões de registros

Processados pela mesma lógica defeituosa.

O erro não mudou.

O Blast Radius mudou.

---

Como arquitetos pensam

Arquitetos raramente perguntam:

"Qual tecnologia usamos?"

Eles perguntam:

"Qual o pior cenário possível?"

Essa pergunta direciona toda a arquitetura.

Porque sistemas críticos são construídos para sobreviver a falhas.

Não apenas para funcionar.

---

Blast Radius e permissões

Um desenvolvedor possui acesso de leitura.

Blast Radius reduzido.

Um desenvolvedor possui acesso irrestrito.

Blast Radius elevado.

É por isso que ambientes maduros trabalham com:

• menor privilégio;

• segregação;

• controle de acesso;

• aprovações.

Tudo isso é gestão de Blast Radius.

---

Blast Radius e banco de dados

Imagine um comando SQL.

Primeiro cenário:

UPDATE CLIENTES
SET STATUS='A'
WHERE ID=100;

Impacto:

um cliente.

Segundo cenário:

UPDATE CLIENTES
SET STATUS='A';

Impacto:

todos os clientes.

A diferença visual é mínima.

A diferença operacional é gigantesca.

---

O princípio da contenção

Existe uma palavra muito importante.

Contenção.

Todo sistema moderno deveria conter falhas.

Não espalhá-las.

Por isso empresas investem em:

• segmentação;

• isolamento;

• partições;

• zonas independentes.

O objetivo é impedir que uma falha local se torne global.

---

O conceito de células

Empresas como Amazon popularizaram a ideia de Cell Architecture.

Em vez de uma estrutura única gigante.

Criam-se células menores.

Se uma célula falhar:

As demais continuam operando.

Isso reduz drasticamente o Blast Radius.

---

Mainframe já fazia isso há décadas

Curiosamente, ambientes mainframe utilizavam conceitos semelhantes muito antes da computação em nuvem.

Exemplos:

• LPARs;

• regiões CICS;

• filas separadas;

• ambientes segregados;

• jobs independentes.

A filosofia era exatamente a mesma.

Conter impactos.

---

O problema do compartilhamento excessivo

Quanto mais sistemas compartilham recursos, maior o Blast Radius.

Banco compartilhado.

Fila compartilhada.

Storage compartilhado.

Processamento compartilhado.

Tudo isso cria pontos únicos de falha.

Um problema em um componente afeta dezenas de outros.

---

O conceito de Blast Radius Humano

Pouca gente fala sobre isso.

Mas pessoas também possuem Blast Radius.

Imagine:

Um único operador consegue executar qualquer comando em produção.

Blast Radius enorme.

Agora imagine:

Necessidade de aprovação dupla.

Blast Radius reduzido.

A governança existe para limitar o alcance dos erros humanos.

---

O papel dos Guard Rails

Blast Radius e Guard Rails caminham juntos.

Guard Rails tentam impedir erros.

Blast Radius tenta limitar consequências.

Exemplo:

Guard Rail:

impedir exclusão acidental.

Blast Radius:

caso a exclusão ocorra, limitar o impacto.

São conceitos complementares.

---

Rollout gradual

Uma das formas mais modernas de controlar Blast Radius é o rollout progressivo.

Em vez de liberar uma mudança para todos.

Liberamos para poucos.

Por exemplo:

1%.

Depois 5%.

Depois 10%.

Depois 100%.

Se houver erro, ele será detectado cedo.

O impacto permanece pequeno.

---

O medo saudável da produção

Existe uma característica interessante nos profissionais experientes de mainframe.

Eles respeitam produção.

Não porque tenham medo da tecnologia.

Mas porque entendem o Blast Radius.

Produção concentra:

• clientes;

• dinheiro;

• contratos;

• obrigações regulatórias;

• reputação.

Uma pequena falha pode produzir consequências gigantescas.

---

Observabilidade e Blast Radius

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

Por isso monitoramento é fundamental.

Imagine um batch que normalmente processa:

500 mil registros

Hoje processou:

50 milhões

Algo claramente está errado.

Um sistema observável detecta rapidamente.

Quanto mais cedo o problema é identificado, menor o Blast Radius.

---

O custo da reputação

Em bancos existe um ativo invisível.

Confiança.

Quando uma falha afeta poucos clientes, a recuperação costuma ser simples.

Quando afeta milhões, surge um problema adicional.

Reputação.

O Blast Radius passa a incluir:

• imprensa;

• investidores;

• reguladores;

• mercado.

O dano deixa de ser apenas tecnológico.

---

O exercício mental que todo COBOL Jr deveria fazer

Antes de qualquer alteração, pergunte:

Se eu errar:

• Quantos clientes serão impactados?

• Quantos sistemas dependem disso?

• Existe rollback?

• Existe monitoramento?

• Existe plano de contingência?

• Existe limite operacional?

• Existe validação?

• Existe segregação?

Essas perguntas valem mais do que qualquer linha de código.

---

A verdadeira maturidade profissional

Existe um momento em que o desenvolvedor deixa de ser apenas um programador.

Ele passa a enxergar sistemas.

Passa a enxergar operações.

Passa a enxergar negócios.

Passa a enxergar riscos.

Nesse momento surge uma nova pergunta.

Não mais:

O programa funciona?

Mas sim:

Qual é o Blast Radius se ele parar de funcionar?

Essa mudança de perspectiva transforma a forma de desenvolver software.

---

Conclusão

Blast Radius é um dos conceitos mais importantes da engenharia moderna porque nos obriga a pensar além do código.

Ele nos força a enxergar impacto.

A enxergar consequências.

A enxergar riscos.

Para um desenvolvedor COBOL Jr, compreender Blast Radius significa entender que o tamanho de uma alteração não determina sua importância.

Uma linha de código pode alterar milhões de contas.

Um único parâmetro pode interromper operações nacionais.

Uma pequena falha pode se propagar por dezenas de sistemas.

Os melhores engenheiros não são aqueles que acreditam que nunca errarão.

São aqueles que projetam sistemas assumindo que erros inevitavelmente acontecerão.

E quando eles acontecerem, o objetivo não será impedir a explosão.

Será garantir que o raio da explosão seja o menor possível.

Esse é o verdadeiro significado de Blast Radius.

 

Bellacosa Mainframe e o assistente de IA LLM RAG

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

"Primeiro ele responde perguntas. Depois organiza tarefas. Em seguida consulta sistemas. Quando você percebe, existe uma inteligência trabalhando ao seu lado 24 horas por dia."

---

🚀 Afinal, o que é um Assistente de IA?

Imagine um operador de computador que:

✅ Nunca dorme
✅ Nunca tira férias
✅ Nunca esquece um procedimento
✅ Aprende com documentação
✅ Conversa em linguagem natural

Um Assistente de Inteligência Artificial é um software capaz de compreender perguntas, interpretar contexto, acessar informações e executar tarefas para auxiliar pessoas em suas atividades.

Diferente de um chatbot tradicional, que segue roteiros pré-definidos, um assistente moderno utiliza modelos de linguagem (LLMs) para raciocinar sobre problemas e gerar respostas dinâmicas.

Na prática, ele pode:

• Responder dúvidas técnicas

• Gerar código

• Criar documentos

• Automatizar processos

• Consultar bancos de dados

• Executar fluxos de negócio

• Integrar sistemas corporativos

• Apoiar decisões operacionais

Pense nele como uma mistura de:

• Analista de Sistemas

• Operador

• DBA

• Documentador

• Programador

• Professor

Tudo em uma única interface.

---

🏛️ O Assistente de IA no Mundo Mainframe

Imagine um assistente treinado com:

• JCL

• COBOL

• CICS

• DB2

• IMS

• RACF

• TSO/ISPF

• JES2

• z/OS

Você poderia perguntar:

"Por que este JOB deu ABEND S0C7?"

ou

"Monte um JCL para copiar um VSAM KSDS."

ou

"Explique a diferença entre EXEC CICS LINK e XCTL."

Em segundos ele produziria:

• Explicações

• Diagnósticos

• Exemplos

• Sugestões de correção

É como ter um especialista Bellacosa Mainframe disponível 24x7.

---

🔧 Como Construir um Assistente de IA?

Hoje existem vários caminhos.

Caminho 1 — O Mais Simples

Utilizar plataformas prontas:

• GPTs personalizados

• Assistants

• Copilots

• No-Code AI Builders

Você fornece:

• Documentação

• PDFs

• Manuais

• Procedimentos

E o assistente aprende aquele contexto.

Ideal para:

• Empresas

• Equipes de suporte

• Times de treinamento

---

Caminho 2 — Assistente com Base de Conhecimento

Arquitetura típica:

Usuário
   │
   ▼
Assistente IA
   │
   ▼
Base de Conhecimento
   │
   ├── PDFs
   ├── Manuais
   ├── Wikis
   ├── Procedimentos
   └── Documentação Técnica

O modelo consulta documentos antes de responder.

Chamamos isso de:

RAG (Retrieval Augmented Generation)

É uma das arquiteturas mais populares atualmente.

---

Caminho 3 — Assistente Corporativo

Aqui a brincadeira fica séria.

Usuário
   │
   ▼
Assistente IA
   │
   ├── SAP
   ├── Mainframe
   ├── Banco de Dados
   ├── ServiceNow
   ├── Jira
   ├── APIs
   └── Sistemas Legados

O assistente deixa de apenas responder.

Ele passa a:

• Consultar sistemas

• Abrir chamados

• Executar processos

• Atualizar registros

Estamos entrando no território dos Agentes de IA.

---

🎯 O Que Eu Ganho Construindo Um?

Muito mais do que parece.

1. Produtividade

Tarefas que demoravam horas passam a levar minutos.

---

2. Documentação Viva

Em vez de procurar em centenas de PDFs:

CTRL+F
CTRL+F
CTRL+F
CTRL+F

Você simplesmente pergunta.

---

3. Treinamento Acelerado

Novatos aprendem mais rápido.

Um júnior pode consultar o assistente constantemente.

---

4. Preservação do Conhecimento

Quando especialistas se aposentam, muito conhecimento desaparece.

O assistente pode ajudar a preservar:

• Procedimentos

• Boas práticas

• Lições aprendidas

---

5. Disponibilidade 24x7

Não importa:

• Madrugada

• Feriado

• Final de semana

O assistente continua disponível.

---

⚠️ As Desvantagens

Nem tudo é magia.

Alucinações

O maior problema atual.

A IA pode responder com enorme confiança algo completamente errado.

Exemplo:

"Qual parâmetro resolve esse ABEND?"

Ela pode inventar uma solução inexistente.

---

Dependência Excessiva

Algumas pessoas param de pensar.

Começam a copiar respostas sem validar.

Isso é extremamente perigoso.

---

Custo

Modelos avançados podem gerar custos relevantes.

Especialmente em grandes empresas.

---

Segurança

Documentos enviados para modelos externos podem conter:

• Dados sensíveis

• Segredos corporativos

• Informações confidenciais

Governança é obrigatória.

---

☠️ Os Caminhos Tenebrosos

Agora entramos na sala escura do datacenter.

Luzes piscando.

Ar-condicionado rugindo.

Alarmes ao fundo.

---

Caminho Tenebroso #1

Confiar Cegamente na IA

A IA não é uma autoridade.

Ela é uma ferramenta.

Quem assina a decisão continua sendo o humano.

---

Caminho Tenebroso #2

Alimentar a IA com Dados Incorretos

Existe uma regra antiga:

Garbage In
Garbage Out

Se o treinamento estiver errado:

As respostas estarão erradas.

---

Caminho Tenebroso #3

Expor Informações Sigilosas

Jamais envie para modelos públicos:

• Senhas

• Chaves de API

• Dumps confidenciais

• Dados de clientes

Uma única falha pode gerar consequências enormes.

---

Caminho Tenebroso #4

Automatizar Sem Controle

Um assistente que apenas responde é uma coisa.

Um assistente que executa comandos é outra completamente diferente.

Imagine:

DELETE PRODUCAO

executado automaticamente.

Nem preciso explicar o restante da história...

---

Caminho Tenebroso #5

Substituir Conhecimento Humano

O objetivo não é eliminar especialistas.

É amplificar sua capacidade.

O melhor cenário é:

Humano + IA

e não

Humano OU IA

---

🎓 O Futuro

Estamos caminhando para uma era onde cada profissional terá seu próprio assistente especializado.

Um desenvolvedor terá um assistente de programação.

Um médico terá um assistente clínico.

Um advogado terá um assistente jurídico.

E um profissional de Mainframe poderá ter algo como:

"Bellacosa Mainframe Assistant"

Capaz de explicar:

• JES2

• RACF

• CICS

• DB2

• COBOL

• JCL

• z/OS

com exemplos, laboratórios e diagnósticos.

---

☕💣 Conclusão Bellacosa Mainframe

O assistente de IA não é o fim do operador.

Não é o fim do programador.

Não é o fim do analista.

Ele é uma nova camada de abstração, assim como:

• Assembly evoluiu para COBOL

• Cartões perfurados evoluíram para terminais

• Terminais evoluíram para interfaces gráficas

• Interfaces evoluíram para a Web

Agora estamos entrando na era da conversa.

A pergunta não é mais:

"Como faço isso?"

Mas sim:

"Como explico para a IA o que eu preciso?"

Quem dominar essa habilidade terá uma vantagem semelhante à de quem aprendeu internet nos anos 90 ou computação em nuvem nos anos 2000.

Porque, no fim das contas, o maior poder da IA não está em responder perguntas.

Está em transformar conhecimento em ação.

E isso, meu amigo operador, é algo que merece um café forte antes do próximo IPL. ☕🚀💣

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.