☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sexta-feira, 7 de agosto de 2026

O Spread do Conhecimento: Matrix, COBOL e o Profissional de R$ 200/h que Recebe R$ 55

Bellacosa Mainframe e o spread do conhecimento por que $200/h não é igual $50/h

☕ Um Café no Bellacosa Mainframe

O Spread do Conhecimento: Matrix, COBOL e o Profissional de R$ 200/h que Recebe R$ 55

🔴🔵 Uma viagem pela Matrix corporativa para entender quanto custa o conhecimento, quem assume o risco e por que o profissional que faz o trabalho pode receber apenas uma pequena parcela do valor cobrado por ele

Por Vagner Bellacosa


Há uma cena de Matrix que sempre me chamou atenção.

Thomas Anderson trabalha em uma grande empresa de software.

Não parece ser um desempregado.

Não parece ser alguém sem qualificação.

Muito pelo contrário.

Anderson é programador.

Conhece computadores.

Entende sistemas.

E, quando deixa o escritório e assume sua segunda identidade, descobrimos que Neo possui habilidades suficientemente valiosas para existir também em uma pequena economia clandestina.

Mesmo assim, sua vida é surpreendentemente modesta.

Apartamento pequeno.

Pouco luxo.

Noites diante do computador.

Um emprego durante o dia.

Outra vida durante a noite.

E boletos.

Sempre os boletos.

Talvez os verdadeiros Agentes da Matrix nunca tenham usado terno preto.

Talvez venham impressos com código de barras.

Porque existe uma característica extraordinária nos boletos:

RECEITA: EVENTUAL
EMPREGO: INSTÁVEL
PROJETO: TEMPORÁRIO
BOLETO: 24x7

Você pode perder o emprego.

Pode terminar o projeto.

Pode ficar alguns meses procurando uma nova oportunidade.

Mas tente explicar isso para a conta de energia.

Ela não demonstra muita empatia.

Foi pensando nisso que comecei a observar uma das contradições mais curiosas da indústria de tecnologia.

Um banco pode movimentar bilhões.

Um sistema pode processar milhões de transações.

Uma aplicação pode permanecer funcionando durante vinte ou trinta anos.

Mas o profissional que ajudou a construir tudo aquilo pode terminar o projeto numa sexta-feira e começar a segunda-feira seguinte procurando emprego.

Não estou dizendo que existe necessariamente algo errado nisso.

Também não estou dizendo que o programador deveria ser proprietário do banco.

Muito menos que consultorias são parasitas ou que empresas não assumem riscos.

A realidade é muito mais interessante.

E justamente por isso merece uma conversa.

Morpheus está esperando.

Sobre a mesa existem duas pílulas.

🔵 A azul diz:

"Você foi contratado para fazer um trabalho. Recebeu por ele. O contrato terminou. Vida que segue."

🔴 A vermelha pergunta:

"Quanto realmente custou produzir o conhecimento que tornou aquele trabalho possível — e quem capturou o valor produzido por ele?"

Pegue seu café.

Vamos descobrir até onde vai essa toca do coelho.


💊 A pílula azul: você recebeu pelo trabalho

Vamos começar pelo argumento mais óbvio.

Uma empresa contrata alguém.

Esse profissional aceita determinadas condições.

Executa o serviço.

Recebe aquilo que foi combinado.

Fim.

Existe algo errado nisso?

Em princípio, não.

A empresa possui capital.

Possui infraestrutura.

Consegue clientes.

Assume riscos.

Paga impostos.

Mantém departamentos jurídicos, comerciais, administrativos e técnicos.

Pode investir milhões em um projeto que fracassa completamente.

Se houver prejuízo, normalmente ninguém telefona para o programador dizendo:

— João, aquele sistema que você ajudou a desenvolver perdeu R$ 30 milhões. Poderia depositar sua parte do prejuízo?

Naturalmente não.

Portanto, existe um argumento perfeitamente razoável:

quem assume maior risco econômico também espera capturar parte maior do retorno econômico.

Isso é capitalismo básico.

Mas...

Sempre existe um BUT escondido em algum lugar do código.

IF ARGUMENTO = "SIMPLES"
   PERFORM OLHAR-MAIS-DE-PERTO
END-IF.

Porque existe outro risco que raramente aparece nessa conta.

O risco do profissional.


🔴 Quanto custou você aprender aquilo que sabe?

Imagine um programador COBOL experiente.

Quando uma empresa o contrata, ela não está comprando apenas oito horas daquele dia.

Está acessando algo que levou talvez vinte anos para ser construído.

COBOL.

JCL.

Db2.

CICS.

VSAM.

MQ.

IMS.

RACF.

Git.

APIs.

Regras de negócio.

Experiência em produção.

Incidentes.

Madrugadas.

Erros.

Livros.

Cursos.

Certificações.

Laboratórios.

Documentação.

Projetos anteriores.

E milhares de pequenas experiências que nunca aparecerão no currículo.

Quanto custou isso?

Normalmente calculamos assim:

Curso .................... R$ 500
Livro .................... R$ 150
Certificação ............. R$ 800

Mas existe uma linha invisível nessa planilha:

TEMPO .................... ???

Suponha que você tenha estudado 100 horas para aprender determinada tecnologia.

Foram 100 horas que poderiam ter sido usadas para trabalhar.

Ou dormir.

Ou viajar.

Ou brincar com os filhos.

Ou assistir Matrix pela 37ª vez procurando Easter Eggs.

Ou simplesmente ficar olhando para o teto.

O ócio também possui valor.

Economistas chamam isso de custo de oportunidade.

Você escolheu estudar.

Logo, abriu mão de alguma outra coisa.

Agora multiplique isso por dez, vinte ou trinta anos de carreira.

De repente percebemos algo curioso:

o profissional é uma empresa que investe continuamente em P&D sobre si próprio.

E geralmente faz isso com capital próprio.


🧪 O laboratório chamado "você"

Existe ainda outro problema.

Nem todo conhecimento adquirido dará retorno.

Você pode passar seis meses aprendendo uma tecnologia porque todo mundo garante:

"Isso é o futuro!"

Seis meses depois:

"Aquilo morreu. Agora o futuro é outra coisa."

Bem-vindo à tecnologia.

Você assumiu o risco.

Comprou o curso.

Gastou noites.

Montou laboratório.

Leu documentação.

Talvez tenha pago certificação.

E descobriu que o mercado mudou.

Quem indeniza esse investimento?

Ninguém.

Você escolheu a pílula errada.

Tente novamente.

Isso significa que empresas não assumem riscos?

Claro que não.

Elas assumem enormes riscos.

Mas precisamos abandonar uma simplificação:

"A empresa assume o risco e o trabalhador recebe salário."

Existem diferentes tipos de risco.

A empresa possui risco empresarial e de capital.

O profissional possui risco de empregabilidade, renda, formação e obsolescência.

São riscos diferentes.

E podem coexistir.


🏦 Bem-vindo ao banco

Agora nosso Neo consegue um projeto.

Parabéns!

Existe um grande banco precisando de alguém com seus conhecimentos.

O banco possui dinheiro para contratar especialistas.

Digamos, apenas para construir um exemplo hipotético, que esteja disposto a pagar:

R$ 200 por hora.

Mas grandes organizações raramente contratam cada especialista diretamente.

Então aparece uma consultoria.

BANCO
  │
  │ R$ 200/h
  ▼
CONSULTORIA A

A consultoria possui contrato.

Conhece procurement.

Atende requisitos de compliance.

Mantém estrutura comercial.

Possui seguros.

Gerencia contratos.

Assume responsabilidades.

Isso possui valor.

Portanto:

BANCO
  │ R$ 200/h
  ▼
CONSULTORIA A
  │ R$ 160/h
  ▼

Até aqui, perfeitamente compreensível.

Mas talvez a Consultoria A também não possua aquele especialista.

Ela procura um parceiro.

BANCO
  │ R$ 200
  ▼
CONSULTORIA A
  │ R$ 160
  ▼
CONSULTORIA B
  │ R$ 120
  ▼

A Consultoria B encontra outro fornecedor.

BANCO
  │ R$ 200
  ▼
CONSULTORIA A
  │ R$ 160
  ▼
CONSULTORIA B
  │ R$ 120
  ▼
FORNECEDOR C
  │ R$ 85
  ▼
PROFISSIONAL
    R$ 55

ATENÇÃO.

Esses valores são deliberadamente ilustrativos.

Não estou afirmando que essa seja a margem real de qualquer empresa ou setor.

A pergunta é conceitual.

O banco desembolsa R$ 200 por uma hora de determinada capacidade técnica.

O profissional que efetivamente possui essa capacidade recebe R$ 55.

Entre os dois existem R$ 145.

Esse dinheiro não desapareceu.

Ele remunerou alguma coisa.

Administração.

Comercial.

Risco.

Impostos.

Gestão.

Compliance.

Recrutamento.

Lucro.

Infraestrutura.

E margens intermediárias.

Talvez tudo seja perfeitamente justificável.

Mas Morpheus coloca novamente as duas pílulas sobre a mesa.

🔵 Quanto custa contratar esse profissional?

🔴 Quanto valor cada camada realmente adicionou até ele chegar ao teclado?

São perguntas diferentes.


💰 O Spread do Conhecimento

Quem trabalha em banco conhece muito bem uma palavra:

spread.

Simplificando bastante, existe uma diferença entre o custo de determinado recurso financeiro e o preço pelo qual ele é disponibilizado.

Então pensei:

talvez exista algo semelhante na indústria de conhecimento.

Chamo isso, provocativamente, de:

Spread do Conhecimento

Podemos representar assim:

VALOR PAGO PELO CONHECIMENTO
              -
VALOR RECEBIDO POR QUEM POSSUI O CONHECIMENTO
              =
SPREAD DO CONHECIMENTO

Cuidado.

O spread não é automaticamente lucro.

Existem custos legítimos no meio.

A provocação é outra:

quanto maior a cadeia de intermediação, maior pode se tornar a distância entre o valor pago pelo cliente e o valor recebido pelo especialista.

E aparece uma pergunta fascinante:

O profissional sabe quanto sua hora custa na outra ponta?

Frequentemente, não.

E talvez o banco também não saiba quanto chega efetivamente ao profissional.

Essa opacidade interessa a quem?

Boa pergunta.

Pílula vermelha ou azul?

Você decide.


🧑‍💻 O paradoxo do profissional indispensável e descartável

Durante o projeto:

— Precisamos urgentemente de alguém com COBOL, CICS, Db2, VSAM, MQ, RACF, APIs, Git e experiência no mercado financeiro!

Depois do projeto:

— Obrigado. Seu acesso será desativado às 18h.

Três meses depois:

— Alguém sabe por que o programa XPTO possui esse IF?

Silêncio.

— Quem escreveu isso?

— Era um terceiro.

— Onde ele está?

— O contrato terminou.

— Temos documentação?

...

Houston, temos um problema.

Ou melhor:

Morpheus, temos um problema.

Existe conhecimento que pode ser documentado.

E existe conhecimento tácito.

É aquilo que o profissional aprendeu convivendo com o sistema.

Ele sabe que determinada rotina precisa rodar antes de outra.

Sabe que aquele campo aparentemente inútil existe porque um sistema externo ainda o utiliza.

Sabe que aquele IF estranho foi colocado ali depois de um incidente ocorrido quinze anos atrás.

Na documentação existe:

CAMPO-STATUS PIC X.

Na cabeça do veterano existe:

"Não coloque '9' nisso entre 23:55 e 00:10 porque o sistema Y ainda está fechando o movimento e você vai acordar metade da operação."

Boa sorte colocando isso no inventário patrimonial.


🧠 O ativo que não aparece no balanço

Hardware aparece.

Software aparece.

Licenças aparecem.

Contratos aparecem.

Cloud aparece.

Datacenter aparece.

Mas uma parte enorme do conhecimento organizacional vive em pessoas.

E pessoas possuem uma característica inconveniente:

elas vão embora.

Principalmente quando são tratadas exclusivamente como:

RESOURCE_ID = 92731
STATUS      = CONTRACTOR
END_DATE    = 30/09/2026

A empresa pode ser proprietária do código.

Mas isso não significa que seja proprietária de todas as conexões mentais utilizadas para construí-lo.

Essa diferença só costuma ficar evidente quando alguma coisa quebra.


🚨 03:17 da manhã

Produção parou.

War Room aberta.

Executivos entrando.

Operação olhando logs.

DBA olhando banco.

Sysprog olhando sistema.

Desenvolvimento olhando código.

Até alguém dizer:

— Chamem o Carlos.

— Carlos?

— Sim. Ele trabalhou nisso.

— Ele ainda está aqui?

— Não.

— Quando saiu?

— Dois anos atrás.

— Para onde foi?

...

Nesse momento acontece um milagre contábil.

Um profissional que aparentemente valia R$ 55/h às 17h de sexta-feira pode adquirir valor extraordinário às 03:17 da terça-feira.

O código não mudou.

O conhecimento não mudou.

Mudou apenas nossa percepção sobre seu valor.


💊 Mas existe outra pílula azul importante

Seria intelectualmente desonesto transformar essa discussão em:

"programador bom, empresa má."

Não funciona assim.

Uma aplicação bancária não produz bilhões simplesmente porque alguém escreveu COBOL.

Existem milhares de pessoas envolvidas.

Arquitetura.

Operações.

Segurança.

Auditoria.

Compliance.

Jurídico.

Produto.

Negócio.

Infraestrutura.

Atendimento.

Gestão.

Regulação.

Executivos.

Investidores.

Clientes.

E décadas de capital acumulado.

O programador não criou sozinho aquele valor.

Da mesma forma, movimentar R$ 10 bilhões através de um programa não significa que o programador produziu R$ 10 bilhões.

Essa distinção é essencial.

Caso contrário nossa pílula vermelha vira apenas outra ilusão.


🔴 Então qual é a verdadeira pergunta?

Talvez seja esta:

A maneira como remuneramos conhecimento especializado representa adequadamente o investimento, o risco e o valor econômico desse conhecimento?

Não sei.

E desconfio de qualquer pessoa que tenha uma resposta simples.

Mas sei que vale perguntar.

Principalmente quando terceirização vira quarteirização.

E quarteirização vira uma cadeia tão grande que o profissional que efetivamente faz o trabalho sequer conhece quem originalmente está pagando por ele.


📚 "Mas você aceitou o contrato"

Sim.

Esse argumento também é válido.

Neo poderia continuar na MetaCortex.

Anderson poderia chegar no horário.

O profissional pode recusar determinado valor.

Em teoria.

Mas mercados reais possuem assimetria de poder e informação.

O banco sabe quanto paga.

A primeira consultoria sabe quanto recebe.

A segunda conhece sua margem.

O fornecedor conhece sua margem.

O profissional normalmente conhece apenas:

R$ 55/h
ACEITA?
SIM / NÃO

Ele pode negociar.

Mas negocia conhecendo toda a cadeia?

Provavelmente não.

Isso torna o contrato inválido?

Não.

Mas torna o mercado perfeitamente transparente?

Também não.

Duas coisas podem ser verdade ao mesmo tempo.

Bem-vindo à Matrix.


👔 Os agentes não precisam ser vilões

Talvez essa seja a parte mais importante deste café.

Não precisamos procurar vilões.

O gerente da consultoria provavelmente também possui metas.

O recrutador possui metas.

O procurement possui metas.

O executivo precisa reduzir custos.

O banco precisa gerar retorno.

O profissional precisa pagar boletos.

Cada pessoa está executando racionalmente sua pequena parte do sistema.

E o resultado agregado pode produzir algo que nenhuma delas planejou individualmente.

Isso é muito mais interessante do que uma conspiração.

Sistemas não precisam de vilões para produzir resultados estranhos.

Às vezes basta cada agente seguir suas próprias regras.

Quem trabalha com mainframe deveria entender isso melhor do que ninguém.


🐇 Follow the white rabbit

Talvez abrir os olhos da comunidade não signifique dizer:

"Vocês estão sendo explorados."

Isso seria simplista.

Talvez signifique ensinar cada profissional a perguntar:

Quanto investi na minha formação?

Quanto vale minha experiência?

Quanto custa substituir meu conhecimento?

Quanto minha hora custa para o cliente?

Quantas camadas existem entre mim e ele?

Que riscos a empresa assume?

Que riscos eu assumo?

Que valor cada intermediário adiciona?

Estou sendo remunerado apenas pelo meu tempo ou também pela raridade do meu conhecimento?

Estou construindo conhecimento transferível para minha próxima oportunidade?

Minha dependência deste contrato é maior do que a dependência da empresa em relação a mim?

E principalmente:

eu conheço meu próprio valor econômico ou apenas conheço meu salário?

Essa última pergunta pode ser desconfortável.

Talvez seja justamente por isso que vale fazê-la.


🤖 E então chegou a Inteligência Artificial

Agora coloque IA generativa dentro dessa equação.

Ficou interessante, não?

Durante décadas, profissionais produziram:

código,

documentação,

livros,

artigos,

perguntas,

respostas,

exemplos,

tutoriais,

fóruns,

manuais,

experiência coletiva.

Agora construímos máquinas capazes de transformar grandes quantidades de conhecimento em novas respostas e novos códigos.

E as antigas perguntas retornam maiores:

Quem produziu o conhecimento original?

Quem financiou sua produção?

Quem possui o resultado?

Quem captura o ganho de produtividade?

Se um desenvolvedor com IA produz aquilo que antes exigia três profissionais, quem captura essa diferença?

O desenvolvedor?

O cliente?

A consultoria?

O fornecedor da IA?

Todos?

Em quais proporções?

A toca do coelho ficou muito mais funda.


🏦 Juros compostos do conhecimento

Existe uma última ironia que adoro.

Bancos compreendem perfeitamente juros compostos.

Um capital aplicado hoje pode produzir valor durante anos.

Conhecimento funciona de maneira semelhante.

Você aprende COBOL.

Depois aprende CICS.

CICS ajuda a compreender transações.

Transações ajudam a entender sistemas distribuídos.

Depois chegam APIs.

Depois cloud.

Depois DevOps.

Depois IA.

O conhecimento novo não simplesmente substitui o anterior.

Frequentemente ele se conecta.

EXPERIÊNCIA
     +
ESTUDO
     +
ERROS
     +
PROJETOS
     +
TEMPO
     =
CAPITAL INTELECTUAL

São os juros compostos da carreira.

Só existe uma diferença curiosa.

O banco sabe calcular perfeitamente os juros compostos do dinheiro.

Nós, profissionais, frequentemente somos péssimos em calcular os juros compostos do nosso próprio conhecimento.


🏛️ Espera... faltou alguém na Matrix

Até agora nossa arquitetura tinha esta aparência:

BANCO
  ↓
CONSULTORIA A
  ↓
CONSULTORIA B
  ↓
FORNECEDOR
  ↓
PROFISSIONAL

Mas está faltando uma entidade importante.

Muito importante.

                    ESTADO
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       TRIBUTOS    TRABALHO    PREVIDÊNCIA
          │           │           │
          └───────────┼───────────┘
                      ↓
BANCO → CONSULTORIA → PROFISSIONAL

Agora nossa Matrix ficou um pouco mais completa.

Porque o valor que chega ao profissional também não corresponde necessariamente ao dinheiro que estará disponível para ele consumir, poupar ou investir.

Existem impostos.

Existem contribuições.

Existe previdência.

Existem diferentes regimes de contratação.

Existe CLT.

Existe PJ.

Existe autônomo.

Existe terceirizado.

Existe quarteirizado.

E existe uma pergunta que acompanha o trabalhador brasileiro durante décadas:

quanto daquilo que estou entregando hoje está realmente construindo minha segurança amanhã?

Essa pergunta merece outra xícara de café.


☕ O salário bruto é outra Matrix

Existe uma pequena experiência filosófica que todo trabalhador conhece.

Alguém pergunta:

— Quanto você ganha?

Existe uma resposta.

Depois chega o demonstrativo de pagamento.

E existe outra resposta.

SALÁRIO BRUTO
      ↓
DESCONTOS
      ↓
CONTRIBUIÇÕES
      ↓
IMPOSTOS
      ↓
SALÁRIO LÍQUIDO
      ↓
ALUGUEL
      ↓
ENERGIA
      ↓
ÁGUA
      ↓
ALIMENTAÇÃO
      ↓
TRANSPORTE
      ↓
BOLETOS
      ↓
"PARABÉNS! VOCÊ SOBREVIVEU AO MÊS."

Naturalmente, imposto não é simplesmente dinheiro desaparecendo em um buraco negro.

O Estado financia serviços públicos, infraestrutura, saúde, educação, segurança, previdência e inúmeras estruturas necessárias para a sociedade funcionar.

Da mesma maneira que seria intelectualmente desonesto dizer que toda margem de uma consultoria é lucro, seria igualmente simplista tratar toda tributação como dinheiro confiscado sem contrapartida.

A questão interessante continua sendo outra:

qual é a relação entre aquilo que entregamos, aquilo que contribuímos e a segurança que esperamos receber no futuro?

E aqui entramos numa das salas mais desconfortáveis da Matrix brasileira.


👴 A promessa chamada aposentadoria

Quando alguém começa a trabalhar jovem, aposentadoria parece uma abstração.

Aos vinte anos, sessenta parece pertencer a outra civilização.

Você pensa:

"Um dia."

E continua trabalhando.

Ano após ano.

Projeto após projeto.

Segunda-feira após segunda-feira.

20 anos
   ↓
25
   ↓
30
   ↓
35
   ↓
40
   ↓
45
   ↓
50
   ↓
...

Durante esse percurso existe uma espécie de contrato social implícito:

trabalhe, contribua e, no futuro, haverá proteção.

Não é uma conta de investimento individual simples. Sistemas previdenciários são muito mais complexos, envolvem solidariedade entre gerações, regras contributivas, demografia, financiamento e políticas públicas.

Mas, para o trabalhador olhando de dentro da cabine, a percepção pode ser muito mais simples:

"Estou entregando parte da minha renda e décadas da minha vida em troca de alguma segurança futura."

E então as regras mudam.


🐇 A linha de chegada que se movimenta

Aqui precisamos tomar cuidado com números simplificados.

Não podemos dizer literalmente:

COMEÇOU EM 1980 → TRABALHA 35 ANOS
COMEÇOU EM 1990 → TRABALHA 40 ANOS
COMEÇOU EM 2000 → TRABALHA 50 ANOS
COMEÇOU EM 2010 → TRABALHA 60 ANOS

A legislação brasileira nunca funcionou segundo essa progressão matemática.

Existem regras diferentes, reformas, idades, tempos de contribuição, categorias e sistemas de transição.

Mas como metáfora geracional, existe algo poderosíssimo aí.

Imagine uma esteira.

Você começa a correr.

No horizonte existe uma placa:

APOSENTADORIA
       10 KM

Você corre.

Corre.

Corre.

Quando finalmente se aproxima:

ATUALIZAÇÃO DO SISTEMA...

NOVAS REGRAS APLICADAS.

A placa parece um pouco mais distante.

Continue correndo.

Isso não significa necessariamente que exista alguém maliciosamente movimentando a placa.

Existe uma questão demográfica real por trás disso.

As pessoas vivem mais.

A proporção entre trabalhadores ativos e beneficiários muda.

A natalidade cai.

O sistema precisa continuar financiável.

Existem contas que precisam fechar.

Essa é a pílula azul.

Mas existe também a vermelha.


🔴 Quanto da vida cabe numa planilha atuarial?

Um sistema previdenciário olha para:

EXPECTATIVA DE VIDA
NÚMERO DE CONTRIBUINTES
NÚMERO DE BENEFICIÁRIOS
IDADE
CONTRIBUIÇÕES
RECEITAS
DESPESAS
PROJEÇÕES

Tudo perfeitamente racional.

Mas existe uma variável difícil de colocar na planilha:

MELHORES ANOS DA VIDA

Dos vinte aos trinta.

Dos trinta aos quarenta.

Dos quarenta aos cinquenta.

Dos cinquenta aos sessenta.

Existe uma coisa que nenhum sistema previdenciário consegue devolver:

tempo.

Dinheiro pode ser compensado.

Salário pode aumentar.

Investimento pode render.

Patrimônio pode valorizar.

Tempo não possui ROLLBACK.


💾 TIME-USED PIC 9(02)

Imagine nosso programa COBOL da existência:

01  WS-IDADE                 PIC 9(03).
01  WS-TEMPO-TRABALHADO      PIC 9(03).
01  WS-TEMPO-DISPONIVEL      PIC 9(03).
01  WS-APOSENTADORIA         PIC X(10).

PROCEDURE DIVISION.

    PERFORM TRABALHAR
       UNTIL WS-APOSENTADORIA = 'LIBERADA'.

    PERFORM APROVEITAR-VIDA.

Parece razoável.

Só existe um pequeno problema de arquitetura.

Quanto mais tarde executamos:

PERFORM APROVEITAR-VIDA

menos sabemos sobre as condições em que essa rotina será executada.

Essa talvez seja uma das maiores ilusões modernas:

"Quando eu me aposentar, faço."

Quando me aposentar, viajo.

Quando me aposentar, estudo aquilo.

Quando me aposentar, vou morar naquele lugar.

Quando me aposentar, caminho por aquele país.

Quando me aposentar, escrevo meu livro.

Quando me aposentar, finalmente terei tempo.

Existe apenas uma variável que ninguém conhece:

FUTURO AVAILABLE? Y/N

🔵 Mas Morpheus precisa mostrar a outra pílula

Seria fácil transformar isso em:

"Previdência é uma fraude."

Não.

Seria uma conclusão irresponsável.

Previdência social possui uma função importantíssima.

Sem mecanismos coletivos de proteção, milhões de pessoas chegariam à velhice sem nenhuma fonte de renda.

Nem todo trabalhador consegue investir.

Nem toda carreira permite acumular patrimônio.

Existem doenças, desemprego, crises, acidentes, desigualdade e acontecimentos completamente imprevisíveis.

Proteção social existe justamente porque a vida não executa sempre com:

RETURN-CODE = 00

Às vezes vem:

S0C7

sem aviso.

Portanto, a discussão não deveria ser:

Estado ou indivíduo?

Talvez seja:

quanto da nossa segurança futura deveria depender exclusivamente de uma promessa cuja regra pode mudar ao longo de quarenta anos?

Essa pergunta é muito mais interessante.


🔴 O risco regulatório do trabalhador

Falamos anteriormente sobre risco empresarial.

Depois falamos sobre risco profissional.

Agora aparece outro:

risco regulatório.

Você pode planejar sua carreira considerando determinadas regras existentes aos 25 anos.

Mas possui pouquíssimo controle sobre quais regras existirão quando tiver 55.

Esse risco é particularmente curioso porque o horizonte é gigantesco.

Imagine contratar um serviço cujo prazo de entrega seja:

quarenta anos.

Durante esses quarenta anos:

governos mudarão,

leis mudarão,

moedas poderão mudar,

economias entrarão em crise,

tecnologias desaparecerão,

profissões nascerão,

demografia mudará,

e talvez o próprio conceito de trabalho seja transformado.

Mesmo assim, fazemos planejamento previdenciário atravessando todo esse período.

É quase um projeto mainframe.

Só que o sistema legado é você.


🧑‍💻 E o terceirizado?

Agora voltamos ao nosso profissional de R$ 55/h.

Dependendo da relação contratual, ele pode ter diferentes níveis de proteção.

Pode ser CLT.

Pode ser PJ.

Pode trabalhar por projeto.

Pode passar períodos sem contrato.

Pode precisar financiar sozinho sua formação.

Pode precisar formar sua própria reserva.

Pode ter benefícios diferentes.

Pode contribuir para a previdência de maneiras diferentes.

E talvez exista aqui uma das maiores contradições da chamada flexibilização do trabalho:

quanto mais risco transferimos ao indivíduo, mais necessário se torna que ele compreenda finanças, previdência e seu próprio valor econômico.

O antigo modelo dizia aproximadamente:

TRABALHE
   ↓
RECEBA
   ↓
CONTRIBUA
   ↓
APOSENTE

O novo mundo pode se parecer mais com:

ESTUDE
   ↓
PAGUE O ESTUDO
   ↓
ENCONTRE PROJETO
   ↓
TRABALHE
   ↓
PROJETO TERMINA
   ↓
PROCURE OUTRO
   ↓
ATUALIZE-SE
   ↓
PAGUE SUA PROTEÇÃO
   ↓
FORME RESERVA
   ↓
ACOMPANHE AS REGRAS
   ↓
RECOMECE

Isso é liberdade?

Pode ser.

Isso é precarização?

Também pode ser.

Depende de quem está olhando, das condições oferecidas e principalmente de quanto poder de escolha aquela pessoa realmente possui.

Outra vez:

pílula azul.

Pílula vermelha.


🕶️ Anderson entregou os melhores anos

E finalmente retornamos ao apartamento pequeno.

Talvez seja por isso que Thomas Anderson continue sendo tão reconhecível décadas depois.

Ele não começa como escolhido.

Começa como trabalhador.

Acorda.

Vai trabalhar.

Entrega tempo.

Recebe salário.

Volta para casa.

Tenta construir outra identidade durante as horas que sobraram.

E repete.

A grande provocação de Matrix talvez não seja simplesmente:

"Nossa realidade é falsa?"

Existe outra pergunta muito mais cotidiana:

"Quanto da sua realidade foi escolhido por você?"

Estudar foi escolha?

Trabalhar foi escolha?

Aceitar aquele projeto foi escolha?

Adiar aquela viagem foi escolha?

Trabalhar naquele sábado foi escolha?

Guardar dinheiro foi escolha?

Não guardar porque não sobrava foi escolha?

Esperar pela aposentadoria foi escolha?

Talvez algumas respostas sejam sim.

Outras não.

E muitas provavelmente sejam:

mais ou menos.


⏳ O único ativo não renovável

Dinheiro perdido pode voltar.

Emprego perdido pode ser substituído.

Uma certificação vencida pode ser renovada.

Uma tecnologia esquecida pode ser reaprendida.

Um sistema destruído pode ser restaurado do backup.

Mas existe um recurso sem disaster recovery:

TIME

Não existe:

RESTORE TIME
FROM BACKUP
WHERE YEAR = 1997.

Talvez essa seja a verdadeira pílula vermelha deste artigo.

Não é descobrir que bancos ganham dinheiro.

Sabíamos.

Não é descobrir que consultorias possuem margens.

Sabíamos.

Não é descobrir que o Estado cobra impostos.

Definitivamente sabíamos.

É perceber que, no centro de toda essa arquitetura, existe alguém pagando com uma moeda que nenhum dos outros participantes consegue fabricar:

tempo de vida.

E isso não significa abandonar o trabalho.

Não significa abandonar a CLT.

Não significa abandonar a previdência.

Não significa declarar guerra ao Estado, aos bancos ou às consultorias.

Significa apenas acrescentar uma variável ao nosso planejamento:

IF DINHEIRO > 0
   AND TEMPO = 0
      DISPLAY 'TRANSACTION FAILED'
END-IF.

Porque talvez tenhamos passado gerações ensinando trabalhadores a perguntar:

Quanto vou receber quando me aposentar?

Quando deveríamos também ensinar:

Quanto da minha vida estou disposto a adiar até lá?

Essa pergunta não cabe numa folha de pagamento.

Não aparece no Imposto de Renda.

Não aparece no contrato.

Não aparece no extrato previdenciário.

Mas talvez seja uma das contas mais importantes que faremos.

🔵 A pílula azul diz:

trabalhe agora para viver depois.

🔴 A vermelha pergunta:

e se "depois" não puder entregar aquilo que você adiou?

Nenhuma das duas elimina a necessidade de trabalhar.

Nenhuma elimina os boletos.

Nenhuma resolve a previdência.

Mas uma delas talvez faça você olhar para o relógio de maneira diferente.

E desta vez...

não estou falando do relógio de ponto.

🕶️ Wake up, Neo

Talvez seja isso que mais me fascine em Thomas Anderson.

Durante o dia, alguém dizia quanto ele valia.

Tinha cargo.

Salário.

Horário.

Chefe.

Identificação.

Lugar no organograma.

Na outra vida existia Neo.

Neo começou a descobrir que aquilo que sabia fazer tinha valor fora da estrutura que definia Anderson.

Não precisamos abandonar nossos empregos.

Não precisamos declarar guerra às consultorias.

Não precisamos exigir royalties por cada MOVE A TO B.

Não precisamos enxergar exploração em toda relação comercial.

Mas talvez devêssemos fazer algo muito mais simples.

Entender a Matrix.

Entender quem paga.

Quem recebe.

Quem arrisca.

Quem investe.

Quem aprende.

Quem intermedeia.

Quem mantém.

Quem captura valor.

E quem pode ser descartado quando o projeto termina.

Porque liberdade profissional não começa quando você pede demissão.

Começa quando você entende sua posição dentro do sistema.


☕ Cambio final, Torre de Controle

Da próxima vez que alguém disser:

— Sua hora vale R$ 55.

Talvez a resposta não precise ser:

— Isso é injusto!

Talvez seja simplesmente:

— Interessante. Quanto ela vale para o cliente?

Essa pergunta não acusa ninguém.

Não exige nada.

Não quebra contrato.

Não transforma empresa em inimiga.

Apenas acende uma luz.

E sistemas complexos ficam muito mais interessantes quando conseguimos enxergar suas conexões.

Talvez você descubra que os R$ 55 são perfeitamente razoáveis.

Talvez descubra que existem custos que nunca havia considerado.

Talvez perceba que a consultoria realmente adiciona enorme valor.

Ou talvez descubra cinco camadas entre seu teclado e o cliente, cada uma retirando uma pequena fatia de algo que começou em R$ 200.

Nesse momento você terá uma escolha.

Não entre capitalismo e socialismo.

Não entre empregado e empresário.

Não entre banco e programador.

Uma escolha muito mais simples.

🔵 Continuar olhando apenas para o número que aparece no contrato.

Ou...

🔴 Começar a entender toda a arquitetura econômica que existe atrás dele.

Morpheus provavelmente sorriria.

Porque a pílula vermelha nunca prometeu que aquilo que encontraríamos seria necessariamente injusto.

Prometeu apenas uma coisa:

ver o sistema como ele realmente funciona.

E para um programador COBOL...

convenhamos...

não existe convite mais irresistível do que esse.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. WAKE-UP-NEO.

       PROCEDURE DIVISION.

           PERFORM ENTENDER-O-SISTEMA
              UNTIL FIM-DA-CARREIRA.

           DISPLAY 'KNOWLEDGE HAS VALUE'.
           DISPLAY 'KNOW YOURS.'.

           STOP RUN.

☕🕶️💊

Cambio final, Torre de Controle.

Wake up, Neo.

Os boletos já acordaram.

quinta-feira, 6 de agosto de 2026

O Caso TSB Bank : Como uma migração de mainframe destruiu a reputação de um banco

Bellacosa Mainframe edição especial O Caso TSB Bank

Um café no Bellacosa Mainframe Edição Especial

O Caso TSB Bank

Como uma migração de mainframe destruiu a reputação de um banco

Resumo

Em abril de 2018, o banco britânico TSB Bank realizou uma migração do seu core bancário.

O objetivo era:

  • abandonar a plataforma herdada da Lloyds

  • desligar o ambiente mainframe legado

  • migrar milhões de contas para a plataforma espanhola Proteo4UK, desenvolvida pelo grupo Sabadell.

O resultado foi um desastre.

Durante semanas:

  • clientes ficaram sem acessar contas

  • pagamentos falharam

  • salários não foram creditados

  • pessoas visualizaram contas de terceiros

  • fraudes aumentaram

  • o banco praticamente parou.

Até hoje o episódio é usado em universidades e cursos de gerenciamento de projetos.


Antes da crise

2008

Crise financeira mundial.

O governo britânico salva o Lloyds Banking Group.

Como condição da União Europeia:

Lloyds deveria vender parte de seus ativos.


2013

Nasce o novo TSB.

Entretanto...

O banco não possuía infraestrutura própria.

Continuou utilizando o enorme ambiente tecnológico da Lloyds.

Era praticamente um "inquilino" da infraestrutura do antigo dono.


O problema

Todos os anos o TSB pagava milhões para utilizar:

  • mainframe

  • processamento

  • storage

  • sistemas

  • infraestrutura

Era caro.

Muito caro.


2015

O banco espanhol

Banco Sabadell

compra o TSB por cerca de £1,7 bilhão.

O plano era simples.

"Vamos desligar toda a tecnologia da Lloyds e colocar tudo na plataforma Sabadell."

Nascia o projeto Proteo4UK. (Tsb)


O erro número 1

Uma consultoria estratégica contratada antes da aquisição recomendou justamente o contrário:

permanecer o máximo possível na plataforma Lloyds e, depois, utilizar uma cópia independente ("clone") da plataforma existente, reduzindo riscos de migração. (Tsb)

Mas, após a compra pelo Sabadell, prevaleceu o objetivo de capturar rapidamente as sinergias financeiras da aquisição, acelerando a migração para a plataforma própria. (Tsb)

  • Para saber mais

https://eljefemidnightlunch.blogspot.com/2020/04/o-caso-tsb-bank-como-uma-migracao-de.html

  • House MD investiga quando os dados mentem

https://eljefemidnightlunch.blogspot.com/2021/04/o-paciente-tsb-house-cobol-e-migracao.html


O cronograma

2015

Projeto iniciado


2016

Construção da nova plataforma


2017

Testes

Dress rehearsals

Ensaios

Migrações parciais

Segundo o banco:

  • nove ensaios completos

  • milhares de testes

  • piloto com cerca de 1.600 funcionários

Tudo aparentemente aprovado. (Tsb)


Abril de 2018

Chega o grande fim de semana.

Toda migração foi planejada para ocorrer entre

20 e 22 de abril.


Sexta-feira

20/04/2018

Os sistemas entram em manutenção.

Clientes avisados.


Domingo

22/04

Às 18h

Os serviços deveriam voltar.

Não voltaram normalmente.

Começaram os primeiros relatos:

  • erro de login

  • saldo incorreto

  • aplicativos travando

E o mais assustador...

Algumas pessoas conseguiam visualizar dados bancários de outros clientes. (The Guardian)


Segunda-feira

23 abril

O banco dizia:

"Há apenas problemas de acesso."

Nas redes sociais a situação parecia muito pior.

Milhares de reclamações.

Curiosamente, a própria Sabadell chegou a publicar uma nota comemorando o "sucesso" da migração antes de retirar o comunicado. (The Guardian)


Terça-feira

24 abril

O caos.

Até 1,9 milhão de clientes de internet banking e aplicativo foram afetados. (The Guardian)


O que aconteceu tecnicamente?

Durante muito tempo imaginou-se que:

"os dados foram perdidos."

Na realidade...

Não.

Os dados principais foram migrados corretamente.

Todas as contas chegaram.

O problema estava na infraestrutura.

Segundo as análises posteriores:

  • inconsistências entre os dois data centers

  • diferenças de configuração entre ambientes que deveriam ser idênticos

  • problemas de capacidade

  • defeitos de software

  • gargalos inesperados

  • canais digitais instáveis

  • explosão de acessos dos clientes tentando verificar suas contas, sobrecarregando ainda mais call centers e agências. (Tsb)

Ou seja...

Os registros bancários foram preservados.

A plataforma ao redor deles não conseguiu operar de forma estável.


IBM entra em cena

Dias depois, o CEO Paul Pester anunciou que especialistas da IBM haviam sido chamados para ajudar na estabilização da plataforma. O objetivo era recuperar o ambiente, e não conduzir a migração original. (The Guardian)

É importante destacar:

A IBM não foi responsável pelo projeto de migração.

Ela entrou posteriormente para auxiliar na recuperação.


As consequências

Durante semanas ocorreram:

  • salários atrasados

  • hipotecas afetadas

  • cartões recusados

  • pagamentos perdidos

  • transferências bloqueadas

  • empresas incapazes de pagar funcionários

Houve também aumento nas tentativas de fraude contra clientes durante o período de instabilidade. (Grupo Banc Sabadell)


O Parlamento britânico

O CEO Paul Pester foi convocado diversas vezes para prestar esclarecimentos ao Comitê do Tesouro da Câmara dos Comuns.

As audiências foram bastante críticas e questionaram planejamento, governança, comunicação e avaliação de riscos. (The Guardian)


O relatório independente

Em 2019, o conselho do TSB publicou uma revisão independente conduzida pelo escritório de advocacia Slaughter and May.

Entre as conclusões estavam:

  • cronograma excessivamente agressivo

  • supervisão insuficiente de fornecedores

  • falhas na governança

  • testes que não reproduziram adequadamente o ambiente real

  • excesso de confiança nos indicadores de prontidão antes do "go live". (Tsb)


Quanto custou?

As estimativas variam conforme o critério contábil, mas o impacto financeiro foi enorme.

Os custos incluíram:

  • compensações a clientes

  • recuperação operacional

  • perda de clientes

  • reforço da infraestrutura

  • consultorias

  • suporte emergencial

  • investigações regulatórias

O Grupo Sabadell informou centenas de milhões de libras em impactos relacionados ao incidente ao longo do tempo, considerando custos diretos e indiretos. (Grupo Banc Sabadell)


Houve multa?

Sim.

Em dezembro de 2022, os reguladores britânicos (Financial Conduct Authority – FCA e Prudential Regulation Authority – PRA) anunciaram um acordo com o TSB.

As multas somadas chegaram a aproximadamente £48,65 milhões, relacionadas às deficiências na gestão dos riscos operacionais e da migração tecnológica. (Tsb)


O CEO caiu?

Sim.

Paul Pester renunciou em setembro de 2018.

A pressão política e pública tornou sua permanência praticamente inviável. (The Guardian)


O TSB quebrou?

Curiosamente...

Não.

O banco continuou existindo.

Hoje opera normalmente utilizando a nova plataforma.

Após anos de estabilização, o próprio TSB afirma que os incidentes de TI voltaram a níveis comparáveis aos de outros bancos do mercado e que internalizou parte relevante da gestão de TI. (Tsb)


As principais lições para quem trabalha com mainframe

Este caso costuma ser resumido em algumas lições clássicas:

  1. O problema não era o mainframe. A motivação principal era reduzir dependências e custos do ambiente legado, não substituir uma plataforma que estivesse falhando.

  2. Migrações de core bancário são projetos de transformação organizacional, não apenas de tecnologia.

  3. Testes de laboratório não garantem comportamento em produção. Carga real, usuários simultâneos e cenários extremos podem revelar problemas invisíveis.

  4. Cronogramas definidos por metas de negócio podem aumentar o risco técnico. O relatório independente critica explicitamente o calendário considerado otimista demais. (Tsb)

  5. Planos de rollback e contingência precisam ser extremamente robustos. Em sistemas financeiros, recuperar a operação rapidamente é tão importante quanto migrar.


Links para as principais fontes históricas

Na minha opinião técnica, o caso TSB é um dos melhores estudos para profissionais de mainframe porque desmonta um mito recorrente: a falha não ocorreu porque o banco usava mainframe, mas porque uma transformação extremamente complexa foi conduzida sob um cronograma agressivo e encontrou problemas de arquitetura, implantação, governança e operação. A própria migração preservou os dados dos clientes; o colapso aconteceu na infraestrutura e nos serviços que deveriam disponibilizar esses dados de forma confiável. É por isso que o episódio continua sendo citado em discussões sobre modernização de sistemas críticos, muito mais como uma lição de engenharia e gestão do que como uma crítica à tecnologia de origem.

quarta-feira, 5 de agosto de 2026

NÃO ENTRE EM PÂNICO: Doctor Who, Doomwatch, COBOL e o Guia do Programador Mainframe para Sobreviver ao Futuro

Bellacosa Mainframe e o nao entre em panico como os britanicos e suas series viam o futuro

☕ Um Café no Bellacosa Mainframe

NÃO ENTRE EM PÂNICO: Doctor Who, Doomwatch, COBOL e o Guia do Programador Mainframe para Sobreviver ao Futuro

Ou: como a ficção científica britânica dos anos 1970 descobriu AI Governance, resiliência, pandemias, vigilância e incidentes cinquenta anos antes de inventarmos os nomes bonitos

Por Vagner Bellacosa


Existe uma regra fundamental para sobreviver no universo.

Douglas Adams resumiria isso em letras grandes e amigáveis:

NÃO ENTRE EM PÂNICO.

No mundo mainframe, entretanto, convém acrescentar algumas observações:

NÃO ENTRE EM PÂNICO.

Não cancele o job sem saber o que ele está fazendo.

Não dê PURGE apenas porque alguém importante está gritando ao telefone.

Não altere produção diretamente porque “é só uma coisinha”.

E, pelo amor de todos os compiladores COBOL existentes na galáxia, descubra primeiro por que o sistema funciona antes de decidir modernizá-lo.

Pegue sua toalha.

Pegue seu café.

Abra o SDSF.

Nossa nave está prestes a sair da órbita.

Destino:

Reino Unido, década de 1970.

Porque, escondidas entre cenários de papelão, monstros de borracha, computadores cheios de luzes piscantes e naves construídas em miniatura, algumas séries britânicas estavam fazendo perguntas que continuam assustadoramente atuais.

A matéria que serviu de ponto de partida para esta viagem considera os anos 1970 uma espécie de “era de ouro” da ficção científica televisiva britânica. A principal razão não era simplesmente a quantidade de alienígenas apresentados na televisão, mas a profundidade dos temas: problemas políticos, sociais, ambientais e tecnológicos começaram a ocupar o centro das histórias.

Eis a primeira coisa que um jovem programador COBOL precisa entender:

ficção científica de verdade raramente fala sobre o futuro.

Ela fala sobre o presente usando o futuro como máscara.


1. O planeta Reino Unido estava com problemas

Antes de encontrarmos Daleks, Cybermen, vírus mortais e governos totalitários, precisamos verificar o log do sistema operacional chamado Reino Unido.

Nos anos 1970, a situação estava longe de ser tranquila.

O país enfrentava problemas econômicos, greves, restrições de investimento e crise energética. Entre 1973 e 1974, a situação chegou ao ponto de haver restrições na operação das emissoras BBC e ITV durante a noite.

Agora imagine um roteirista sentado diante da televisão.

Ele vê:

greves;

desemprego;

problemas energéticos;

desconfiança política;

ameaças da Guerra Fria;

poluição;

crescimento tecnológico;

medo nuclear.

E pergunta:

“E se isso piorar?”

Pronto.

Temos ficção científica.

Uma das grandes virtudes dos britânicos foi transformar problemas concretos em experimentos narrativos.

As diferenças entre classes sociais, o totalitarismo e as preocupações ambientais tornaram-se temas recorrentes dessas produções.

O roteiro deixou de ser apenas:

ALIENÍGENA CHEGA
      ↓
HERÓI DESCOBRE
      ↓
HERÓI LUTA
      ↓
ALIENÍGENA EXPLODE
      ↓
FIM

e começou a ser algo parecido com:

SOCIEDADE CRIA TECNOLOGIA
          ↓
TECNOLOGIA CRIA BENEFÍCIOS
          ↓
ALGUÉM IGNORA OS RISCOS
          ↓
INCENTIVOS POLÍTICOS INTERFEREM
          ↓
SISTEMA SAI DO CONTROLE
          ↓
PESSOAS DESCOBREM QUE DEPENDIAM DELE
          ↓
PROBLEMA

Se você trabalha com tecnologia há alguns anos, isso provavelmente lhe parece menos ficção científica do que deveria.


2. Antes de Doctor Who havia Quatermass

Voltemos um pouco no tempo.

Em 1953 a BBC exibiu The Quatermass Experiment.

A história mostrava astronautas contaminados por uma forma de vida alienígena após uma missão espacial. O material que analisamos identifica a produção como uma das experiências da BBC que misturavam drama, terror, fantasia e ciência antes do nascimento de Doctor Who.

Observe a arquitetura da história.

O perigo não aparece simplesmente porque “alienígenas são maus”.

O problema surge porque:

HOMEM
 ↓
EXPLORA
 ↓
DESCONHECIDO
 ↓
TRAZ ALGO DE VOLTA
 ↓
NÃO ENTENDE O QUE TROUXE

Isso é uma estrutura importantíssima da ficção científica moderna.

E também da segurança da informação.

Se substituirmos “organismo extraterrestre” por:

biblioteca desconhecida
pacote npm
imagem Docker
modelo de IA
arquivo recebido
dependência open source

a história continua funcionando.

O monstro muda.

O problema permanece.


3. 1955: surge concorrência no datacenter televisivo

Durante muitos anos, a BBC dominou praticamente sozinha a televisão britânica.

Então surgiu a ITV.

De repente, existia competição.

A ITV trouxe programação mais popular e produções estrangeiras. A BBC precisou reagir aumentando sua capacidade de oferecer entretenimento sem abandonar sua tradição educacional e cultural.

Aqui encontramos uma lição de arquitetura empresarial.

Um sistema raramente evolui sozinho.

Ele evolui porque o ambiente muda.

Concorrência muda produto.

Regulação muda produto.

Usuários mudam produto.

Tecnologia muda produto.

Custo muda produto.

Até COBOL muda.

O COBOL que você encontra hoje em um IBM Z moderno não é simplesmente uma peça arqueológica que alguém esqueceu ligada desde 1968.

É resultado de décadas de evolução.

Da mesma forma, a BBC precisava preservar aquilo que funcionava e adaptar aquilo que já não respondia ao ambiente.

Guarde essa ideia.

Ela voltará quando falarmos de modernização mainframe.


4. 1963: chega Doctor Who

Então entra Sydney Newman.

A missão era quase impossível:

manter o conteúdo inteligente da BBC e, ao mesmo tempo, torná-lo popular.

A resposta foi uma série chamada:

Doctor Who.

A concepção original tinha forte propósito educacional. História, ciência, tecnologia, espaço e viagens temporais seriam apresentados aos jovens através de aventuras.

Parece simples hoje.

Mas pense na elegância da arquitetura.

Você quer ensinar história?

Leve os personagens para o passado.

Quer falar sobre tecnologia?

Viaje para o futuro.

Quer discutir ética?

Crie uma civilização alienígena.

Quer discutir racismo?

Crie duas espécies que se odeiam.

Quer falar sobre autoritarismo?

Invente um governo galáctico.

Quer discutir guerra?

Crie Daleks.

Doctor Who transformou ficção científica em uma espécie de laboratório moral portátil.

A TARDIS podia levar o espectador para qualquer problema.


5. O sistema quase foi cancelado

A primeira aventura de Doctor Who não provocou o sucesso esperado.

Então apareceram os Daleks.

A audiência aumentou dramaticamente, chegando a aproximadamente nove milhões de espectadores segundo o material analisado.

Ironicamente:

os Daleks salvaram Doctor Who.

Isso também contém uma pequena aula de engenharia de produtos.

Você pode criar uma solução tecnicamente brilhante.

Mas se ninguém quiser utilizá-la, temos um problema.

O criador pensa:

“Mas minha arquitetura está perfeita!”

O usuário responde:

“Tá. Mas onde está o botão que resolve meu problema?”

A BBC descobriu algo parecido.

A ideia educacional era boa.

Mas os Daleks forneceram:

ameaça;

identidade;

conflito;

memória;

símbolo.

Em linguagem de produto:

engajamento.


6. 1970: Doomwatch entra na sala

Agora chegamos a uma das partes mais interessantes desta viagem.

Em 1970 estreia Doomwatch.

A série foi criada por Kit Pedler e Gerry Davis. Pedler era cientista e atuava como consultor das situações apresentadas. Segundo o artigo analisado, a produção teve três temporadas e 38 episódios.

Mas observe a premissa.

Existe um departamento chamado:

Department for the Observation and Measurement of Scientific Work.

Missão:

acompanhar pesquisas científicas e verificar se elas poderiam representar ameaça às pessoas ou ao meio ambiente.

Caro viajante galáctico...

Estamos em 1970.

Agora troque:

Scientific Work

por:

Artificial Intelligence.

Temos imediatamente:

DEPARTMENT FOR THE OBSERVATION
AND MEASUREMENT OF
ARTIFICIAL INTELLIGENCE

Parabéns.

Você acabou de reinventar:

AI Governance.


7. A pergunta de Doomwatch

A pergunta fundamental de Doomwatch é maravilhosa:

se podemos fazer alguma coisa, devemos fazê-la?

Na tecnologia normalmente somos treinados para responder:

“Funciona?”

Mas sistemas críticos exigem outras perguntas:

“Devemos fazer?”

“Quem será afetado?”

“Qual é o risco?”

“Como detectaremos erro?”

“Quem pode interromper?”

“Existe rollback?”

“Quem autorizou?”

“Existe evidência?”

“Existe auditoria?”

“Qual é o blast radius?”

Esse é exatamente o ponto em que engenharia deixa de ser simplesmente programação.


8. O programador COBOL encontra Doomwatch

Imagine que alguém lhe entregue uma mudança:

IF CLIENTE-VIP
    MOVE ZERO TO TAXA
END-IF.

Funciona?

Provavelmente.

Compila?

Talvez.

Resolve a solicitação?

Aparentemente.

Mas o programador experiente pergunta:

Quem definiu CLIENTE-VIP?

Essa taxa pode legalmente ser zerada?

Quem autorizou?

Existe trilha de auditoria?

Isso afeta cálculo tributário?

Existem outros programas utilizando esse campo?

É aqui que surge uma regra fantástica:

código correto pode produzir um sistema errado.

Doomwatch já estava discutindo, metaforicamente, exatamente esse problema.


9. 1975: Survivors e o planeta sem produção

Então Terry Nation criou algo muito mais sombrio.

Survivors.

Uma praga provocada por vírus cultivado em laboratório destrói aproximadamente 99% da população mundial. Os sobreviventes precisam reconstruir comunidades praticamente sem infraestrutura moderna.

A produção existiu entre 1975 e 1977 e acumulou 38 episódios.

Hoje, depois de uma pandemia global real, assistir a essa premissa produz outra sensação.

Mas existe uma camada ainda mais interessante.

Survivors não é apenas sobre vírus.

É sobre:

dependência sistêmica.


10. Civilization.exe parou de responder

Imagine que amanhã desapareçam:

energia;

telecomunicações;

sistema bancário;

logística;

produção industrial;

governo;

hospitais;

internet;

combustíveis;

cadeias de suprimento.

Em poucas horas descobriremos algo curioso.

Nossa civilização é uma gigantesca aplicação distribuída.

Ela possui milhares de serviços.

Alguns críticos.

Alguns aparentemente insignificantes.

E todos possuem dependências.

Por exemplo:

SUPERMERCADO
     ↓
LOGÍSTICA
     ↓
COMBUSTÍVEL
     ↓
PAGAMENTO
     ↓
BANCO
     ↓
DATACENTER
     ↓
ENERGIA
     ↓
TELECOM

Agora faça o caminho inverso.

Telecom depende de energia.

Energia depende de sistemas informatizados.

Sistemas informatizados dependem de redes.

Redes dependem de telecom.

Bem-vindo ao maravilhoso universo das:

dependências circulares.


11. O batch das 04:37

Um jovem desenvolvedor pode olhar para determinado processamento mainframe e pensar:

“É apenas um job.”

Não.

Pode ser:

liquidação;

folha de pagamento;

posição contábil;

cartões;

compensação;

arrecadação;

seguros;

reservas;

crédito;

tributação.

O job pode terminar às 04:37.

Ninguém vê.

Ninguém aplaude.

Nenhuma animação aparece.

Não existem luzes azuis cinematográficas.

Mas talvez milhões de pessoas acordem de manhã esperando que o resultado daquele processamento exista.

Essa é uma das grandes lições de Survivors.

Infraestrutura só parece invisível enquanto funciona.


12. Resiliência antes de chamarmos de resiliência

Hoje utilizamos termos sofisticados:

Business Continuity.

Disaster Recovery.

Cyber Resilience.

High Availability.

Fault Tolerance.

Redundancy.

RTO.

RPO.

Survivors coloca tudo isso em uma única pergunta:

“O que acontece quando quase tudo deixa de funcionar?”

O exercício parece extremo.

Mas arquitetos fazem versões menores dessa pergunta todos os dias.

Se o Db2 cair?

Se o CICS parar?

Se perdermos um LPAR?

Se perdermos o datacenter?

Se a rede cair?

Se o fornecedor desaparecer?

Se o backup estiver corrompido?

Se o operador errar?

Se o ransomware atingir infraestrutura crítica?

Ficção científica e engenharia compartilham uma ferramenta intelectual maravilhosa:

cenários hipotéticos.


13. 1978: Blake's 7

Chegamos então a Blake's 7.

Também criada por Terry Nation.

A série apresenta um futuro onde uma organização chamada Terran Federation governa diversos mundos através de mecanismos políticos, religiosos, tecnológicos e até genéticos.

Agora mudamos de ameaça.

Em Survivors:

o sistema desapareceu.

Em Blake's 7:

o sistema ficou poderoso demais.

Excelente contraponto.

Um extremo:

SEM CONTROLE

Outro:

CONTROLE TOTAL

A humanidade vive entre os dois.


14. A tecnologia também pode controlar

Na Federação, tecnologia não é apenas ferramenta.

Ela é instrumento de poder.

Essa discussão cresceu enormemente no século XXI.

Quem possui os dados?

Quem controla algoritmos?

Quem define recomendações?

Quem observa usuários?

Quem decide quais informações aparecem?

Quem pode desligar uma conta?

Quem controla sistemas de identidade?

Quem controla a infraestrutura?

Não precisamos imaginar uma Federação Galáctica.

Podemos estudar simplesmente a concentração de infraestrutura digital.


15. Blake não é Luke Skywalker

Outro aspecto interessante é que Blake's 7 não transforma automaticamente a resistência em grupo moralmente perfeito.

Os próprios personagens questionam Blake.

Nem todos compartilham sua ideologia.

A série chega a apresentar acusações de fanatismo contra ele.

Isso é muito importante.

Porque sistemas complexos raramente apresentam:

MOCINHO = CERTO
VILÃO   = ERRADO

Normalmente encontramos:

pressões;

interesses;

incentivos;

erros;

interpretações;

riscos;

informação incompleta.

Quem trabalha em incidentes conhece isso.

Depois que tudo termina, é fácil dizer:

“Era óbvio.”

Antes do incidente?

Nem sempre.


16. Zen, o computador

A nave Liberator possui um computador chamado Zen.

Por décadas a ficção científica imaginou computadores que:

conversam;

aconselham;

controlam;

decidem;

questionam;

enganam;

ajudam.

Durante muito tempo isso parecia apenas recurso narrativo.

Agora chegamos à era dos modelos generativos e agentes.

A fronteira começou a mudar.

Antes:

HOMEM
 ↓
COMANDO
 ↓
COMPUTADOR
 ↓
RESULTADO

Hoje podemos ter:

HOMEM
 ↓
OBJETIVO
 ↓
AGENTE
 ↓
PLANO
 ↓
FERRAMENTA
 ↓
AÇÃO
 ↓
AVALIAÇÃO
 ↓
NOVA AÇÃO

A diferença é gigantesca.

Quanto maior a autonomia, maior a importância de controle, observabilidade e validação.

Doomwatch volta à sala.


17. UFO: a burocracia encontra os alienígenas

Outra produção importante foi UFO, de Gerry e Sylvia Anderson, também mencionada entre as séries relevantes daquele período.

Existe algo particularmente divertido em UFO.

A defesa da Terra não depende simplesmente de um herói com uma arma.

Existe uma organização.

Existem procedimentos.

Bases.

Monitoramento.

Satélites.

Computadores.

Comando.

Comunicação.

Ou seja:

até para combater alienígenas os britânicos imaginaram uma estrutura operacional.

Quase conseguimos ouvir alguém dizendo:

“Antes de interceptar a nave alienígena, abra o ticket.”

Isso talvez seja a coisa mais britânica possível.


18. Espaço: 1999 e o problema chamado consequência

Espaço: 1999 apresenta uma ideia completamente absurda do ponto de vista da física:

uma explosão gigantesca lança a Lua para fora da órbita terrestre.

Tudo bem.

Não entre em pânico.

Ficção não precisa necessariamente funcionar como artigo científico.

O interessante é a causa.

Resíduos nucleares.

Outra vez encontramos:

tecnologia + irresponsabilidade + consequência.

Os anos 1970 estavam profundamente preocupados com energia, poluição e tecnologia nuclear.

A Lua simplesmente serviu como cenário.


19. O detalhe mais importante das Eagles

As naves Eagle tornaram-se talvez um dos designs mais memoráveis da série.

Mas existe uma curiosidade de engenharia escondida nelas.

Elas parecem máquinas.

Não parecem “magia espacial”.

É possível observar:

módulos;

estrutura;

propulsores;

cockpit;

componentes.

Isso produz plausibilidade visual.

A mesma regra vale para software.

Quando mostramos arquitetura como caixas mágicas:

APP → CLOUD → IA → RESULTADO

não explicamos nada.

Um bom arquiteto precisa desmontar a Eagle.

APLICAÇÃO
    ↓
API
    ↓
AUTENTICAÇÃO
    ↓
SERVIÇO
    ↓
BANCO
    ↓
MENSAGERIA
    ↓
MAINFRAME

Agora podemos discutir risco.


20. O impacto no Brasil

A influência dessas produções no Brasil aconteceu de maneira diferente da experiência britânica.

Nem todas as séries tiveram aqui a mesma visibilidade.

Isso significa que memória cultural não depende apenas da qualidade de uma obra.

Depende também de:

distribuição;

emissora;

horário;

dublagem;

reprises;

licenciamento;

alcance.

No Reino Unido, Doctor Who tornou-se parte profunda da cultura popular.

No Brasil, para muitas gerações, outras produções britânicas como UFO, produções de Gerry Anderson e Espaço: 1999 foram referências muito mais imediatamente reconhecíveis.

Essa diferença ensina algo curioso.

Tecnologia também possui distribuição cultural.

Uma invenção pode existir.

Mas se não chega às pessoas, seu impacto é limitado.

Software é igual.


21. O código que ninguém conhece não existe

Imagine criar uma biblioteca fantástica.

Documentação inexistente.

Ninguém sabe utilizá-la.

Ela praticamente não existe.

Agora imagine um programa COBOL de 1989.

Executa todos os dias.

Possui milhares de regras.

Resolve dezenas de exceções.

Pouquíssimas pessoas entendem completamente aquilo.

O código existe.

O conhecimento talvez esteja desaparecendo.

É o problema inverso.

Em um caso:

produto sem distribuição.

No outro:

sistema sem conhecimento distribuído.

Ambos são risco.


22. O que a ficção britânica fez de diferente

Existe uma generalização interessante.

Muita ficção científica americana tradicional perguntou:

“O que encontraremos no futuro?”

A tradição britânica frequentemente perguntou:

“O que o futuro fará conosco?”

Não é uma regra absoluta.

Mas ajuda a compreender essas produções.

Doctor Who pergunta:

como usamos conhecimento?

Doomwatch pergunta:

quem controla ciência?

Survivors pergunta:

o que acontece quando infraestrutura desaparece?

Blake's 7 pergunta:

o que acontece quando controle tecnológico se torna excessivo?

Space: 1999 pergunta:

quais consequências deixamos para o futuro?

Essas perguntas continuam abertas.


23. De 1970 para 2026

Podemos montar uma pequena tradução temporal.

DOOMWATCH
1970: risco científico
2026: AI Governance
SURVIVORS
1975: pandemia e colapso
2026: resiliência sistêmica
BLAKE'S 7
1978: Estado tecnológico
2026: vigilância algorítmica
UFO
1970: infraestrutura de defesa
2026: sistemas distribuídos
SPACE: 1999
1975: lixo nuclear
2026: sustentabilidade tecnológica
DOCTOR WHO
1963+
ciência + ética + história
2026:
inovação responsável

Isso não significa que os roteiristas “previram” exatamente nosso mundo.

Significa algo mais interessante.

Eles identificaram padrões.


24. E padrões sobrevivem

Tecnologias mudam.

Padrões humanos nem tanto.

Temos:

pressa;

ambição;

medo;

competição;

custo;

ego;

autoridade;

conformismo;

pressão por prazo;

excesso de confiança.

Agora misture isso com tecnologia.

Resultado:

incidentes.

É exatamente aqui que nossas discussões sobre Plan Continuation Bias entram na TARDIS.

Um plano começa fazendo sentido.

O ambiente muda.

Surgem sinais de problema.

Mas pessoas continuam seguindo o plano porque já investiram nele.

“Já estamos quase terminando.”

“Não vamos voltar agora.”

“Diretoria já anunciou.”

“O cutover é hoje.”

“Todo mundo está mobilizado.”

Enquanto isso:

alerta.

alerta.

alerta.

alerta.

E ninguém reage.

Bem-vindo à Alarm Fatigue.


25. O episódio perdido de Doomwatch

Imagine.

Doomwatch — episódio 39.

Título:

The Legacy System.

Um grande banco decide substituir um sistema COBOL criado décadas antes.

Uma consultoria garante:

“Dezoito meses.”

Um jovem executivo pergunta:

“Quantas linhas?”

Alguém responde:

“Oito milhões.”

Executivo:

“Então é fácil. Colocamos cinquenta programadores.”

No fundo da sala existe um senhor com cinquenta anos de mainframe.

Ele levanta a mão.

Silêncio.

Pergunta:

“Vocês sabem o que ele faz?”

Executivo:

“Claro. Processa contas.”

O veterano:

“Não. Isso é o que vocês acham que ele faz.”

Música dramática.

Corta para propaganda.


26. A arqueologia do legado

Aqui está outra lição fundamental para quem começa em COBOL.

Sistema legado não significa necessariamente:

sistema ruim.

Significa principalmente:

sistema herdado.

Ele acumulou decisões.

Regras.

Correções.

Mudanças legais.

Tratamentos especiais.

Exceções.

Integrações.

Um programa pode conter algo assim:

IF DATA-MOVIMENTO < WS-DATA-1997
   PERFORM CALCULO-ANTIGO
ELSE
   PERFORM CALCULO-NOVO
END-IF.

O jovem pergunta:

“Por que 1997?”

Resposta:

“Ninguém sabe.”

Cuidado.

Isso não significa automaticamente que podemos apagar.

Talvez exista legislação.

Conversão histórica.

Contrato antigo.

Migração.

Compatibilidade.

A primeira ferramenta do mantenedor não é DELETE.

É:

curiosidade.


27. Guia galáctico para mexer em COBOL antigo

Antes de modificar código crítico:

Passo 1 — Descubra quem chama

JCL?

CICS?

IMS?

Outro programa?

Scheduler?

MQ?

API?

Passo 2 — Descubra o que entra

Arquivo?

VSAM?

Db2?

COMMAREA?

Fila?

Passo 3 — Descubra o que sai

Outro arquivo?

Tabela?

Relatório?

Transação?

Passo 4 — Procure dependências

COPYBOOKS.

CALLs.

PROCs.

SORTs.

Utilitários.

Passo 5 — Entenda a regra de negócio

Não pergunte apenas:

“O que esse IF faz?”

Pergunte:

“Por que o negócio precisa desse IF?”

Passo 6 — Teste o cenário feliz

Depois teste justamente o contrário.

Passo 7 — Crie rollback

Porque:

MOVE PROD TO TEST

é ficção científica.

MOVE TEST TO PROD

sem controle é terror.


28. O verdadeiro vilão quase nunca é o computador

Essa talvez seja a grande síntese.

Nas boas histórias de ficção científica, a máquina raramente é o problema inteiro.

Normalmente existe:

TECNOLOGIA
     +
DECISÃO HUMANA
     +
CONTEXTO
     +
INCENTIVO
     +
FALHA DE CONTROLE

= desastre.

Isso vale para:

IA;

mainframe;

aviação;

energia;

medicina;

bancos;

redes sociais;

automação.


29. Curiosidade: Daleks e Cybermen são diferentes

Para um iniciante em Doctor Who, existe uma diferença filosófica divertida.

Daleks representam uma espécie de pureza ideológica extrema.

Cybermen representam transformação tecnológica que elimina progressivamente características humanas.

Ou seja:

um teme o “outro”.

O outro elimina o “humano”.

Em tecnologia moderna isso permite uma metáfora interessante.

Um sistema pode falhar porque rejeita diversidade.

Ou pode falhar porque automatiza tudo sem preservar julgamento humano.

Qualquer semelhança com debates contemporâneos sobre IA é bastante conveniente.


30. Easter egg COBOL galáctico

Se Arthur Dent fosse programador COBOL, provavelmente seu código começaria assim:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DONT-PANIC.

       PROCEDURE DIVISION.

       0000-MAIN.

           PERFORM UNTIL UNIVERSE-END
               DISPLAY "DON'T PANIC"
               PERFORM CHECK-BATCH
               PERFORM DRINK-COFFEE
           END-PERFORM.

           STOP RUN.

O problema está em:

UNIVERSE-END

porque ninguém documentou o formato da variável.

Há rumores de que seja PIC 9(8).

Outros afirmam que é PIC X(42).

Naturalmente, 42.


31. Segunda curiosidade: a resposta não serve sem a pergunta

Em O Guia do Mochileiro das Galáxias, 42 é apresentado como resposta à Grande Questão da Vida, do Universo e de Tudo.

Mas existe um detalhe genial:

ninguém sabe exatamente qual era a pergunta.

Isso é uma metáfora perfeita para tecnologia.

Quantas vezes alguém aparece com uma solução?

“Cloud!”

“Blockchain!”

“Microserviços!”

“IA!”

“Kubernetes!”

“Agentes!”

Você pergunta:

“Qual problema estamos resolvendo?”

Silêncio.

Temos a resposta.

Esquecemos a pergunta.

Arquitetura boa começa pelo problema.


32. O mainframe é a TARDIS da computação empresarial

Exteriormente, alguém olha e diz:

“Isso ainda existe?”

Por dentro encontramos:

processamento massivo;

virtualização;

criptografia;

bancos de dados;

mensageria;

Linux;

APIs;

Java;

Python;

COBOL;

containers;

automação;

IA;

DevOps.

Talvez não seja literalmente maior por dentro.

Mas é suficientemente grande para assustar qualquer desenvolvedor que achava que “mainframe = COBOL + tela verde”.


33. O que realmente aprendemos

Depois de atravessar Quatermass, Doctor Who, Doomwatch, Survivors, Blake's 7, UFO e Espaço: 1999, podemos finalmente voltar para nosso café.

Essas séries ensinaram algo essencial.

Tecnologia não existe isolada.

Ela existe dentro de:

sociedade;

economia;

política;

organizações;

pessoas;

valores.

Portanto, nenhuma discussão tecnológica séria deveria terminar em:

“Funcionou.”

Precisamos perguntar também:

Funcionou para quem?

Com qual risco?

Sob qual controle?

Quem observa?

Quem audita?

Quem interrompe?

Quem responde?

Quem entende?


34. A pergunta que o jovem programador deve aprender

Quando receber sua primeira alteração em um sistema COBOL crítico, talvez você queira mostrar serviço.

Excelente.

Mas existe uma pergunta extremamente poderosa:

“O que pode dar errado?”

Depois:

“Como saberemos que deu errado?”

Depois:

“O que faremos se der errado?”

Essas três perguntas transformam um programador em engenheiro.


35. Não entre em pânico

Um ABEND acontece.

Não entre em pânico.

Veja o código.

Uma transação CICS falha.

Não entre em pânico.

Veja o contexto.

Um job fica preso.

Não entre em pânico.

Veja dependências.

Um usuário liga gritando.

Principalmente:

não entre em pânico.

O pânico reduz investigação.

E incidentes exigem investigação.


36. Observe antes de agir

Talvez Doomwatch pudesse ter como lema:

observar antes de intervir.

Isso é fantástico para produção.

Primeiro:

colete evidência.

Depois:

forme hipótese.

Depois:

valide.

Depois:

aja.

Em pseudo-COBOL:

PERFORM OBSERVE
PERFORM UNDERSTAND
PERFORM VALIDATE
PERFORM AUTHORIZE
PERFORM CHANGE
PERFORM VERIFY

Jamais:

PERFORM CHANGE
PERFORM PRAY

Embora esse segundo modelo tenha sido utilizado com surpreendente frequência na história da informática.


37. A grande lição da ficção científica britânica

Não foram as naves.

Não foram os monstros.

Não foram os figurinos.

Não foram os computadores piscantes.

A grande contribuição foi perceber que o problema fundamental do futuro seria:

como viver com as consequências das tecnologias que criamos.

Essa discussão aparece repetidamente nas obras analisadas: a matéria destaca explicitamente que essas produções dos anos 1970 utilizaram ficção científica para discutir questões sociais, políticas, ambientais e de poder.

Isso continua conosco.

IA.

Biotecnologia.

Computação quântica.

Cybersecurity.

Automação.

Redes sociais.

Mainframes.

Cloud.

Agentes autônomos.

A tecnologia continua avançando.

A pergunta continua praticamente a mesma.


38. Epílogo: o último operador do universo

Imagine o fim do universo.

As estrelas apagaram.

Os planetas desapareceram.

Os Daleks foram embora.

A Federação caiu.

A Lua finalmente encontrou uma órbita decente.

Arthur Dent terminou seu chá.

Restou apenas um datacenter IBM Z perdido no vazio cósmico.

Uma luz verde pisca.

No console aparece:

IEF404I JOB DAILY42 ENDED

Um velho operador olha para o relógio.

04:37.

Sorri.

O batch terminou.

O universo pode acabar tranquilo.

Porque em algum lugar nos últimos registros da civilização existe uma linha dizendo:

MAXCC=0000

E talvez essa seja a maior definição possível de sucesso operacional.

Não evitar todo problema.

Não possuir tecnologia perfeita.

Não prever exatamente o futuro.

Mas construir sistemas suficientemente compreendidos, observáveis, resilientes e responsáveis para continuar funcionando quando o inesperado finalmente aparecer.

Os britânicos descobriram isso enquanto colocavam monstros de borracha diante das câmeras.

Nós descobrimos novamente em cada war room.

Então, jovem programador COBOL, quando alguém aparecer diante de sua mesa dizendo:

“É só uma alteraçãozinha...”

segure sua toalha.

Beba seu café.

Abra o código.

Pergunte quem autorizou.

Descubra as dependências.

Prepare o rollback.

E lembre-se das palavras mais importantes já impressas em qualquer guia realmente útil para sobreviver à tecnologia:

NÃO ENTRE EM PÂNICO.

Principalmente em produção.

terça-feira, 4 de agosto de 2026

Como a Inteligência Artificial, o AI Job Hunter e um Espírito de Explorador Podem Transformar um Iniciante em um Profissional Contratável

 

Bellacosa Mainframe e os caçadores da vaga perdida

☕ Um Café no Bellacosa Mainframe

A Arca Perdida do Primeiro Emprego COBOL

Como a Inteligência Artificial, o AI Job Hunter e um Espírito de Explorador Podem Transformar um Iniciante em um Profissional Contratável

"Não é o chicote que faz Indiana Jones sobreviver às aventuras. É a preparação antes de entrar no templo."

O mesmo vale para quem deseja conquistar o primeiro emprego como Programador COBOL.



Prólogo — O Templo Esquecido

Imagine uma floresta fechada.

No meio dela existe um enorme templo coberto por musgo.

Na porta está escrito:

EMPREGO COBOL JÚNIOR

Você chega animado.

Bate na porta.

Ela não abre.

Então olha para o lado e vê dezenas de aventureiros indo embora.

Todos reclamam da mesma coisa.

— "As empresas só querem gente com experiência."

Mas...

Será mesmo?

Ou será que estamos tentando abrir a porta errada?

Hoje vamos vestir o chapéu de Indiana Jones, trocar o mapa do tesouro por um currículo ATS Friendly, transformar o chicote em um teclado IBM Model M e descobrir como a Inteligência Artificial pode ajudar um iniciante a entrar no fascinante mundo do Mainframe.

Prepare seu café.

Nossa expedição está apenas começando.



Capítulo 1 — A Primeira Armadilha: A Experiência

Existe uma crença quase religiosa entre iniciantes.

"Sem experiência ninguém contrata."

Essa frase parece lógica.

Mas basta observar como funcionam os grandes bancos, seguradoras e empresas de tecnologia.

Todos os anos milhares de jovens são contratados.

Como?

Eles nasceram com experiência?

Claro que não.

O mercado procura algo diferente.

Ele procura evidências de capacidade.

Existe uma enorme diferença entre:

"Eu sei COBOL."

e

"Posso provar que sei COBOL."

É exatamente aqui que começa nossa aventura.



O Guardião do Templo: O Recrutador

Imagine um recrutador sentado diante de 300 currículos.

Ele possui poucos segundos para decidir.

Ele não conhece você.

Nunca conversou com você.

Nunca viu seus projetos.

Tudo o que ele possui é um documento.

É como um arqueólogo olhando um fragmento de cerâmica.

Ele precisa imaginar a história inteira.

Seu currículo precisa ajudá-lo nessa missão.



A IA Não Procura Pessoas. Procura Evidências.

O infográfico do AI Job Hunter mostra um conceito extremamente moderno.

A Inteligência Artificial não está apenas procurando palavras.

Ela está tentando responder uma pergunta muito mais interessante:

"Este profissional possui características semelhantes às pessoas que foram contratadas para esta vaga anteriormente?"

Essa diferença muda completamente o jogo.



O AI Job Hunter — O Mapa da Expedição

Imagine o AI Job Hunter como o mapa que Indiana Jones recebeu antes de procurar a Arca da Aliança.

Sem ele...

Você entra em qualquer caverna.

Com ele...

Você sabe exatamente onde está o tesouro.

O sistema funciona como um enorme mecanismo de recomendação.

Entrada:

  • currículo

  • cursos

  • certificados

  • habilidades

  • tecnologias

  • objetivos profissionais

Processamento:

  • IA

  • análise semântica

  • compatibilidade

  • recomendação

Saída:

As vagas com maior probabilidade de sucesso.

Parece simples.

Mas por trás disso existe um conjunto enorme de tecnologias.

https://www.dio.me/articles/vem-ai-o-ai-job-hunter-seu-agente-de-ia-para-conquistar-as-melhores-vagas-e-salarios-em-tecnologia-4f73edde6424



O Primeiro Enigma — Busca Inteligente

Há alguns anos um sistema faria isto:

Você digitava:

COBOL

Resultado:

Todas as vagas contendo COBOL.

Hoje isso seria considerado extremamente limitado.

Os mecanismos modernos utilizam busca semântica.

Se você escreve:

Enterprise COBOL

O sistema pode entender também:

  • IBM Z

  • Mainframe

  • Batch

  • CICS

  • z/OS

  • Legacy Modernization

  • Mission Critical

Perceba.

Ele compreende significado.

Não apenas palavras.



Easter Egg nº 1

Fernando Corbató revolucionou os computadores com o Time Sharing.

Hoje os algoritmos de IA fazem algo semelhante.

Em vez de compartilhar tempo de CPU entre usuários, compartilham atenção entre milhões de currículos.

Curiosamente...

Ambos nasceram exatamente do mesmo problema:

Como utilizar recursos limitados da maneira mais inteligente possível?



O Segundo Enigma — O Score

Imagine um grande painel.

Cada tecnologia acende uma luz.

COBOL ✔

JCL ✔

VSAM ✔

Git ✔

DB2 ✔

REST ✔

Cloud ✔

Quanto mais luzes acendem...

Maior sua aderência.

Mas cuidado.

O score não mede inteligência.

Ele mede proximidade com uma vaga específica.

É perfeitamente possível possuir 95% para um banco e apenas 40% para uma fintech.

Isso não significa que você é pior.

Significa apenas que são necessidades diferentes.


A Maldição do Currículo Genérico

Talvez este seja o maior erro dos iniciantes.

Currículo:

Conhecimento em programação.

Isso não diz absolutamente nada.

Agora observe.

Desenvolvedor em formação com conhecimentos em Enterprise COBOL, JCL, VSAM, SQL e fundamentos de CICS. Experiência prática em projetos acadêmicos utilizando IBM Z Xplore e GitHub.

Mesma pessoa.

Outra percepção.


Indiana Jones Nunca Entrava Sem Equipamentos

Por que tantos iniciantes tentam entrar no mercado apenas com um curso?

Indiana levava:

  • mapa

  • bússola

  • chicote

  • lanterna

  • mochila

  • experiência

Você precisa montar sua mochila profissional.

Ela deve conter:

  • COBOL

  • Git

  • GitHub

  • JCL

  • VSAM

  • SQL

  • DB2

  • IBM Z Xplore

  • LinkedIn

  • Portfólio

Cada item reduz um pouco o risco percebido pelo recrutador.


O Tesouro Escondido Chama-se GitHub

Muitos acreditam que GitHub serve apenas para Java.

Grande erro.

Imagine um recrutador abrindo seu perfil.

Ele encontra.

Projeto 1

Sistema Bancário

Projeto 2

Folha de Pagamento

Projeto 3

Controle de Estoque

Projeto 4

Cadastro de Clientes

Projeto 5

CRUD VSAM

Projeto 6

CRUD DB2

Projeto 7

Integração REST

Agora ele consegue enxergar algo.

Você produz.


Curiosidade Histórica

Durante décadas os programadores COBOL levavam listagens impressas com centenas de páginas para demonstrar seu trabalho.

Hoje...

Um simples link do GitHub mostra tudo.

Mudou a tecnologia.

Mas a necessidade continua igual.

Demonstrar competência.


O Raio-X da Vaga

Um recurso extremamente interessante do AI Job Hunter é o chamado Raio-X.

Ele praticamente responde:

"O que falta para você?"

Imagine.

Você possui:

COBOL

JCL

VSAM

DB2

Git

O sistema informa.

Faltam:

Docker

Jenkins

APIs REST

OpenShift

Agora seu estudo deixa de ser aleatório.

Você sabe exatamente onde investir seu tempo.


A Expedição do Conhecimento

Existe uma diferença enorme entre estudar e evoluir.

Muitos fazem isso:

Curso

Outro curso

Outro curso

Outro curso

Outro curso

Nenhum projeto.

Nenhuma aplicação.

Nenhuma prática.

É como Indiana Jones lendo cinquenta mapas sem sair de casa.

Conhecimento precisa virar construção.


O Método Bellacosa dos Cinco Artefatos

Imagine que cada novo conhecimento gera um artefato.

Artefato 1

Curso

Aprendeu.


Artefato 2

Projeto

Aplicou.


Artefato 3

GitHub

Publicou.


Artefato 4

LinkedIn

Compartilhou.


Artefato 5

Portfólio

Organizou.

Agora existe uma trilha de evidências.


O Diário Perdido do Arqueólogo

Indiana Jones sempre fazia anotações.

Faça o mesmo.

Sempre que terminar um assunto.

Escreva.

Hoje aprendi:

  • PERFORM

  • OCCURS

  • VSAM KSDS

  • IDCAMS

  • SORT

  • SQL

Essas anotações podem virar:

  • artigos

  • posts

  • apresentações

  • vídeos

  • documentação

Sem perceber, você começa a construir autoridade.


O Verdadeiro Significado da Experiência

Essa talvez seja a maior descoberta desta jornada.

Experiência não significa apenas:

Carteira assinada.

Experiência também é:

Resolver problemas.

Criar projetos.

Corrigir erros.

Ler documentação.

Participar da comunidade.

Construir soluções.

É por isso que dois iniciantes podem parecer completamente diferentes para um recrutador.


Easter Egg nº 2 — O Graal do Mainframe

Nos filmes, o Santo Graal não era o copo mais bonito.

Era o mais simples.

No mercado de tecnologia acontece algo parecido.

O melhor currículo nem sempre é o mais colorido.

É o mais claro.

A simplicidade continua sendo uma das maiores virtudes de um documento ATS Friendly.


O Plano de 90 Dias

Primeiro mês

Domine:

  • COBOL

  • Git

  • GitHub

Construa:

Primeiro projeto.


Segundo mês

Aprenda:

  • JCL

  • VSAM

  • SQL

  • DB2

Publique dois projetos completos.


Terceiro mês

Estude:

  • CICS

  • REST

  • JSON

  • Cloud Computing (conceitos)

Monte:

  • LinkedIn

  • Portfólio

  • Currículo ATS Friendly

Comece a enviar currículos.


O Segredo dos Bancos

Pouca gente sabe.

Quando um banco contrata um Programador COBOL Júnior, ele não espera um especialista em z/OS.

Ele espera alguém que:

  • saiba aprender;

  • tenha disciplina;

  • consiga trabalhar em equipe;

  • leia documentação;

  • resolva problemas;

  • demonstre curiosidade técnica.

Essas competências são treináveis.


A Nova Arca da Aliança

Durante muitos anos o currículo era a Arca da Aliança do mercado.

Hoje ele é apenas uma peça.

O profissional moderno possui:

Currículo

GitHub

LinkedIn

Projetos

Certificações

Comunidade

Aprendizado contínuo

Tudo isso forma sua identidade profissional.


O Último Desafio do Templo

Antes da sala do tesouro existe uma inscrição.

Ela diz:

"Somente aqueles que provarem seu valor poderão atravessar."

Não diz.

"Somente quem possui cinco anos de experiência."

Diz.

"Quem provar seu valor."

Essa pequena diferença muda completamente a forma de enxergar sua carreira.


Sherlock Holmes Entra na Expedição

Se Indiana Jones representa a coragem para entrar no templo, Sherlock Holmes representa a capacidade de observar detalhes que os outros ignoram.

Um recrutador experiente faz exatamente isso. Ele procura pistas:

  • O GitHub mostra evolução ao longo dos meses?

  • Os projetos possuem documentação?

  • O candidato escreve commits claros?

  • Existe consistência entre currículo, LinkedIn e portfólio?

  • As certificações acompanham a evolução técnica?

Essas pequenas evidências contam uma história. E histórias coerentes geram confiança.


O Futuro do Programador COBOL

Durante décadas dizia-se que COBOL estava morrendo.

Enquanto isso, bancos processavam bilhões de transações diariamente em sistemas escritos nessa linguagem.

Hoje o cenário mudou novamente.

O profissional COBOL não trabalha isolado. Ele conversa com:

  • APIs REST

  • Microsserviços

  • Cloud híbrida

  • IA Generativa

  • Git

  • DevOps

  • OpenShift

  • z/OS Connect

  • Observabilidade

  • Segurança

Isso significa que o objetivo não é ser apenas um programador COBOL, mas um desenvolvedor capaz de integrar o legado ao futuro.


Conclusão — O Tesouro Nunca Esteve no Final da Jornada

No último filme de Indiana Jones, aprendemos que a maior descoberta nunca foi um artefato.

Foi a própria jornada.

Com a carreira acontece exatamente o mesmo.

O primeiro emprego não é o tesouro.

Ele é apenas a porta de entrada para um universo de aprendizado contínuo.

Ferramentas como o AI Job Hunter ajudam a iluminar o caminho, mostrando quais vagas combinam com seu perfil, quais competências ainda precisam ser desenvolvidas e como apresentar melhor seu potencial. Mas nenhuma IA substitui aquilo que realmente transforma um iniciante em um profissional contratável: curiosidade, disciplina, prática e disposição para aprender todos os dias.

Lembre-se de uma última frase que poderia muito bem estar gravada na parede de um antigo templo do IBM Z:

"Quem espera ter experiência para começar nunca começa. Quem começa a construir evidências cria a própria experiência."

Então ajuste o chapéu, organize seu GitHub, atualize seu LinkedIn, prepare um bom currículo ATS Friendly e continue explorando. O mundo do Mainframe ainda guarda muitos tesouros — e o próximo pode ser justamente a sua primeira oportunidade como Programador COBOL Júnior.

https://github.com/VagnerBellacosa/437_CarrinhoComprasShopeeNode.js

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...