☕ 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

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

domingo, 30 de agosto de 2026

Dr. House Entra no Centro de Operações — Seis Etapas de IA, um Programa COBOL em Coma e o Diagnóstico que o Logo Bonito Não Faz

 

Bellacosa Mainframe e as 6 etapas de ia para um programador cobol

☕ Um Café no Bellacosa Mainframe

Dr. House Entra no Centro de Operações — Seis Etapas de IA, um Programa COBOL em Coma e o Diagnóstico que o Logo Bonito Não Faz

Ou: por que assinar vinte ferramentas de inteligência artificial não salva um processo mal definido, não conserta um S0C7 e certamente não dá alta para produção sem exame, teste e alguém disposto a dizer “isso não fecha”


Prólogo — O paciente chegou falando em produtividade

Eram 7h12 quando um jovem padawan COBOL entrou na sala de diagnóstico do hospital imaginário de Princeton-Plainsboro, carregando um notebook, três abas abertas, uma apresentação com quarenta logos coloridos e uma expressão de quem acabara de descobrir o Santo Graal da produtividade.

— Doutor House, encontrei o mapa definitivo. São seis etapas para fazer mais com IA: pensar, programar, criar conteúdo, trabalhar melhor, fazer imagens e automatizar tudo.

House nem levantou os olhos da bengala.

— “Automatizar tudo” é uma frase linda. Também é uma ótima maneira de automatizar um desastre inteiro antes do café.

O rapaz ficou imóvel.

— Mas tem ChatGPT, Claude, Perplexity, Cursor, Replit, Midjourney, n8n, Zapier…

— Exatamente — respondeu House. — Uma ambulância cheia de aparelhos não cura o paciente se ninguém souber qual órgão está falhando. Agora me diga: qual é o problema?

E ali começa a conversa que todo iniciante precisa ter. Inteligência artificial não é uma coleção de aplicativos com ícones bonitos. É uma camada de apoio para pensar, pesquisar, escrever, programar, revisar, criar, organizar e automatizar. Quando usada com método, poupa tempo e melhora a qualidade. Quando usada como caixa-preta, produz uma quantidade industrial de respostas convincentes, código aparentemente elegante, imagens espetaculares e erros muito bem embalados.

No mainframe, onde um detalhe de dado, segurança ou processamento pode afetar milhares — às vezes milhões — de operações, essa diferença é ainda maior.

O Dr. House, naturalmente, não está interessado em “qual IA é a melhor”. Ele quer saber: qual é o sintoma? Qual dado confirma a hipótese? O que pode estar escondido? E qual ação ainda precisa de um ser humano com responsabilidade e café suficiente?



1. Primeira etapa: pensar e perguntar — antes de pedir resposta, descubra a pergunta

A primeira camada do quadro reúne ferramentas como ChatGPT, Claude e Perplexity. Em aparência, elas fazem a mesma coisa: você escreve uma pergunta e recebe uma resposta. Na prática, o uso saudável é mais profundo.

Uma ferramenta conversacional pode ajudar a:

  • organizar uma ideia confusa;

  • explicar um conceito técnico em vários níveis;

  • criar exemplos;

  • comparar soluções;

  • revisar um texto;

  • transformar um requisito em casos de teste;

  • fazer o papel de aluno iniciante, arquiteto, revisor ou advogado do diabo.

Já uma ferramenta focada em pesquisa tende a ser mais útil quando você precisa localizar fontes, comparar documentação, verificar onde uma afirmação apareceu e continuar a investigação por conta própria.

A primeira lição do padawan COBOL é simples: a IA responde à pergunta que você fez, não à pergunta que você queria ter feito.

Compare:

“Explique CICS.”

Agora compare:

“Explique HANDLE CONDITION em CICS para um programador COBOL iniciante. Diferencie-o de HANDLE ABEND, apresente um exemplo de erro ao tratar NOTFND e explique por que capturar um abend e simplesmente retornar pode esconder um problema de integridade.”

A segunda pergunta tem objetivo, contexto, profundidade e critérios de qualidade. Ela força a ferramenta a trabalhar. A primeira pede uma apostila genérica, algo entre “CICS é um monitor de transações” e uma vontade súbita de fechar a aba.

House bateu com a bengala na mesa.

— Todo mundo mente. Inclusive o requisitante. Ele diz que precisa de “uma explicação sobre Db2”, mas na verdade precisa descobrir por que o programa Java recebe -805 e o SELECT no SPUFI funciona.

É uma provocação, mas ela carrega uma verdade operacional: perguntas vagas produzem respostas vagas. Em tecnologia, o problema real costuma estar escondido atrás da primeira descrição.

Um método simples para perguntar melhor

Antes de chamar uma IA, organize cinco itens:

  1. Objetivo: o que você quer decidir, aprender ou produzir?

  2. Contexto: qual ambiente, linguagem, versão, público ou restrição?

  3. Entrada: quais dados, logs, trecho de código ou fontes são confiáveis?

  4. Saída esperada: explicação, checklist, código, teste, tabela, roteiro?

  5. Critério de aceitação: como você saberá que a resposta presta?

Exemplo aplicado:

“Tenho um programa COBOL batch que lê um arquivo sequencial e recebe S0C7 ao calcular valor líquido. Crie hipóteses ordenadas por probabilidade, diga quais campos devo inspecionar, mostre um exemplo seguro de validação antes do cálculo e não invente o conteúdo do dump.”

Essa é uma excelente conversa técnica. A IA pode sugerir que campos numéricos contêm espaços, caracteres inválidos, sinal inesperado, desalinhamento de layout ou uma origem de dados mal tratada. Mas o dump, o DISPLAY, o FILE STATUS, o layout real e a evidência ainda são seus.

A IA pode levantar diagnóstico diferencial. Não pode declarar o paciente curado sem exame.


2. A segunda etapa: construir e programar — velocidade não substitui entendimento

Cursor, Replit, Lovable, Base44 e ferramentas semelhantes prometem construir aplicações rapidamente. E cumprem parte da promessa. Elas conseguem gerar telas, APIs simples, formulários, protótipos, integrações comuns e até estruturas iniciais de projetos em tempo muito menor que o desenvolvimento manual.

Mas existe uma diferença histórica entre:

  • fazer uma demonstração funcionar;

  • fazer um sistema sobreviver à realidade.

No hospital de House, o jovem padawan mostra um aplicativo de cadastro de clientes gerado em vinte minutos.

— Ele cria, altera e exclui clientes — comemora.

House olha para a tela.

— Quem pode excluir? Exclusão é física ou lógica? O CPF pode mudar? Como você evita que dois operadores alterem o mesmo registro? Cadê o log de auditoria? Onde está o rollback? O que acontece se o banco cair entre atualizar o cadastro e registrar a transação? Quem validou a autorização?

Silêncio.

Em COBOL, nós já conhecemos esse filme. Um MOVE é fácil. O difícil é saber se ele deveria acontecer. Um WRITE é fácil. O difícil é garantir que o registro não foi duplicado, que a chave é válida, que o arquivo está consistente e que o operador não está vendo uma mensagem bonita escondendo um erro grave.

A IA é muito boa para acelerar tarefas mecânicas:

  • criar o esqueleto de um programa;

  • explicar um trecho legado;

  • gerar comentários iniciais;

  • sugerir refatorações;

  • criar casos de ZUnit;

  • transformar regras descritas em linguagem natural em cenários de teste;

  • elaborar uma matriz de entradas e saídas;

  • ajudar a escrever JCL de laboratório;

  • documentar um fluxo CICS, Db2 ou VSAM.

Mas ela precisa ser tratada como um desenvolvedor júnior muito rápido, muito disponível e perigosamente confiante. Ela não conhece o seu ambiente por osmose. Ela não sabe quais copybooks são padrão, quais campos carregam regras históricas, qual job tem janela crítica, qual transação depende de outra nem que um campo aparentemente inocente é usado por um sistema de fraude há quinze anos.

O teste da pergunta incômoda

Antes de aceitar código gerado por IA, pergunte:

  • Compila?

  • Passa nos testes?

  • Trata erro?

  • Mantém o padrão do projeto?

  • Expõe dado sensível?

  • Tem permissão excessiva?

  • Entende concorrência?

  • É reversível?

  • Foi revisado por alguém que conhece a regra de negócio?

Se a resposta a qualquer uma for “não sei”, o código não está pronto. Está apenas escrito.

A produtividade verdadeira não é gerar mais linhas. É reduzir o tempo entre entender uma necessidade e entregar uma mudança correta, testada, auditável e sustentável.


3. Terceira etapa: criar conteúdo — a IA multiplica formatos, não fabrica autoridade

A terceira faixa do mapa fala de ferramentas para texto, avatar, vídeo, edição, cortes e newsletter. Aqui existe um ganho extraordinário para quem cria conteúdo técnico.

Uma explicação boa sobre COBOL pode virar várias peças:

  • artigo detalhado para blog;

  • roteiro de vídeo;

  • short de 45 segundos;

  • carrossel para LinkedIn;

  • infográfico;

  • checklist;

  • newsletter;

  • exercício para alunos;

  • perguntas e respostas;

  • thumbnail para YouTube.

A IA reduz o esforço de conversão entre formatos. Ela pode pegar um texto longo e sugerir títulos, cortes, pontos de curiosidade, estrutura de carrossel ou uma lista de dúvidas frequentes.

Mas atenção: converter não é repetir.

Se você pega um artigo técnico e manda a IA “criar dez posts”, ela provavelmente entregará dez versões da mesma sopa requentada: “No mundo acelerado de hoje…”, “Você sabia?”, “A revolução chegou…”. É conteúdo que não ofende ninguém e também não permanece em ninguém.

A conexão nasce de uma voz própria, de um exemplo realista e de uma tese. Um texto sobre S0C7 é mais memorável quando explica que o programa não “ficou louco”: alguém mandou o COBOL tratar como número algo que, em algum ponto da cadeia, deixou de ser número. O abend é o médico gritando que o exame de sangue não combina com o diagnóstico.

House aprovaria essa parte.

— O sintoma não é a doença. Febre não é diagnóstico. S0C7 também não.

Para conteúdo técnico, a IA deve ajudar a estruturar e editar; a experiência humana deve fornecer o cheiro de produção. É ela que sabe por que um ICH408I em homologação pode ser uma configuração inocente ou a primeira pista de uma concessão de acesso feita sem controle. É ela que sabe que o programa “simples” costuma ter uma regra escondida no copybook, uma exceção em um IF e uma história antiga que ninguém documentou.

A máquina produz texto. O autor produz significado.


4. Quarta etapa: trabalhar com mais inteligência — não é só escrever melhor, é construir memória confiável

Ferramentas de correção, anotações, e-mail, ditado, pesquisa de documentos e organização parecem menos glamourosas do que gerar um vídeo cinematográfico. Mas, para quem trabalha com conhecimento, elas podem ser mais úteis.

A maior virada de chave ocorre quando a IA deixa de conversar apenas com “a internet” e passa a trabalhar sobre material confiável e permitido: documentação oficial, runbooks, procedimentos, atas, manuais, apostilas, normas, código autorizado e notas técnicas.

Imagine duas perguntas.

A primeira:

“Como resolver um ICH408I?”

A segunda:

“Com base no procedimento de acesso de homologação, explique o fluxo aprovado para investigar ICH408I, indicando que evidências devem ser coletadas antes de solicitar alteração de perfil.”

A primeira pode oferecer boas ideias gerais. A segunda pode ajudar no trabalho real — desde que a base de documentos esteja correta e que a empresa autorize esse tratamento.

Aqui entra um cuidado sério: dados de produção, dumps, credenciais, informações pessoais, chaves, código proprietário e documentação interna não devem ser enviados automaticamente para qualquer serviço externo. O entusiasmo com IA não suspende LGPD, contrato, sigilo profissional, política de segurança ou bom senso.

No mainframe, segurança não é enfeite de apresentação. É controle de acesso, segregação de funções, trilha de auditoria e mínima permissão necessária. Uma ferramenta inteligente com acesso amplo continua sendo uma ferramenta com acesso amplo. E isso é exatamente o tipo de coisa que House chamaria de “ideia ruim com interface amigável”.


5. Quinta etapa: voz, imagem, vídeo e design — visual forte exige direção, não apenas geração

Ferramentas de imagem, vídeo, música, voz e design permitem testar ideias com uma rapidez que seria impensável há pouco tempo. Você pode imaginar um mainframe como uma usina, um cowboy CICS perseguindo um abend ou Dr. House examinando um programa COBOL em coma — e transformar essa cena em imagem.

Isso é valioso. O visual prende atenção, facilita a memória e abre a porta para a explicação.

Mas imagem gerada não é documentação técnica. Ela ilustra uma ideia; não prova um fato. E qualquer texto técnico dentro de uma imagem exige revisão. Nomes de comandos, mensagens de erro, campos COBOL, números de versão e sintaxe são terreno fértil para pequenas deformações que o olho passa por cima e o leitor atento percebe.

Um bom processo visual tem quatro partes:

  1. Definir a mensagem: qual é a única ideia que a imagem deve transmitir?

  2. Gerar a cena-base: usar IA para composição, personagens, cor e atmosfera.

  3. Revisar os detalhes: corrigir termos, legibilidade, logo, dados e contexto.

  4. Manter identidade: repetir elementos visuais que façam o leitor reconhecer sua marca.

A imagem não precisa explicar tudo. Ela deve fazer o leitor querer entrar no texto.


6. Sexta etapa: automatizar — o ponto onde a produtividade vira operação

Automação é a etapa mais poderosa e, por isso mesmo, a que exige mais disciplina.

Ferramentas como n8n, Zapier, agentes, conectores, robôs de coleta e serviços de integração permitem ligar eventos e ações. Um arquivo chegou? O fluxo lê, organiza, gera resumo e envia para revisão. Uma fonte oficial publicou notícia? O fluxo coleta links, classifica assuntos e prepara o radar semanal. Uma planilha mudou? O processo atualiza uma base ou cria uma tarefa.

Isso poupa horas. Mas “automatizar tudo” é uma frase que deveria vir com sirene, extintor e uma pessoa segurando o botão de desligar.

O fluxo saudável é:

Evento → coleta → organização → rascunho → revisão humana → ação externa

O fluxo perigoso é:

Evento → IA interpreta → IA decide → IA publica → IA responde → problema

A diferença é a aprovação humana. Quanto maior o impacto da ação, maior deve ser a trava.

Para automatizar com segurança, siga o passo a passo do jovem padawan:

  1. Escolha uma tarefa repetitiva e bem compreendida.

  2. Execute o processo manualmente algumas vezes e documente cada passo.

  3. Defina entradas, saídas e exceções.

  4. Automatize primeiro apenas a coleta ou o rascunho.

  5. Mantenha aprovação humana para publicar, enviar, apagar, pagar, conceder acesso ou alterar registros críticos.

  6. Registre logs.

  7. Crie limite de volume, tentativas e custo.

  8. Teste falhas de propósito.

  9. Garanta que exista um botão de desligar.

  10. Revise o fluxo periodicamente.

Em linguagem de mainframe: não entregue ALTER, DELETE, acesso privilegiado e SUBMIT de produção para um processo que ninguém consegue explicar. Primeiro defina o procedimento. Depois teste. Depois limite. Depois monitore. Só então escale.


7. A etapa esquecida no infográfico: validar

O grande buraco de muitos mapas de IA é a ausência da validação. Eles mostram pensar, criar e automatizar, mas pulam justamente a parte em que o adulto entra na sala e pergunta: “como sabemos que isso está certo?”

A versão madura das seis etapas seria:

  1. definir o problema;

  2. pesquisar e raciocinar;

  3. produzir um rascunho;

  4. validar tecnicamente e contextualmente;

  5. publicar ou executar;

  6. automatizar o que já funciona.

A validação depende do tipo de trabalho:

EntregaValidação mínima
Texto técnicofontes, exemplos, termos e versão correta
Códigocompilação, testes, revisão e segurança
Imagemlegibilidade, fidelidade de termos e direitos
Automaçãologs, limites, falhas e reversão
Resposta operacionalevidência, procedimento e responsável

House fecha a pasta do paciente.

— Então qual é o diagnóstico?

O padawan respira e responde:

— IA não é um substituto para pensar. É uma forma de encurtar a distância entre uma pergunta bem feita e uma entrega revisada.

House dá um meio sorriso, o equivalente médico a fogos de artifício.

— Agora você pode ter alta. Mas não toque em produção.


Epílogo — O logo não tem a culpa, mas também não faz o trabalho

As ferramentas do infográfico são úteis. Muitas são excelentes. Algumas serão substituídas, incorporadas por outras ou mudarão de preço, recurso e qualidade em poucos meses. Esse é o detalhe menos importante.

O que permanece é o método.

Use IA para pensar melhor, não para terceirizar o pensamento. Use-a para acelerar código, mas teste antes de confiar. Use-a para multiplicar um conteúdo que tenha substância. Use-a para organizar conhecimento permitido e confiável. Use-a para criar visuais que abram a conversa. Use-a para automatizar o repetitivo — nunca para entregar decisões perigosas a uma caixa-preta simpática.

O programador COBOL iniciante que aprende isso cedo leva uma vantagem enorme. Ele não será a pessoa que sabe pedir “faça um sistema bancário completo”. Será a pessoa que entende a pergunta, identifica a regra, procura a evidência, testa a resposta, protege os dados e sabe onde a automação deve parar.

No fim, o mainframe e o Dr. House concordam em algo: confiança não vem de uma tela bonita dizendo que deu certo. Confiança vem de evidência, controle, rastreabilidade e da capacidade de descobrir o que aconteceu quando, inevitavelmente, alguma coisa der errado.

E quando o primeiro S0C7 aparecer no plantão, não entre em pânico. Pegue o café, reúna os fatos, faça perguntas melhores e desconfie de toda resposta que parece fácil demais.

terça-feira, 30 de junho de 2026

Inteligência Artificial: Ferramenta ou Autora?

 

Bellacosa Mainframe inteligencia artificial ferramenta ou autora?

☕ Um Café no Bellacosa Mainframe

Inteligência Artificial: Ferramenta ou Autora?

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Criatividade, Direitos Autorais, Plágio, Engenharia de Prompt e Por Que a Maior Discussão da IA Não É Tecnológica — É Humana

"Um compilador nunca foi considerado autor de um programa COBOL. Então por que uma IA deveria ser considerada autora de um texto?"

Vivemos um momento curioso da história.

Talvez o mais curioso desde o surgimento da Internet.

Há poucos anos, quem escrevia um artigo digitava palavra por palavra.

Quem criava uma imagem precisava dominar Photoshop, Illustrator ou desenhar à mão.

Quem escrevia um livro passava meses organizando ideias.

Então surgiram os modelos generativos.

Hoje uma pessoa escreve um prompt de três linhas e, em poucos segundos, recebe um artigo inteiro, uma apresentação, uma música, uma imagem ou até centenas de linhas de código.

E imediatamente nasce a pergunta.

Quem criou aquilo?

A IA?

Ou a pessoa?

Essa pergunta parece simples.

Mas envolve filosofia, direito, ética, engenharia de software, criatividade, educação e até psicologia.

Infelizmente, boa parte da discussão acontece de forma apaixonada.

Pouca reflexão.

Muito preconceito.

Muito medo.

E pouca compreensão de como essas ferramentas realmente funcionam.

Vamos tomar um café.

Porque essa conversa merece calma.


Primeiro precisamos esquecer Hollywood

Hollywood nos ensinou uma imagem completamente errada da Inteligência Artificial.

Robôs conscientes.

Máquinas que pensam.

Computadores que possuem vontade própria.

Nada disso descreve um LLM moderno.

ChatGPT.

Claude.

Gemini.

Copilot.

Llama.

Mistral.

Nenhum deles "pensa" como uma pessoa.

Eles calculam probabilidades.

A próxima palavra.

Depois a próxima.

Depois outra.

Bilhões de vezes.

Existe um modelo matemático gigantesco por trás disso.

Mas não existe intenção.

Não existe desejo.

Não existe inspiração.

Não existe ego.

Não existe sofrimento.

Não existe orgulho.

E principalmente...

não existe autoria consciente.


Um martelo não constrói uma casa

Imagine um carpinteiro.

Ele possui:

  • martelo

  • serra

  • furadeira

  • parafusadeira

  • esquadro

Quem construiu a casa?

O martelo?

Claro que não.

O martelo apenas ampliou a capacidade humana.

Agora pense em um compilador COBOL.

Você escreve o código.

O compilador gera milhares de instruções de máquina.

Quem escreveu o programa?

O compilador?

Nunca.

Ele apenas traduziu.

A IA faz algo semelhante.

Só que muito mais sofisticado.

Ela amplia nossa capacidade intelectual.


O prompt é uma forma de engenharia

Existe uma enorme diferença entre pedir:

"Escreva um artigo."

e pedir:

"Escreva um artigo de 2.000 palavras para arquitetos IBM Z. Use analogias com COBOL, DevOps e Kubernetes. Explique historicamente. Utilize linguagem técnica, mas acessível. Finalize com aplicações práticas."

Esses dois resultados serão completamente diferentes.

Por quê?

Porque o segundo caso envolve projeto.

Planejamento.

Objetivo.

Conhecimento.

Curadoria.

Existe intenção humana.

E intenção é parte essencial da criação.


A IA cria do nada?

Não.

Nem seres humanos fazem isso.

Shakespeare leu outros autores.

Newton estudou Galileu.

Einstein estudou Maxwell.

Os Beatles ouviram blues.

Todo conhecimento humano é construído sobre conhecimento anterior.

A IA faz exatamente isso.

Aprende padrões estatísticos.

Não consulta um cérebro mágico.

Não recebe inspiração divina.

Ela reorganiza padrões.

Os humanos também reorganizam padrões.

A diferença está na consciência.


Então quem é o autor?

Essa é a pergunta de um milhão de dólares.

Imagine quatro situações.

Caso 1

Você escreve um livro inteiro.

A IA apenas corrige ortografia.

Autor?

Você.

Sem discussão.


Caso 2

Você escreve um livro.

A IA melhora estilo.

Reorganiza capítulos.

Sugere títulos.

Autor?

Continua sendo você.

Da mesma forma que um editor não vira autor do livro.


Caso 3

Você fornece estrutura.

Capítulos.

Argumentos.

Pesquisa.

Exemplos.

Reescreve metade.

Remove trechos.

Inclui experiências pessoais.

Autor?

Ainda é você.

A IA foi uma ferramenta.

Muito poderosa.

Mas ferramenta.


Caso 4

Você escreve:

"Escreva um romance."

Copia.

Publica.

Sem alterar uma linha.

A situação muda bastante.

Nesse caso, sua contribuição criativa foi mínima.

Você dificilmente poderia reivindicar integralmente aquela criação como fruto de um trabalho intelectual profundo.


O problema não é usar IA

O problema é fingir que não usou.

É parecido com uma calculadora.

Um engenheiro usa calculadora.

Um contador usa planilhas.

Um médico usa tomografia.

Ninguém considera isso fraude.

Fraude ocorre quando existe mentira.

Imagine um concurso literário cujo regulamento diz:

"Somente textos escritos integralmente por humanos."

Você usa IA escondido.

Isso é antiético.

Agora imagine outro concurso que permite IA.

Não existe problema.

O contexto importa.


O fantasma do plágio

Outro tema que aparece constantemente.

"IA é plágio."

Será?

Nem sempre.

Plágio significa apresentar como seu algo criado por outra pessoa identificável.

Os LLMs normalmente não copiam livros inteiros.

Eles geram novos textos baseados em padrões aprendidos.

Isso não significa que nunca possam reproduzir trechos existentes.

Pode acontecer.

Especialmente quando o conteúdo solicitado é muito específico.

Por isso sempre vale revisar.

Verificar.

Conferir fontes.

A responsabilidade continua sendo humana.


A sociedade condena porque ainda está aprendendo

Toda grande tecnologia passou por isso.

Quando surgiu a imprensa:

"Haverá excesso de livros."

Quando surgiu a calculadora:

"As crianças nunca aprenderão matemática."

Quando surgiu a Internet:

"Ninguém mais estudará."

Quando surgiu o Google:

"As pessoas deixarão de memorizar."

Quando surgiu a Wikipédia:

"Ela destruirá a educação."

Agora chegou a IA.

A história se repete.

O medo normalmente aparece antes da compreensão.


O verdadeiro diferencial deixou de ser escrever

Durante muito tempo, escrever era uma habilidade rara.

Hoje produzir texto ficou barato.

Muito barato.

O valor mudou.

Agora vale mais:

  • fazer perguntas inteligentes;

  • validar informações;

  • conectar ideias;

  • identificar erros;

  • exercer pensamento crítico;

  • tomar decisões;

  • assumir responsabilidade.

Isso nenhuma IA faz por você.


Um excelente prompt não nasce por acaso

Existe um equívoco comum.

Algumas pessoas imaginam que um prompt seja apenas uma frase.

Na realidade, um bom prompt pode representar anos de experiência.

Quando um médico solicita uma análise complexa a uma IA, ele sabe exatamente o que perguntar.

Quando um advogado pede uma minuta contratual, ele conhece os riscos jurídicos.

Quando um arquiteto IBM Z pede uma arquitetura resiliente, ele conhece CICS, DB2, MQ, RACF, WLM, Sysplex e dezenas de tecnologias.

A qualidade do resultado depende diretamente da qualidade de quem pergunta.

Garbage In.

Garbage Out.

Esse princípio continua absolutamente verdadeiro.


A IA não substitui experiência

Imagine pedir à IA:

"Projete um sistema bancário."

Ela consegue.

Mas será um projeto realmente adequado?

Talvez.

Talvez não.

Quem identifica os riscos?

Quem percebe uma inconsistência regulatória?

Quem sabe que determinada arquitetura falhou em um banco há dez anos?

Quem entende as restrições do negócio?

Quem responde perante um cliente?

Sempre haverá uma pessoa.

A responsabilidade nunca desaparece.


E na educação?

Esse talvez seja o debate mais importante.

Muitos professores proíbem IA.

Outros incentivam.

Quem está certo?

Depende do objetivo.

Se a intenção é avaliar escrita manual, talvez o uso de IA realmente prejudique a avaliação.

Mas se o objetivo é resolver problemas reais...

Proibir IA pode ser semelhante a proibir computadores em um curso de informática.

O mercado não fará essa proibição.

Os profissionais usarão IA.

Os melhores profissionais aprenderão a utilizá-la com responsabilidade.

A escola precisa ensinar isso.

Não fingir que a tecnologia não existe.


Detectores de IA nem sempre acertam

Outra polêmica.

Ferramentas que afirmam detectar textos produzidos por IA.

Elas existem.

Mas nenhuma é infalível.

Diversos estudos já mostraram falsos positivos.

Textos escritos por humanos foram classificados como IA.

Textos feitos por IA passaram despercebidos.

Por isso, utilizar esses detectores como única prova de fraude é extremamente problemático.

Eles podem auxiliar.

Jamais substituir análise humana.


O futuro pertence aos profissionais híbridos

No início da computação existia resistência ao computador.

Depois veio resistência ao Excel.

Depois ao Google.

Depois ao GitHub.

Depois ao Stack Overflow.

Agora chegou a IA.

A tendência é semelhante.

Os profissionais mais valorizados não serão aqueles que recusam a tecnologia.

Nem aqueles que dependem completamente dela.

Serão aqueles que unem:

  • experiência;

  • conhecimento;

  • criatividade;

  • ética;

  • pensamento crítico;

  • Inteligência Artificial.

Essa combinação produz resultados extraordinários.


Então a IA é autora?

Na minha visão, não.

Ela não possui intenção.

Não possui consciência.

Não possui responsabilidade.

Não possui identidade.

Ela não responde judicialmente.

Não assina contratos.

Não sente orgulho da obra.

Ela produz conteúdo.

Quem transforma esse conteúdo em conhecimento útil continua sendo o ser humano.


Talvez estejamos fazendo a pergunta errada

Talvez a pergunta nunca tenha sido:

"Quem escreveu?"

Talvez a pergunta correta seja:

Quem tomou as decisões intelectuais?

Quem escolheu o tema?

Quem definiu o público?

Quem estruturou a narrativa?

Quem validou os fatos?

Quem assumiu a responsabilidade?

Quem publicou?

Quem responderá pelos erros?

Enquanto essas respostas apontarem para uma pessoa, continuará existindo autoria humana.

A IA participa do processo.

Mas participação não significa autoria.

Assim como um compilador participa do desenvolvimento de um sistema.

Assim como um editor participa da produção de um livro.

Assim como uma câmera participa da criação de uma fotografia.

Ferramentas ampliam capacidades.

Não substituem responsabilidade.


Muito Além da Inteligência Artificial

Talvez a maior transformação provocada pela IA não seja tecnológica.

Seja filosófica.

Durante séculos acreditamos que produzir texto era prova definitiva de inteligência.

Hoje uma máquina produz milhões de palavras por minuto.

Isso nos obriga a redefinir o que realmente significa ser inteligente.

Talvez inteligência nunca tenha sido apenas escrever.

Talvez criatividade nunca tenha sido apenas combinar palavras.

Talvez conhecimento nunca tenha sido apenas memorizar informações.

O verdadeiro diferencial humano continua sendo algo que nenhuma arquitetura de redes neurais demonstrou possuir: consciência, propósito, julgamento moral, empatia e responsabilidade pelas consequências de suas escolhas.

A IA é uma das ferramentas mais poderosas já criadas pela humanidade. Como toda grande ferramenta, pode ampliar o melhor e o pior de quem a utiliza. Nas mãos de alguém desonesto, facilita fraudes. Nas mãos de um estudante preguiçoso, reduz o aprendizado. Nas mãos de um profissional ético, acelera descobertas, democratiza conhecimento, elimina tarefas repetitivas e libera tempo para aquilo que realmente importa: pensar.

Portanto, talvez devêssemos abandonar a pergunta "A IA substitui o ser humano?" e adotar outra muito mais útil:

"Como posso usar a IA para me tornar um profissional melhor, mais criativo, mais produtivo e mais responsável?"

Essa, sim, é a pergunta que definirá os vencedores desta nova era.

Porque, no fim das contas, a Inteligência Artificial não diminui o valor da inteligência humana.

Ela apenas torna ainda mais evidente onde ela realmente está.

Se desejar, posso adaptar este texto para o formato tradicional da série "Um Café no Bellacosa Mainframe", com referências a IBM Z, COBOL, compiladores, DevOps, Git, revisão por pares, casos reais do mercado e um tom ainda mais reflexivo, chegando a cerca de 2.500–3.000 palavras.

sexta-feira, 5 de junho de 2026

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

 

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. ☕🚀💣


quarta-feira, 20 de maio de 2026

SKILL.md : O JCL da Inteligência Artificial?




☕ Um Café no Bellacosa Mainframe

SKILL.md

O JCL da Inteligência Artificial?

Como transformar prompts descartáveis em componentes reutilizáveis de IA

"Programadores COBOL nunca escreveram comandos repetidos quando podiam criar uma PROC. O SKILL.md segue exatamente essa filosofia."


O problema do Prompt Engineering

Hoje a maioria das pessoas trabalha assim:

Abre ChatGPT

↓

Escreve um prompt enorme

↓

Recebe resposta

↓

Fecha

↓

No dia seguinte...

Escreve tudo novamente

É praticamente isso.

Imagine um DBA que toda manhã tivesse que escrever novamente o JCL inteiro para executar o RUNSTATS.

Ninguém faria isso.

Criaria uma PROC.

Ou um CLIST.

Ou um REXX.

Ou um Script.

Ou um Pipeline.

Então por que fazemos isso com IA?


O nascimento do SKILL.md

A ideia do SKILL.md é simples.

Em vez de guardar conhecimento na cabeça...

...guardamos conhecimento em arquivos.

Esses arquivos descrevem exatamente:

  • quando executar

  • como executar

  • quais regras seguir

  • quais ferramentas usar

  • qual formato devolver

Ou seja...

não é um prompt.

É um módulo.


Pense como um programador COBOL

No COBOL existe:

COPYBOOK

Você escreve uma vez.

Depois reutiliza em centenas de programas.

O SKILL.md é praticamente o COPYBOOK da IA.


Outro exemplo.

No z/OS temos

PROC JCL

Em vez de copiar:

IEFBR14

DISP

SPACE

DCB

...

criamos

PROC

e chamamos:

//STEP EXEC PROC=BACKUP

O SKILL.md faz exatamente isso.


Em vez de escrever

Analise este código COBOL...

gere documentação...

explique...

crie testes...

faça HTML...

gere JSON...

você apenas chama

/documentar-cobol

E pronto.


O que realmente existe dentro de um SKILL.md?

A imagem resume isso muito bem.

Vamos aprofundar.


1 Nome

name:

É o identificador.

Exemplo

documentar-cobol

ou

analisar-jcl

ou

explicar-vsam

2 Description

Essa talvez seja a parte mais importante.

Ela não serve apenas para humanos.

Serve para a IA descobrir:

"quando devo usar este Skill?"

Exemplo.

Sempre que o usuário enviar um programa COBOL
e pedir documentação.

Observe.

Não é um prompt.

É um gatilho.


3 Instructions

Aqui mora o cérebro.

Exemplo.

1 Leia o código

2 Identifique variáveis

3 Gere fluxograma

4 Explique SQL

5 Explique CICS

6 Gere documentação

7 Gere Markdown

É praticamente um algoritmo.


4 Constraints

Muito importante.

Exemplo.

Nunca invente campos

Nunca altere lógica

Explique apenas o que existe

Sempre preserve comentários

Sem restrições...

a IA improvisa.

Com restrições...

ela fica previsível.


5 Output

Como devolver.

Exemplo.

Markdown

JSON

HTML

Tabela

Mermaid

Ascii Art

PlantUML

Isso elimina enorme parte da inconsistência.


Progressive Disclosure

Essa parte da imagem é excelente.

Ela mostra algo pouco conhecido.

A IA não precisa carregar tudo imediatamente.

Ela faz:

Stage 1

↓

Carrega apenas metadados

Depois

Stage 2

↓

Carrega instruções completas

Depois

Stage 3

↓

Busca scripts externos

Isso reduz consumo de contexto.

É parecido com paginação de memória.

Ou até mesmo:

Demand Paging

no z/OS.

Só carrega quando precisa.


Anatomia

A imagem resume assim:

name

description

instructions

Mas, na prática, um bom Skill costuma ter também:

Examples

References

Templates

Output

Validation

Error Handling

Scripts

Assets

Ou seja...

é quase um pequeno projeto.


Estrutura de diretórios

A imagem mostra algo como

.claude/

skills/

review-pr/

Dentro temos

SKILL.md

scripts/

references/

assets/

Isso é fantástico.

Porque aproxima IA da engenharia de software.

Não existe mais um prompt perdido.

Existe um componente organizado.


Um exemplo para Mainframe

Imagine:

skills/

analisar-cobol/

SKILL.md

copybooks/

templates/

scripts/

Dentro do Skill:

Receba um programa COBOL.

Explique:

Data Division

Working Storage

Linkage

File Section

Procedure Division

CICS

SQL

VSAM

Performance

Sugestões

Checklist

Fluxograma

Sempre igual.

Sempre consistente.


Outro exemplo

Imagine um Skill chamado

JCL Review

Quando alguém envia

//STEP01 EXEC PGM=IDCAMS

automaticamente a IA faz:

✔ verifica DISP

✔ verifica SPACE

✔ verifica UNIT

✔ verifica DCB

✔ verifica GDG

✔ verifica retorno

✔ identifica problemas

✔ sugere melhorias

Sem escrever prompt algum.


Outro exemplo

RACF Auditor

Entrada

Comandos RACF

Saída

Riscos

Boas práticas

Least Privilege

Violação

Explicação

Checklist

Normas IBM

Outro exemplo

Explicar Dump S0C7

Sempre devolvendo

Causa

Registro PSW

Offset

Hex

Instrução COBOL

Correção

Exemplo

Por que isso escala?

Porque agora existe padronização.

Imagine uma empresa.

Hoje.

100 desenvolvedores.

Cada um escreve prompts diferentes.

Resultados diferentes.

Qualidade diferente.

Agora imagine.

Todos usam

review-api

review-cobol

review-java

security

documentation

A empresa inteira produz praticamente no mesmo padrão.


Isso lembra muito...

Quem trabalha em Mainframe provavelmente percebeu.

SKILL.md lembra vários conceitos clássicos:

MainframeMundo IA
PROCSkill
COPYBOOKSkill compartilhado
CLISTSkill
REXXSkill com lógica
ISPF PanelInterface para Skill
JCL ProcedureReutilização
PARMLIBConfiguração
EXITPersonalização
Macro AssemblerTemplate reutilizável

Na verdade...

a filosofia é praticamente a mesma.


Skills × Config × MCP

A imagem também mostra essa diferença.

Skills

São capacidades.

Gerar documentação

Revisar código

Criar testes

Explicar erros

Converter formatos

São executadas sob demanda.


Configs

São comportamentos permanentes.

Exemplo.

Sempre responda em português.

Sempre seja objetivo.

Nunca gere código inseguro.

É equivalente às configurações globais do ambiente.


MCP

É outra camada completamente diferente.

MCP conecta IA a recursos externos.

Por exemplo:

GitHub

Jira

Confluence

PostgreSQL

Oracle

VSCode

Filesystem

AWS

IBM APIs

Enquanto um Skill ensina como pensar, o MCP fornece acesso ao mundo externo.


O futuro: IA Programável

A mensagem mais importante da imagem é esta:

"The shift is happening towards programmable AI systems."

Esse é realmente o movimento que está ganhando força.

A evolução pode ser vista em quatro fases:

2023

Prompt Engineering

2024

Prompt Libraries

2025

AI Agents

2026+

Skills

MCP

Workflows

Memory

Ferramentas

Automação

Cada etapa reduz trabalho manual e aumenta a reutilização e a previsibilidade.


Como isso se aplica ao Bellacosa Mainframe

Esse conceito combina muito com o projeto Bellacosa Mainframe. Em vez de criar prompts longos para cada artigo ou análise, você pode construir uma biblioteca de Skills especializadas, por exemplo:

  • Artigo Bellacosa — gera artigos longos no seu estilo, com curiosidades, história, exemplos, SEO, FAQ e chamadas para ação.

  • Review COBOL — analisa código COBOL com foco em bancos brasileiros, boas práticas, legibilidade e performance.

  • Analisador JCL — valida DISP, SPACE, GDG, retornos, organização dos DDs e oportunidades de melhoria.

  • Explicador CICS — detalha COMMAREA, Channels/Containers, TSQ/TDQ, RESP/RESP2, BMS e tratamento de erros.

  • Gerador de Quiz — cria avaliações com diferentes níveis de dificuldade e gabarito comentado.

  • Criador de Laboratórios — produz exercícios práticos para Hercules, ADCD e ambientes IBM Z.

  • SEO Blogspot — gera meta description, marcadores, slug e estrutura otimizada para mecanismos de busca.

Cada Skill seria reutilizada inúmeras vezes, garantindo consistência em todos os seus conteúdos.


Conclusão

O SKILL.md representa uma mudança importante na forma de trabalhar com IA. O foco deixa de ser escrever prompts elaborados para cada interação e passa a ser a criação de componentes reutilizáveis, documentados e padronizados, muito semelhantes aos princípios que profissionais de mainframe já utilizam há décadas com COPYBOOKs, PROCs, CLISTs, REXX e módulos reutilizáveis.

No fim das contas, a lógica é familiar para qualquer desenvolvedor experiente:

Não copie conhecimento. Encapsule-o. Não repita instruções. Reutilize-as. Não trate a IA como uma calculadora. Trate-a como uma plataforma programável.

Essa mudança aproxima a Inteligência Artificial das boas práticas de engenharia de software e tende a tornar seu uso mais confiável, escalável e sustentável em ambientes corporativos — exatamente como aconteceu com a evolução do desenvolvimento no mundo IBM Z ao longo das últimas décadas.

domingo, 12 de abril de 2026

💥 SEU COBOL NÃO É LEGADO — É OURO AUTOMATIZÁVEL: Como o IBM RPA Transforma Mainframe em Máquina de Produtividade

 

Bellacosa Mainframe introduz o IBM RPA

💥 SEU COBOL NÃO É LEGADO — É OURO AUTOMATIZÁVEL: Como o IBM RPA Transforma Mainframe em Máquina de Produtividade

Se você é um dev COBOL raiz, daqueles que já domou JCL, sobreviveu a dumps indecifráveis e conversa com o CICS como quem pede café… então segura essa: RPA não é modinha de mercado — é multiplicador de mainframe.

E quando falamos de RPA corporativo de verdade, estamos falando de IBM — que resolveu levar automação além da superfície e conectar com o coração do legado: o seu COBOL.


🧠 O que é IBM RPA (sem papo de vendedor)

O IBM Robotic Process Automation (RPA) é uma plataforma que cria “robôs de software” capazes de:

  • Simular ações humanas (digitar, clicar, navegar)
  • Integrar sistemas que nunca foram pensados para conversar
  • Automatizar processos repetitivos
  • Orquestrar fluxos complexos (inclusive com IA)

👉 Em linguagem de mainframe:

É como ter um operador batch + usuário TSO + integrador MQ + analista funcional… tudo em um script automatizado.


🕰️ Origem e evolução (sim, isso tem história)

Antes de virar hype:

  • Anos 70–90: Automação já existia… via JCL, CLIST, REXX
  • Anos 2000: Scripts de automação GUI começam a aparecer
  • Pós-2015: Surge o conceito moderno de RPA
  • IBM entra no jogo e evolui para algo corporativo, robusto e integrável com:
    • z/OS
    • APIs REST
    • IA (Watson)

💡 Ou seja:

O RPA moderno é o “REXX com esteróides + interface gráfica + IA”


🔥 Por que isso importa para quem vive no COBOL?

Porque o problema nunca foi o COBOL.

O problema é:

  • Integração com sistemas modernos
  • Processos manuais
  • Interfaces antigas (green screen, alguém? 😏)
  • Dependência humana para tarefas repetitivas

👉 O RPA resolve isso SEM reescrever seu sistema.


💡 Caso real (estilo Bellacosa)

🎯 Cenário

Sistema COBOL no CICS que:

  • Consulta saldo
  • Atualiza registros VSAM
  • Não tem API
  • Só acessível via terminal 3270

😵 Problema

Um time precisa consultar 5.000 registros/dia manualmente


🤖 Solução com IBM RPA

O robô:

  1. Abre emulador 3270
  2. Loga no sistema
  3. Navega pelas telas
  4. Executa transações CICS
  5. Captura dados
  6. Exporta para CSV / envia via API

🧾 Resultado

AntesDepois
6 horas humanas15 minutos
Erros manuaisZero
Stress operacionalEliminado

💥 E o melhor:

Nenhuma linha de COBOL alterada


⚙️ Como funciona por dentro (visão técnica)

O IBM RPA tem três pilares:

1. 🧩 Designer

  • Interface visual (drag & drop)
  • Criação de bots
  • Integração com scripts

2. 🤖 Bots

  • Executam tarefas
  • Podem ser:
    • Attended (com usuário)
    • Unattended (totalmente automáticos)

3. 🎛️ Control Center

  • Orquestra execução
  • Agenda jobs
  • Monitora performance

👉 Sim, é tipo um JES2 moderno… só que para automação 😄


🛠️ Exemplo prático (pseudo fluxo)

START BOT
|
|-- Launch Terminal 3270
|-- Send Keys: USER/PASSWORD
|-- Navigate: CICS TXN ABCD
|-- Read Screen Field
|-- Store Data
|-- Loop Records
|-- Export CSV
|
END BOT

💡 Para um coboleiro:

Isso é basicamente um PERFORM UNTIL… com tela verde no meio


🧪 Easter Eggs que poucos sabem

🔥 1. RPA + MQ = integração invisível
Você pode acionar bots via filas MQ → automação baseada em eventos

🔥 2. RPA pode chamar APIs REST e depois alimentar COBOL
Bridge perfeita entre cloud e z/OS

🔥 3. Pode automatizar ISPF
Sim… ISPF. Aquela telinha azul dos anos 80 😄

🔥 4. Substitui scripts Frankenstein
Adeus .bat + macro Excel + script Python + reza


🧠 Curiosidades que mudam o jogo

  • RPA NÃO é só front-end → pode orquestrar backend
  • RPA NÃO substitui COBOL → potencializa COBOL
  • RPA NÃO é só “clicador” → pode tomar decisões com IA

⚠️ Onde tomar cuidado

RPA NÃO é bala de prata.

Evite usar quando:

  • Existe API bem definida → use integração direta
  • Processo é instável → bot quebra fácil
  • Tela muda frequentemente → manutenção alta

👉 Regra de ouro:

Use RPA para estabilizar o legado, não para mascarar caos


🚀 Passo a passo para começar (mentalidade mainframe)

1. Identifique processos repetitivos

  • Batch manual?
  • Consulta operacional?
  • Input humano?

2. Escolha um “quick win”

  • Algo pequeno, mas visível

3. Modele o fluxo

  • Pense como um JCL + COBOL

4. Crie o bot no IBM RPA

5. Teste como se fosse produção

  • Simule erro
  • Timeout
  • Input inválido

6. Coloque sob controle (governança!)

  • Logs
  • Monitoramento
  • Auditoria

🔥 Insight final (pra fechar com impacto)

Você não precisa modernizar o mainframe jogando ele fora.

Você moderniza quando:

  • Conecta
  • Automatiza
  • Orquestra

E o IBM RPA faz exatamente isso:

Ele não substitui o COBOL…
Ele transforma seu COBOL em uma API viva — mesmo sem API.


☕ Conclusão no estilo Bellacosa

Se o JCL foi o maestro do batch…
Se o CICS foi o rei do online…

Então o RPA é:

💥 O operador invisível que nunca erra, nunca cansa e nunca pede férias

domingo, 28 de setembro de 2025

A Escravidão do WhatsApp : Quando um Programador Descobre que o Expediente Terminou às 18h... Mas o Grupo da Empresa Continua Executando em LOOP Até a Morte Térmica do Universo

Bellacosa Mainframe e a escravidão secreta do whatsapps

☕ Um Café no Bellacosa Mainframe

A Escravidão do WhatsApp sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o Expediente Terminou às 18h... Mas o Grupo da Empresa Continua Executando em LOOP Até a Morte Térmica do Universo

Houve uma época, jovem padawan do COBOL, em que o telefone tocava e isso significava alguma coisa.

Talvez alguém tivesse morrido.

Talvez sua tia estivesse chegando de Campinas.

Talvez o banco estivesse oferecendo um empréstimo que você não pediu.

Ou talvez um amigo quisesse conversar durante quinze minutos, preferencialmente depois das oito da noite, quando o impulso telefônico custava menos e a humanidade ainda possuía algo chamado paciência.

Sim, o impulso telefônico.

Uma unidade econômica ancestral que ensinava disciplina, objetividade e respeito ao orçamento doméstico.

Você não ligava para alguém para dizer:

— Oi.

Esperar cinco minutos.

— Tudo bem?

Esperar mais três.

— Então...

Não.

Você ligava com um plano.

O telefonema tinha início, meio, fim e, em casos mais sofisticados, despedida.

— Está certo, então. Um abraço para todos. Até mais.

E desligava.

O evento terminava.

Nenhuma bolinha permanecia vermelha.

Nenhum ícone continuava pulsando.

Nenhuma pessoa interpretava seu silêncio como uma declaração diplomática de guerra.

A vida seguia.

O cidadão saía de casa, trabalhava, tomava café, respondia alguns e-mails, voltava para casa, assistia televisão e, em algum momento da noite, usava o telefone para falar com uma ou duas pessoas.

Essa era a arquitetura.

Simples.

Estável.

Monolítica.

Talvez não fosse elegante, mas funcionava.

Era como um programa COBOL de 1978 processando a folha de pagamento de um país inteiro: ninguém sabia exatamente por que ainda estava funcionando, mas todos tinham medo suficiente para não mexer.

Então vieram os comunicadores instantâneos.

E a humanidade, demonstrando mais uma vez sua notável capacidade de transformar qualquer ferramenta útil em um instrumento de sofrimento coletivo, decidiu que “instantâneo” não significava apenas que a mensagem poderia chegar imediatamente.

Passou a significar que a resposta também deveria chegar imediatamente.

E assim nasceu o maior sistema de tempo real já implantado sem documentação, governança, SLA, planejamento de capacidade ou autorização do usuário:

o WhatsApp.


1. O telefone antigo era batch

Para um programador COBOL iniciante, a comparação mais fácil é esta:

o telefone antigo funcionava como processamento batch.

Você acumulava assuntos durante o dia.

À noite, executava o job.

O processamento começava.

As informações eram trocadas.

O job terminava.

Você verificava o retorno.

Se tudo desse certo:

MAXCC = 0000

Se a conversa fosse com um parente complicado:

MAXCC = 0004

Se envolvesse dinheiro, herança ou política:

ABEND S0C7

Mesmo assim, o sistema possuía janela operacional.

Ninguém esperava que o batch executasse a cada sete segundos.

Ninguém enviava uma nova fita magnética enquanto a anterior ainda estava sendo lida.

Ninguém ligava novamente três minutos depois perguntando:

— Você viu minha ligação?

Hoje, o WhatsApp opera como um CICS enlouquecido, recebendo transações sem limite de MXT, sem fila de prioridade e sem qualquer respeito pelo fato de que o operador foi embora.

A transação chega.

Depois outra.

Depois um áudio de quatro minutos.

Depois uma figurinha.

Depois alguém escreve:

— Bom dia, pessoal.

E quarenta e três pessoas respondem:

— Bom dia.

Nesse momento, um data center inteiro poderia ter sido desligado sem causar tanto tráfego inútil.


2. O silêncio deixou de ser neutro

Antigamente, o silêncio era apenas silêncio.

Você não ligou para alguém durante dois dias?

Normal.

A pessoa estava vivendo.

Talvez trabalhando.

Talvez dormindo.

Talvez simplesmente sem assunto.

Hoje, o silêncio foi reclassificado como incidente.

A mensagem foi enviada.

Entregue.

Visualizada.

Nenhuma resposta.

Imediatamente, o sistema emocional abre um chamado de alta prioridade:

INCIDENTE: USUÁRIO NÃO RESPONDEU
SEVERIDADE: CRÍTICA
IMPACTO: EGO DO REMETENTE
CAUSA PROVÁVEL: DESPREZO

Não importa que o destinatário esteja dirigindo, cozinhando, cuidando de alguém, descansando, lendo, trabalhando ou contemplando o vazio existencial.

Ele visualizou.

Logo, na lógica contemporânea, ele assumiu um compromisso contratual com o remetente.

É como se o simples recebimento de uma mensagem criasse uma tarefa.

Essa é uma mudança profunda.

Receber não deveria significar estar disponível.

Visualizar não deveria significar aceitar.

E demorar para responder não deveria ser interpretado como hostilidade.

Mas o aplicativo introduziu indicadores comportamentais que transformaram a comunicação em vigilância social.

“Online.”

“Visto por último.”

“Digitando.”

“Gravando áudio.”

Pouco a pouco, deixamos de conversar e começamos a monitorar estados de sessão.

É quase um SDSF das relações humanas.

Você não fala mais com a pessoa.

Você consulta o status do job.

USER123  ACTIVE
USER123  TYPING
USER123  LAST SEEN 22:47
USER123  DID NOT REPLY

O próximo passo lógico será exibir consumo de CPU, nível de paciência e percentual de vontade de fugir para as montanhas.


3. O grupo corporativo que nunca termina

Agora chegamos ao coração sombrio do problema.

O grupo do trabalho.

Essa entidade digital que começa inocentemente.

— Vamos criar um grupo apenas para assuntos importantes.

Essa frase deveria ser gravada em pedra ao lado de outras grandes mentiras da humanidade:

— O cheque está no correio.

— Será uma reunião rápida.

— O sistema estará pronto até sexta-feira.

— Não haverá impacto em produção.

O grupo “apenas para assuntos importantes” rapidamente se transforma em um ecossistema completo.

Avisos.

Pedidos.

Cobranças.

Fotos.

Planilhas.

Áudios.

Reflexões estratégicas às 22h13.

Mensagens de “boa noite” que contêm trabalho disfarçado.

— Boa noite, pessoal. Amanhã precisamos pensar melhor naquele problema do relatório.

Observe a engenharia.

A mensagem parece inocente.

Não exige resposta.

Mas implanta um processo residente na memória do trabalhador.

Agora ele vai tomar banho pensando no relatório.

Vai jantar pensando no relatório.

Vai deitar pensando no relatório.

A empresa não pediu oficialmente uma atividade.

Apenas instalou um job em background na mente do funcionário.

Sem remuneração.

Sem log.

Sem contabilização.

Sem janela de manutenção.

É a terceirização perfeita do processamento cognitivo.

A empresa economiza CPU.

Usa a sua.


4. Bater o ponto não encerra mais a sessão

No passado, bater o ponto era uma instrução objetiva.

END-OF-JOB.
    STOP RUN.

Você saía.

O trabalho ficava no prédio.

Naturalmente, cargos de confiança, plantões e funções específicas podiam exigir disponibilidade.

Mas isso era tratado como exceção.

A empresa fornecia meios.

Celular corporativo.

Pager.

Rádio.

Nextel.

Chip.

Fatura.

Escala.

Adicional.

Compensação.

Algum tipo de reconhecimento de que estar disponível fora do horário era uma condição especial.

Hoje, essa condição foi silenciosamente empurrada para todos.

Seu telefone virou extensão da empresa.

Seu chip virou ativo corporativo informal.

Sua internet residencial virou link redundante.

Sua bateria virou fonte de energia de emergência.

Seu plano de dados virou despesa operacional não reembolsada.

Seu número pessoal foi incorporado à infraestrutura sem assinatura de contrato, inventário patrimonial ou aprovação do setor de segurança.

Se isso acontecesse com um servidor, alguém abriria auditoria.

Mas como acontece com o trabalhador, chamam de “colaboração”.


5. O expediente invisível

Há uma ideia equivocada de que você só trabalha quando está digitando.

Isso é falso.

Ler uma mensagem profissional pode iniciar uma sequência de processamento mental.

Você recebe:

— Amanhã vamos precisar rever o fluxo do fechamento mensal.

Pronto.

O cérebro começa.

Quem participa?

Qual é o problema?

Será que houve erro?

Tenho que preparar alguma coisa?

Aquilo que fiz ontem estava correto?

Será que vão mudar o processo?

Existe risco de cobrança?

Em segundos, você está trabalhando.

Não está sendo produtivo para si mesmo.

Não está descansando.

Não está livre.

Está executando uma análise não remunerada.

Esse fenômeno pode ser entendido como resíduo cognitivo.

Parte da atenção permanece presa à tarefa mesmo quando você tenta fazer outra coisa.

No universo mainframe, seria como um job que encerrou formalmente, mas deixou recursos alocados.

DATASET IN USE
RESOURCE STILL HELD
UNABLE TO RELEASE

Você está em casa, mas uma parte da mente continua no escritório.

A televisão está ligada.

A comida está na mesa.

A família está falando.

E dentro da cabeça existe um pequeno gerente segurando uma prancheta:

— Precisamos refletir sobre aquela mensagem.

Esse gerente nunca dorme.

Não recebe salário.

E, aparentemente, mora no seu córtex pré-frontal sem pagar aluguel.


6. A obrigação não escrita

O aspecto mais perverso é que muitas vezes ninguém diz explicitamente:

— Você deve responder fora do horário.

A obrigação funciona de modo indireto.

Alguns respondem.

Então outros sentem que também devem responder.

Um coordenador manda algo às 21h.

Um funcionário responde às 21h02.

Outro às 21h04.

Em dez minutos, foi criado um novo padrão organizacional.

Não houve reunião.

Não houve votação.

Não houve comunicado oficial.

Mas agora todos sabem que o grupo continua “vivo”.

Quem não responde teme parecer descomprometido.

Quem responde reforça o sistema.

É um loop social.

PERFORM UNTIL EXAUSTAO = 'SIM'
    READ WHATSAPP
    RESPOND WHATSAPP
    FEEL RESENTMENT
    PRETEND ENTHUSIASM
END-PERFORM

O problema é que a condição de saída raramente é atingida.

Porque até quando a pessoa está exausta, continua escrevendo:

— Perfeito! Vamos alinhar amanhã!

Em linguagem corporativa, o ponto de exclamação é frequentemente usado para esconder sofrimento.


7. A empresa economizou e chamou isso de modernização

Existe uma ironia extraordinária.

Quando a empresa fornecia o aparelho, o chip e a fatura, reconhecia-se que havia uma fronteira.

Este aparelho é corporativo.

Este canal é corporativo.

Este custo é corporativo.

Hoje, muitas organizações usam o dispositivo pessoal do funcionário sem cerimônia.

Não pedem formalmente.

Apenas criam o grupo.

Depois, pouco a pouco, o grupo vira parte essencial da operação.

Convocações.

Escalas.

Mudanças.

Informações urgentes.

Orientações.

Documentos.

Até dados potencialmente sensíveis.

O trabalhador passa a ser responsável por manter aquele canal funcionando.

Se troca de número, precisa avisar.

Se perde o aparelho, preocupa-se com o grupo.

Se fica sem internet, sente culpa.

Se silencia as notificações, teme perder algo importante.

A empresa conseguiu implantar BYOD — Bring Your Own Device — sem política, sem suporte, sem governança e sem talvez sequer saber o significado da sigla.

É uma arquitetura admirável.

Do ponto de vista financeiro.

Do ponto de vista humano, assemelha-se a pedir que cada funcionário leve sua própria cadeira, lâmpada e extintor de incêndio.


8. Família e amigos também abriram chamados

O problema não fica restrito ao trabalho.

A família adotou o mesmo modelo.

A pessoa envia uma mensagem.

Você não responde.

Logo chega outra:

— Está tudo bem?

Depois:

— Você está bravo?

Depois:

— Sumiu.

Em alguns casos, surge um telefonema para confirmar por que a mensagem não foi respondida.

Estamos diante de uma inversão curiosa.

Antes, o telefone era usado quando algo precisava de atenção.

Agora, ele é usado para cobrar atenção sobre outra comunicação.

É o equivalente digital de abrir um chamado para perguntar por que outro chamado ainda não foi atendido.

Os amigos também participam.

Você pode passar dez anos sem encontrar alguém pessoalmente, mas se demorar três horas para responder um meme, a amizade entra em crise.

A disponibilidade virou prova de afeto.

Responder rápido significa gostar.

Demorar significa desprezar.

Isso é injusto porque mistura carinho com prontidão operacional.

Uma pessoa pode amar profundamente seus amigos e ainda assim não querer monitorar o telefone a cada cinco minutos.

Aliás, talvez justamente por gostar deles, prefira conversar quando estiver realmente presente, e não respondendo com uma mão enquanto limpa a cozinha com a outra.


9. O cérebro não foi projetado para tantas interrupções

O cérebro humano consegue alternar tarefas, mas paga um preço.

Cada interrupção exige reconstruir contexto.

Você está concentrado em uma planilha.

Chega mensagem.

Você lê.

Volta para a planilha.

Precisa lembrar onde estava.

Chega outra.

Você responde.

Volta.

Esquece qual era a lógica.

Esse custo parece pequeno.

Mas repetido dezenas de vezes, destrói a qualidade do trabalho.

Para um programador COBOL, isso é particularmente perigoso.

Imagine analisar um programa com:

  • sete níveis de PERFORM;

  • arquivos VSAM;

  • CALL dinâmico;

  • indicadores;

  • copybooks;

  • SQL embutido;

  • tratamento de erro criado em 1989;

  • comentários escritos por alguém identificado apenas como “JMS”.

Você finalmente entende que a rotina CALCULA-TAXA-PROMOCIONAL chama VALIDAR-CLIENTE, que altera um indicador usado mais tarde no fechamento.

Nesse exato instante:

PLIM!

Mensagem no grupo:

— Alguém sabe quem ficou com a caneca da sala 3?

O contexto mental desaparece.

O programador olha para o código.

O código olha para o programador.

Nenhum dos dois sabe mais o que está acontecendo.

Em algum lugar distante, um arquivo é atualizado incorretamente.


10. O FOMO corporativo

FOMO significa medo de ficar de fora.

No ambiente pessoal, é o medo de perder uma novidade, uma conversa ou um evento.

No trabalho, surge uma versão ainda mais irritante:

o medo de perder uma decisão tomada informalmente às 22h37.

Você silencia o grupo.

Na manhã seguinte, descobre que vinte pessoas discutiram um assunto.

A decisão foi tomada.

Não houve ata.

Não houve e-mail.

Não houve reunião.

Apenas uma sequência de mensagens, áudios e reações.

Então alguém diz:

— Mas isso foi falado no grupo.

Essa frase é o novo “estava no manual”.

Só que o manual possui 18 mil mensagens, 400 figurinhas, 90 imagens, 12 áudios inaudíveis e um vídeo de aniversário.

Encontrar a decisão é como pesquisar um registro específico em uma fita sem índice.

O FOMO mantém as pessoas conectadas porque sabem que informações importantes podem aparecer no meio do lixo.

É um sistema perverso.

O canal é desorganizado.

Por isso, todos precisam monitorá-lo.

Como todos monitoram, ele continua sendo usado.

Como continua sendo usado, permanece desorganizado.

É um PERFORM VARYING baseado em sofrimento.


11. Urgente ou apenas barulhento?

Um dos grandes problemas da comunicação instantânea é que tudo parece urgente.

A notificação é igual.

A vibração é igual.

A bolinha vermelha é igual.

Pode ser:

  • um incidente crítico em produção;

  • uma foto de cachorro;

  • uma mudança de escala;

  • uma piada;

  • uma cobrança;

  • um “ok”;

  • um áudio de seis minutos;

  • alguém perguntando algo que poderia procurar sozinho.

O dispositivo não diferencia importância.

Quem deveria fazer isso é a organização.

Mas muitas empresas não possuem regras claras.

Assim, a urgência vira uma interpretação emocional.

Quem envia acredita que é urgente.

Quem recebe precisa decidir.

E, para evitar risco, acaba verificando tudo.

Em arquitetura de sistemas, isso seria considerado péssimo desenho de mensageria.

Não existe classificação.

Não existe prioridade.

Não existe roteamento.

Não existe timeout.

Não existe política de retenção.

Não existe escalonamento.

Só existe o grupo chamado:

EQUIPE OFICIAL 2026 NOVO DEFINITIVO 2

E, naturalmente, outro grupo chamado:

EQUIPE SEM A GERENCIA

Esse segundo costuma ter mais atividade e menos governança.


12. Passo a passo para recuperar sua liberdade digital

Não é necessário jogar o aparelho em um rio.

Embora, em determinados dias, a ideia pareça tecnicamente sólida.

É possível estabelecer limites graduais.

Passo 1 — Desative o que transforma comunicação em vigilância

Considere desativar:

  • confirmação de leitura;

  • visto por último;

  • status online, quando possível;

  • notificações de grupos não essenciais;

  • pré-visualização na tela bloqueada.

Isso reduz a pressão social.

Você deixa de ser uma transação monitorada em tempo real.

Passo 2 — Silencie grupos profissionais fora do expediente

Silenciar não é abandonar.

É definir janela de processamento.

Você pode verificar no início do expediente.

O grupo continuará existindo.

A civilização provavelmente também.

Caso o planeta esteja realmente em risco, espera-se que alguém utilize um canal mais adequado do que uma figurinha seguida de “urgente”.

Passo 3 — Diferencie emergência de conveniência

Uma emergência precisa de critérios.

Por exemplo:

  • incidente crítico;

  • indisponibilidade real;

  • risco imediato;

  • plantão acordado;

  • situação previamente definida.

“Lembrei agora” não é emergência.

“Quero adiantar” não é emergência.

“Estou trabalhando e gostaria que todos também estivessem” certamente não é emergência.

Passo 4 — Responda dentro do seu horário

Uma mensagem pode ser recebida às 22h e respondida às 8h30.

Isso não é grosseria.

É processamento assíncrono.

O remetente envia quando pode.

O destinatário responde quando pode.

Essa é a beleza da mensageria.

Se a resposta fosse obrigatoriamente imediata, o nome da ferramenta deveria ser “convocação”.

Passo 5 — Evite justificar demais

Você não precisa apresentar relatório técnico por não ter respondido.

Uma frase simples basta:

— Vi agora pela manhã.

Ou:

— Fora do expediente, deixo as notificações profissionais silenciadas.

Clara.

Educada.

Sem culpa.

Passo 6 — Proponha canais corretos

Assuntos formais deveriam estar em canais rastreáveis.

E-mail.

Sistema de chamados.

Ferramenta corporativa.

Ata.

Documento.

O WhatsApp pode apoiar, mas não deveria ser o único repositório de decisões importantes.

Se algo impacta processo, prazo, responsabilidade ou produção, deve existir registro adequado.

Passo 7 — Não alimente o monstro

Se você responde sempre imediatamente, mesmo quando não precisa, ajuda a criar a expectativa.

Isso não significa ignorar pessoas de propósito.

Significa não ensinar ao sistema que você está disponível em tempo integral.

O comportamento coletivo nasce da repetição individual.


13. Como explicar isso sem parecer um eremita hostil

Você pode dizer:

— Durante o expediente acompanho normalmente. Fora dele, deixo o grupo silenciado e vejo as mensagens no dia seguinte, salvo plantão ou urgência combinada.

Essa frase é profissional.

Não acusa.

Não agride.

Não precisa de discurso revolucionário.

Naturalmente, dentro da sua cabeça você pode imaginar uma marcha militar, a queda do Império das Notificações e um batalhão de programadores COBOL libertando seus chips pessoais.

Mas verbalmente, mantenha a simplicidade.


14. Curiosidades da arqueologia comunicacional

Antes do WhatsApp, outras tecnologias também geraram ansiedade.

O pager permitia localizar alguém.

O Nextel criou comunicação instantânea por rádio.

O BlackBerry tornou o e-mail portátil.

Aliás, o BlackBerry recebeu o apelido de “CrackBerry”, uma referência ao comportamento compulsivo de verificar mensagens.

Ou seja, a humanidade já estava avisada.

Mas decidiu prosseguir.

Outra curiosidade é que os indicadores de leitura parecem inofensivos, mas mudam o contrato social.

Antes, o remetente sabia apenas que enviou.

Agora, acredita saber que o outro recebeu, leu, compreendeu, avaliou e decidiu não responder.

Na verdade, “visualizado” prova apenas que a mensagem apareceu na tela.

Nada mais.

Talvez a pessoa tenha aberto por acidente.

Talvez tenha sido interrompida.

Talvez tenha lido sem condições de formular resposta.

Talvez tenha concluído, com sabedoria, que a mensagem não exigia resposta.

Ou talvez tenha visto o áudio de nove minutos e decidido emigrar.


15. O áudio: a fita magnética do caos moderno

O áudio de WhatsApp merece capítulo próprio.

Quem envia economiza tempo.

Quem recebe paga a conta.

Uma pessoa grava sete minutos de pensamento não estruturado.

Você precisa ouvir tudo para descobrir, no minuto seis e quarenta, que a pergunta era:

— Você tem o arquivo?

Isso é transferência assimétrica de esforço.

É como alguém entregar uma fita magnética inteira e dizer:

— O registro importante está em algum lugar aí.

Áudios podem ser úteis.

Mas devem ter contexto.

— Vou mandar um áudio de um minuto explicando o erro.

Perfeito.

Já o áudio que começa com:

— Então... deixa eu lembrar...

deveria disparar automaticamente uma rotina de compressão, transcrição ou intervenção da ONU.


16. O easter egg escondido no grupo

Todo grupo corporativo possui personagens.

O Bom-Dia Recursivo

Envia “bom dia” diariamente.

Mesmo em feriados.

Mesmo quando ninguém responde.

Provavelmente é um job agendado no Control-M.

O Urgente Permanente

Tudo é urgente.

Se tudo é urgente, nada é urgente.

Mas ninguém teve coragem de contar.

O Filósofo das 23h

Envia reflexões estratégicas tarde da noite.

Normalmente começa com:

— Pessoal, estive pensando...

Essa frase é o prenúncio de sofrimento.

O Respondedor Instantâneo

Responde em oito segundos.

Não importa o horário.

Pode estar em casamento, funeral ou mergulho submarino.

Ele responderá:

— Ok.

É ele quem, sem intenção, estabelece o SLA informal de disponibilidade.

O Fantasma

Nunca fala.

Mas lê tudo.

Um dia, depois de três anos, envia:

— Concordo.

Ninguém sabe com o quê.

O Encaminhador Supremo

Encaminha mensagens de outros grupos.

Sem contexto.

Sem explicação.

Sem misericórdia.

O Arqueólogo

Responde hoje a uma mensagem de onze dias atrás.

Todos já haviam esquecido o assunto.

Ele desenterra.

O incidente retorna à vida.


17. A verdadeira modernidade seria respeitar limites

Existe uma ideia equivocada de que estar sempre disponível é sinal de modernidade.

Não é.

Modernidade real exige organização.

Prioridade.

Processos.

Responsabilidade.

Respeito ao descanso.

Uma empresa madura não depende de trabalhadores monitorando grupos pessoais durante toda a noite.

Uma equipe madura sabe distinguir urgência de conveniência.

Uma liderança madura não mede comprometimento por velocidade de resposta fora do expediente.

E uma relação pessoal madura entende que afeto não é SLA.

Você não ama menos alguém porque respondeu quatro horas depois.

Você não é menos profissional porque não lê mensagens no jantar.

Você não é irresponsável por proteger a própria atenção.

O direito de estar indisponível não é preguiça.

É manutenção preventiva.

Todo sistema precisa de janela de descanso.

Até o mainframe possui manutenção.

Até banco de dados faz checkpoint.

Até fila tem limite.

Mas o trabalhador moderno é tratado como se fosse um serviço crítico ativo-ativo, distribuído em múltiplas regiões e incapaz de falhar.


Conclusão — STOP RUN ainda existe

Você não está errado por se incomodar.

O incômodo é um sinal de que uma fronteira foi ultrapassada.

A tecnologia deveria servir à vida.

Não transformar cada pessoa em central de atendimento 24x7.

O WhatsApp não é maligno.

Ele é apenas uma ferramenta extremamente eficiente operando dentro de uma cultura que perdeu a noção de limite.

O problema não é a mensagem chegar.

O problema é a expectativa de que você suspenda o que está fazendo, mude de contexto, pense, responda e permaneça emocionalmente disponível para qualquer pessoa, a qualquer hora, usando um aparelho que você comprou, um chip que você paga e uma atenção que ninguém devolve.

Talvez devêssemos recuperar uma antiga sabedoria da era do telefone fixo:

nem toda comunicação precisa ser imediata.

Nem todo silêncio é desprezo.

Nem toda mensagem merece resposta instantânea.

Nem todo assunto profissional precisa invadir a noite.

E bater o ponto deveria significar exatamente isto:

o job terminou.

Os arquivos foram fechados.

Os recursos foram liberados.

A sessão foi encerrada.

       9000-FIM.
           DISPLAY 'EXPEDIENTE ENCERRADO'.
           DISPLAY 'MENSAGENS SERAO PROCESSADAS AMANHA'.
           STOP RUN.

Em algum grupo corporativo, alguém certamente responderá:

— Só complementando...

Mas você já terá silenciado as notificações.

E pela primeira vez em muitos anos, o programa terminará com:

MAXCC = 0000


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