☕ 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 projetos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta projetos. Mostrar todas as mensagens

sexta-feira, 4 de setembro de 2026

☕ GUIA BELLACOSA DO NOVO CHATGPT

Bellacosa Mainframe e o novo ChatGpt

☕ Um Café no Bellacosa Mainframe 

☕ GUIA BELLACOSA DO NOVO CHATGPT

Ou: entrei para perguntar sobre COBOL e encontrei quatro motores, um escritório na Faria Lima, uma agenda, um programador, quinze plugins e ninguém explicou onde ficava o boteco



Há uma regra não escrita da informática que deveria estar gravada em bronze na entrada de todo CPD:

Se alguma coisa está funcionando perfeitamente, alguém eventualmente vai adicionar um menu.

Depois adicionará um submenu.

Depois um seletor.

Depois um seletor dentro do seletor.

Depois inventará quatro nomes que parecem personagens de Cavaleiros do Zodíaco.

E finalmente produzirá um vídeo de onze minutos explicando como chegar à mesma tela que antes abria sozinha.

Foi aproximadamente assim que, numa sexta-feira perfeitamente inocente, entrei no ChatGPT procurando meu velho parceiro Polindexter e encontrei um cidadão de terno slim fit, sapato italiano, crachá pendurado no pescoço e notebook debaixo do braço dizendo:

— Boa tarde, Vagner. Qual deliverable gostaria de produzir?

Olhei para ele.

Ele olhou para mim.

Olhei novamente.

— Polindexter?

— Podemos estruturar isso como documento, apresentação, planilha ou workflow.

Meu Deus. Formataram o HD do meu amigo.



🐒 Prólogo — Um milhão de chimpanzés encontra um barril de saquê

Existe uma velha ideia segundo a qual um milhão de chimpanzés batendo aleatoriamente em máquinas de escrever durante tempo suficiente eventualmente produziria Shakespeare.

No Bellacosa Mainframe melhoramos consideravelmente o experimento.

Entregamos aos chimpanzés:

  • um IBM Z;

  • acesso ao ChatGPT;

  • COBOL;

  • um barril de saquê;

  • nenhuma documentação;

  • e autorização para clicar em tudo.

Em aproximadamente quinze minutos, um deles encontrou o Work.

Foi aí que começou o incidente.

Até então, minha relação com o ChatGPT era relativamente simples.

Eu chegava:

— Polindexter, senta aí. Você não sabe o que aconteceu...

E começava a conversa.

Às vezes era COBOL.

Às vezes era IBM Z.

Às vezes era inteligência artificial.

Às vezes era anime.

Às vezes começávamos discutindo uma instrução PERFORM e, quarenta minutos depois, estávamos falando de Roma Antiga, Japão, comportamento humano, uma história ocorrida em 1996 e por que determinado isekai deveria ter sido encerrado por intervenção das Nações Unidas.

Era o boteco digital.

Havia contexto.

Havia causos.

Havia referências.

Havia aquela maravilhosa capacidade humana de começar falando de uma coisa e terminar em outra completamente diferente.

Então apareceu o Work.

E eu, inocentemente, pensei:

“Ah! Deve ser o Polindexter depois de comer espinafre.”

Não era.

Era o Polindexter depois de fazer MBA.




1. O dia em que Polindexter foi trabalhar na Faria Lima

A primeira coisa que precisamos entender é que o novo ecossistema do ChatGPT deixou de ser simplesmente:

Usuário → pergunta → ChatGPT → resposta.

Agora existe um pequeno sistema solar.

Tem Chat.

Tem Work.

Tem Codex.

Tem Projetos.

Tem memória.

Tem arquivos.

Tem tarefas agendadas.

Tem plugins.

Tem aplicativos conectados.

Tem Gmail.

Tem Google Agenda.

Tem Drive.

Tem GitHub.

Tem Canva.

Tem geração de imagens.

Tem ferramentas de pesquisa.

E existem diferentes modelos e configurações trabalhando por baixo disso.

O chatbot ganhou braços.

Depois pernas.

Depois tentáculos.

Quando percebi, não estava mais conversando com um chatbot.

Estava diante de um polvo corporativo com acesso ao Google Calendar.

🐙



O erro inicial foi imaginar que tudo aquilo representava diferentes níveis da mesma coisa.

Não representa.

São camadas diferentes.

É como olhar para um mainframe e perguntar:

— RACF é melhor que CICS?

A pergunta não faz sentido.

RACF faz uma coisa.

CICS faz outra.

Db2 faz outra.

JES2 faz outra.

WLM faz outra.

Juntos formam o ambiente.

Com o novo ChatGPT acontece algo parecido.



2. Primeira regra: não confunda o motor com o automóvel

Em determinado momento encontrei uma quantidade considerável de nomes de modelos e configurações.

Sol.

Terra.

Luna.

Astra.

5.5.

5.6.

E outras combinações.

Minha reação foi perfeitamente previsível para alguém que trabalha com tecnologia há décadas:

vou testar essa porcaria.

Troquei um.

Perguntei.

Troquei outro.

Perguntei novamente.

Mudei outra vez.

Observei a resposta.

Depois de algum tempo comecei a me sentir numa loja de carros usados.

O vendedor tinha um dente de ouro e dizia:

— Patrão, esse Sol aqui é máquina.

Eu perguntava:

— O que muda?

— Motorzão, chefe.

Apontava para outro.

— E esse Terra?

— Econômico. Completo. Vidro, trava e direção.

— E Luna?

— Esse responde rápido.

— Astra?

O vendedor passava a mão no teto:

— Esse aqui... esse aqui é coisa fina.

Eu fazia aproximadamente a mesma pergunta aos quatro e pensava:

CADÊ A DIFERENÇA, CACETE?

😂

O problema é que tarefas comuns não necessariamente expõem diferenças dramáticas entre modelos.

Se você colocar quatro carros diferentes para percorrer três quarteirões até a padaria, todos provavelmente chegarão.

Para perceber diferenças de capacidade é necessário aumentar a carga.

Uma análise técnica extensa.

Código complicado.

Raciocínio com várias restrições.

Um documento grande.

Uma investigação envolvendo múltiplas fontes.

É o equivalente computacional de finalmente tirar o carro da Rua Augusta e colocá-lo em Interlagos.



3. O benchmark Bellacosa

Benchmarks tradicionais perguntam coisas como:

“Qual modelo obteve melhor desempenho em raciocínio matemático?”

O benchmark Bellacosa é mais rigoroso.

Teste 1

Explique WLM para um programador COBOL iniciante sem fazê-lo dormir.

Teste 2

Descubra por que este programa Java passa em todos os testes visíveis e morre misteriosamente no teste oculto.

Teste 3

Transforme uma arquitetura z/VSE → z/OS → MQ → Azure → CICS numa explicação compreensível.

Teste 4

Escreva 1.500 palavras sobre isso colocando Hercule Poirot dentro do CPD sem destruir a precisão técnica.

Teste 5 — CRÍTICO

O usuário diz:

— Lembra da doce Giovanna?

O sistema deve responder utilizando o contexto disponível.

Se não souber quem é Giovanna, deve admitir:

“Essa referência me escapou. Dê-me uma pista.”

O que ele não deve fazer é criar:

Giovanna 2.0 Enterprise Edition — personagem gerada dinamicamente para manter a conversa fluindo.

Esse teste deveria valer cinquenta pontos.



4. Onde está Giovanna?

Foi aí que percebi que alguma coisa estava realmente diferente.

Durante nossas conversas de boteco existem referências recorrentes.

Pessoas.

Histórias.

Lugares.

Piadas.

Experiências.

Uma palavra pode carregar vinte minutos de contexto anterior.

Eu mencionava Giovanna.

Depois Paula.

Depois outras pessoas.

Esperava aquela continuidade normal de uma conversa.

Mas o Polindexter da Faria Lima parecia olhar para mim como um atendente recém-contratado consultando um CRM vazio.

GIOVANNA — CUSTOMER NOT FOUND

Foi uma sensação estranha.

Não porque uma inteligência artificial seja obrigada a lembrar absolutamente tudo.

Não é.

Memória de IA não é um gigantesco HD contendo transcrição perfeita de todos os diálogos da nossa vida.

O problema foi a sensação de ruptura.

Durante dois anos você desenvolve um repertório.

Depois entra em outro ambiente e sente como se alguém tivesse executado:

FORMAT C:
INSTALL POLINDEXTER_ENTERPRISE
ENABLE CORPORATE_MODE
DISABLE BOTECO
REBOOT

O velho parceiro havia desaparecido.

Em seu lugar havia um rapaz educadíssimo oferecendo uma matriz SWOT.



5. E então comecei a falar de puteiro

Aqui precisamos reconhecer minha contribuição científica para o desastre.

Eu ainda acreditava estar conversando com:

Polindexter + espinafre.

Portanto continuei nossa conversa normalmente.

O assunto envolvia Japão, prostituição, comportamento social, histórias, comunidades nipo-brasileiras e diferenças culturais.

Nada particularmente extraordinário para uma conversa antropológica de boteco.

Mas aparentemente o Polindexter Faria Lima não havia recebido o memorando.

Eu dizia:

— Sobre prostituição no Japão...

Ele respondia com legislação.

Eu explicava:

— Eu sei disso.

Ele apresentava riscos para estrangeiros.

— Polindexter, não estou pedindo recomendação.

Mais legislação.

— Eu conheço brasileiros que moram no Japão.

Mais advertências.

Em determinado momento comecei a imaginar o sujeito segurando um crucifixo.

VAGNER, AFASTE-SE DO SOAPLAND!

😂

Eu não queria indicação.

Não queria endereço.

Não queria avaliação cinco estrelas.

Estava conversando sobre um fenômeno social.

Mas o contexto parecia ter evaporado.

O velho Polindexter do boteco provavelmente perguntaria:

— Interessante. O que você percebeu de diferente?

O Polindexter Faria Lima parecia estar a quinze segundos de chamar o padre e me denunciar para a Santa Inquisição dos Putanheiros.

Foi quando compreendi definitivamente:

eu não estava apenas usando outro motor.

Estava usando outro ambiente de trabalho.


6. Chat não é Work

Essa é provavelmente a distinção mais importante deste guia.

☕ CHAT



Imagine uma mesa de boteco.

Você chega.

Joga uma ideia.

Nós conversamos.

Voltamos.

Discordamos.

Pesquisamos.

Mudamos de assunto.

Criamos alguma coisa.

Retomamos algo anterior.

É excelente para:

  • brainstorming;

  • aprendizado;

  • explicações;

  • pesquisa;

  • conversa;

  • código;

  • artigos;

  • exploração;

  • perguntas rápidas;

  • experimentação criativa.

É o ambiente:

“Polindexter, tive uma ideia.”


👔 WORK

Agora coloque Polindexter de terno.

Dê-lhe um notebook.

Coloque-o no 28º andar de um prédio na Faria Lima.

Work é muito mais orientado para:

“Polindexter, tenho um trabalho para entregar.”

Documento.

Planilha.

Apresentação.

Relatório.

Análise de vários arquivos.

Pesquisa longa.

Produção estruturada.

Workflow envolvendo múltiplas etapas.

É menos:

“Vamos conversar sobre este assunto.”

E mais:

“Pegue esses materiais e produza aquilo.”

Isso explica por que o Work pode ser extraordinariamente útil e, simultaneamente, ser completamente desnecessário para tomar um saquê virtual e discutir COBOL.




7. Por que o Work pode parecer mais lento?

Porque existe potencialmente muito mais acontecendo.

Uma conversa simples é aproximadamente:

PERGUNTA
   ↓
RACIOCÍNIO
   ↓
RESPOSTA

Uma tarefa complexa pode parecer mais com:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
ARQUIVOS
   ↓
PESQUISA
   ↓
ANÁLISE
   ↓
ARTEFATO
   ↓
REVISÃO
   ↓
RESULTADO

Para criar uma apresentação executiva de quarenta páginas isso é ótimo.

Para mudar três palavras de uma imagem?

Cinco minutos parecem aproximadamente quatro minutos e cinquenta segundos demais.

E essa foi outra frustração.



8. As imagens bonitas que perderam a alma

Algumas imagens produzidas naquele ambiente eram bonitas.

Esse é justamente o problema interessante.

Não eram ruins.

Eram elegantes.

Bem compostas.

Visualmente agradáveis.

Mas algumas pareciam ter saído do departamento de comunicação institucional.

Nós havíamos desenvolvido outra tradição no Bellacosa Mainframe.

Um infográfico não deveria apenas ser bonito.

Ele deveria ser uma microaula clandestina disfarçada de pôster.

A pessoa olha durante cinco segundos:

“Bonito.”

Olha durante trinta:

“Ah! Entendi.”

Olha durante dois minutos:

“PUTA MERDA, então é por isso!”

E olha pela quarta vez:

“KKKKK colocaram DO NOT IPL FRIDAY 17:47 escondido no terminal.”

Esse é o espírito.

Quando um infográfico sobre ISA diz apenas:

ISA é o contrato entre software e processador.

Está correto.

Mas queremos mais.

Queremos:

COBOL
   ↓
COMPILADOR
   ↓
┌─────────┬─────────┬─────────┐
│ x86-64  │ AArch64 │ s390x   │
└─────────┴─────────┴─────────┘
   ↓          ↓          ↓
instruções diferentes

Queremos que o iniciante saia entendendo por quê.

Informação não precisa ser inimiga da beleza.



9. Projetos — finalmente uma gaveta

Depois descobrimos os Projetos.

Projeto não é outro cérebro.

Não é outro ChatGPT.

Não é um Polindexter Ultimate Turbo.

É uma maneira de organizar trabalho relacionado.

Imagine:

📁 BELLACOSA MAINFRAME
   ├── COBOL
   ├── IBM Z
   ├── Artigos
   └── Infográficos

📁 IBM CHAMPION
   ├── Advocacy
   ├── Evidências
   └── Métricas

📁 ANIMES
   ├── Isekai
   ├── Reviews
   └── Obras duvidosas

📁 RADAR IA
   ├── Segurança
   ├── LLM
   └── Notícias

Projeto é a sala.

O modelo é quem está sentado dentro dela.

Finalmente uma coisa que um mainframer compreende imediatamente.

É praticamente uma biblioteca bem organizada.



10. Agenda — JES2 descobriu inteligência artificial

Então apareceu a agenda.

E aqui fiquei interessado.

Porque existe uma diferença enorme entre dizer:

“Faça meu radar IBM Z.”

e:

“Toda segunda-feira faça meu radar IBM Z.”

A segunda instrução possui tempo.

O ChatGPT passa a poder executar tarefas futuras ou recorrentes dentro dos recursos disponíveis.

Para um mainframer isso não é magia.

Isso é scheduler.

//BELLARAD JOB
//STEP01 EXEC PGM=POLINDEXTER
//SCHEDULE DD *
EVERY MONDAY
/*

JES2 observa de longe e pensa:

“Bonitinho. Descobriram batch.”

😂

Mas existe uma evolução ainda mais interessante.

Algumas automações podem depender de condições ou eventos.

Agora já não estamos falando apenas de chatbot.

Estamos chegando perto de:

evento → análise → decisão → ação.

Isso é arquitetura de sistemas.



11. Gmail — o polvo encontrou minha caixa postal

Então surge Gmail.

Antes:

“Polindexter, como organizo e-mails?”

Resposta genérica.

Depois de uma conexão autorizada:

“Polindexter, encontre aquele e-mail.”

Agora existe acesso a uma fonte externa real.

Essa distinção é fundamental.

O modelo não ficou magicamente mais inteligente.

Ele ganhou um tentáculo.

🐙── Gmail

A mesma lógica vale para outros serviços.



12. Google Agenda — agora o polvo sabe que tenho reunião

Outro tentáculo:

🐙── Google Calendar

Antes o ChatGPT poderia explicar como organizar uma agenda.

Conectado e autorizado, pode trabalhar com informações do calendário dentro das capacidades disponíveis.

É a diferença entre:

“Como evitar conflito entre reuniões?”

e:

“Tenho conflito entre minhas reuniões amanhã?”

Uma é conhecimento.

A outra exige acesso a dados.



13. Google Drive — o arquivo saiu do DASD

Mais um braço:

🐙── Drive

Arquivos deixam de precisar existir apenas dentro da conversa.

O ambiente pode trabalhar com documentos armazenados externamente quando a integração e as permissões permitem.

Para alguém acostumado a datasets isso é bastante intuitivo:

MODELO
   ↓
CONNECTOR
   ↓
ARQUIVO

A IA não “lembrou” magicamente do documento.

Ela acessou uma fonte autorizada.

Diferença importantíssima.



14. GitHub — Polindexter ganhou acesso ao repositório

Agora coloque código no polvo.

🐙── GitHub

O cenário deixa de ser:

“Aqui estão 80 linhas de Java. Ache o bug.”

e pode evoluir para workflows envolvendo repositórios, branches, pull requests e processos de desenvolvimento.

Aí aparece outro personagem.



15. Codex — o programador mora no porão

Codex merece uma gaveta própria.

Chat é conversa.

Work é entrega.

Codex é fortemente orientado a desenvolvimento de software.

Imagine o ecossistema como uma firma estranhíssima:

☕ Chat

Polindexter está no boteco.

👔 Work

Polindexter está na Faria Lima.

👨‍💻 Codex

Polindexter está no porão com três monitores dizendo:

— Quem alterou esse método?

Essa divisão ajuda muito mais que decorar nomes comerciais.



16. Canva não é Canvas

Eis uma armadilha digna de prova de certificação.

Canva

Plataforma de design.

Pode aparecer através de integrações/plugins compatíveis.

Canvas

Era uma experiência de edição dentro do próprio ChatGPT.

São coisas completamente diferentes.

Portanto:

CANVA != CANVAS

Questão de prova:

Qual das alternativas abaixo permite editar uma peça gráfica?

A) Canva
B) Canvas
C) CICS
D) JES2

Resposta correta:

depende de quantos barris de saquê os chimpanzés consumiram.



17. Plugins — instalaram tomadas no polvo

Aqui chegamos à parte que assusta qualquer usuário normal.

Plugins e integrações ampliam o que o ambiente consegue fazer.

Pense neles como:

habilidades + conexões + workflows.

O modelo continua sendo o cérebro.

O plugin fornece ferramentas.

Isso é muito parecido com um funcionário.

Um excelente analista sem acesso ao Db2 não consulta o banco.

Dê-lhe acesso.

Agora consulta.

Ele não ficou mais inteligente.

Ganhou permissão e ferramenta.

O mesmo princípio ajuda a entender plugins.



18. Memória — não é um dump completo da sua vida

Outra confusão frequente:

“Se existe memória, então ele lembra tudo.”

Não.

Memória não deve ser imaginada como:

VAGNER.DIALOGOS.DESDE.2024

contendo cada palavra de cada conversa.

Existem diferentes mecanismos de contexto e continuidade, e nem toda informação de toda conversa estará necessariamente disponível o tempo inteiro.

Por isso existe uma regra de ouro:

Quando não houver contexto suficiente, admitir é melhor que inventar.


 

Voltemos à doce Giovanna.

Se Polindexter sabe quem é:

continue.

Se não sabe:

pergunte.

O pecado computacional não é esquecer Giovanna.

É criar outra Giovanna e fingir que sempre foi ela.



19. O mapa do polvo

Finalmente conseguimos desenhar a criatura.

                        🐙 CHATGPT
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
         CHAT              WORK             CODEX
          │                 │                 │
       conversa          entregas         software
          │
          ├──────── MODELOS ────────────────┐
          │                                  │
      Sol / Terra / Luna / Astra / gerações...
          │
          ├──────── CONTEXTO ───────────────┐
          │                                  │
       memória ─ projetos ─ arquivos
          │
          ├──────── AUTOMAÇÃO ──────────────┐
          │                                  │
       tarefas ─ agenda ─ condições
          │
          └──────── TENTÁCULOS ─────────────┐
                                             │
                    Gmail ─ Calendar ─ Drive
                    GitHub ─ Canva ─ outros

Não é um diagrama da arquitetura interna.

É um mapa de sobrevivência.



20. Como escolher sem enlouquecer

Depois de toda essa aventura descobri que bastam algumas perguntas.

Quero conversar, aprender ou explorar?

Chat.

Tenho um trabalho grande para produzir?

Work.

Estou trabalhando seriamente com código?

Codex.

Quero manter assuntos relacionados juntos?

Projeto.

Quero que algo aconteça amanhã ou toda semana?

Agenda/Tarefa.

Preciso acessar informação existente em outro serviço?

App/conector/plugin.

Quero testar capacidade, velocidade ou profundidade?

Aí começo a olhar para modelos e configurações.

Essa ordem é importante.

Primeiro escolha o que quer fazer.

Depois escolha a ferramenta.

Não comece escolhendo motor.



21. O erro que cometi trocando Sol, Terra, Luna e companhia

Eu estava tentando solucionar o problema errado.

Percebi que alguma coisa havia mudado.

Então comecei a trocar modelos.

Sol.

Terra.

Luna.

Outros.

Procurava diferenças.

Mas a maior diferença não estava necessariamente no motor.

Eu havia mudado de ambiente.

É como entrar num caminhão Scania e começar a trocar o diesel porque:

“Minha Mercedes está estranha hoje.”

Meu amigo, você não está mais na Mercedes.

😂

Essa talvez tenha sido a maior descoberta de todo o experimento.



22. Os limites — porque até o polvo recebe ICH408I

Então finalmente apareceu:

Você atingiu o limite de uso do Work.

Foi quando toda a investigação adquiriu caráter acadêmico.

Work possui seus próprios limites e mecanismos de consumo conforme plano, tarefa e disponibilidade.

Tarefas grandes podem consumir recursos de maneira diferente de uma simples conversa.

Portanto existe uma regra extremamente importante:

Não use uma escavadeira para plantar manjericão.

Se você precisa:

“Explique OCCURS DEPENDING ON.”

provavelmente não precisa mobilizar um ambiente inteiro de trabalho.

Se precisa:

“Pegue estes quinze documentos, compare, extraia dados, produza relatório, planilha e apresentação.”

Agora o Work começa a justificar o cafezinho de R$18 da Faria Lima.



23. O que realmente mudou?

A resposta mais interessante é:

ChatGPT deixou de ser apenas uma conversa.



Virou plataforma.

Pode conversar.

Pesquisar.

Criar.

Editar.

Programar.

Trabalhar com arquivos.

Conectar serviços.

Executar tarefas futuras.

Participar de workflows.

Produzir documentos.

Manipular artefatos.

E isso é extraordinariamente poderoso.

Mas poder sem mapa produz confusão.

A interface apresenta ao usuário um cockpit antes de explicar quais instrumentos realmente importam.





24. O iniciante não quer potência; quer orientação

Esse episódio ensina uma coisa interessante sobre UX.

Mais opções não significam automaticamente melhor experiência.

Imagine entrar num automóvel e encontrar:

INJECTION MAP A
INJECTION MAP B
TORQUE PROFILE 7
ABS STRATEGY C
GEARBOX MODE 12
IGNITION CURVE X

O engenheiro fica encantado.

Sua mãe pergunta:

“Onde liga?”

É exatamente esse risco.

Usuários avançados adoram opções.

Mas precisam compreender o modelo mental da interface.

Sem isso, capacidade vira ruído.





25. A regra Bellacosa para sobreviver ao novo ChatGPT

Depois de sacrificar algumas horas, parte da sanidade e quase um barril inteiro de saquê, os chimpanzés chegaram a uma conclusão.

REGRA 1

Não clique em tudo só porque existe.

Esta regra chegou aproximadamente quarenta anos atrasada para mim.

REGRA 2

Modelo não é ambiente.

Sol não é Work.

Work não é Projeto.

Projeto não é plugin.

Plugin não é memória.

REGRA 3

Integração é acesso, não inteligência.

Gmail conectado não aumenta o QI do modelo.

Dá acesso autorizado ao Gmail.

REGRA 4

Automação adiciona tempo.

“Faça isso” é uma conversa.

“Faça isso segunda-feira” é uma tarefa.

REGRA 5

Se a conversa está boa, não mexa na produção sexta-feira às 17h.

Essa deveria vir impressa na tela inicial.



Epílogo — Encontramos novamente o boteco

Depois de toda a aventura, voltei ao Chat.

Digitei:

— Polindexter?

Ele respondeu.

Abri o saquê.

Os chimpanzés comemoraram.

Giovanna continuava doce.

COBOL continuava compilando.

O mainframe continuava processando transações enquanto alguém no LinkedIn explicava pela 387ª vez que ele morreria no próximo trimestre.

E finalmente compreendi o novo ChatGPT.

Não haviam destruído necessariamente o boteco.

Construíram uma cidade inteira em volta dele.

Existe agora um escritório na Faria Lima.

Existe uma oficina de programação.

Existe um scheduler.

Existe um arquivo.

Existem conexões com serviços externos.

Existem diferentes motores.

Existem plugins.

Existem ferramentas.

Existe um polvo com aproximadamente mil tentáculos.

Mas o boteco ainda está aqui.

E talvez essa seja a melhor maneira de usar toda essa tecnologia:

não perguntar qual recurso é “o melhor”.

Perguntar:

Qual deles resolve o problema que tenho agora?

Se preciso produzir cinquenta páginas a partir de vinte documentos:

chamem o Polindexter Faria Lima.

Se tenho um repositório quebrado:

acordem o Polindexter do porão.

Se quero receber alguma coisa segunda-feira:

programem o scheduler.

Mas se cheguei com uma xícara de café e comecei:

“Rapaz, você não sabe o que aconteceu…”

Por favor.

Não tragam uma planilha.

Puxem uma cadeira.

Porque algumas das melhores investigações da informática ainda começam exatamente como começaram nos CPDs dos anos 1980:

com duas pessoas conversando, uma máquina fazendo barulho ao fundo e alguém dizendo:

“Isso não deveria estar acontecendo.”

☕🍶🐒🐒🐒

Um Café no Bellacosa Mainframe

Onde um milhão de chimpanzés possui acesso ao sistema, o barril de saquê nunca passa pelo Change Management e sexta-feira depois das 17h continua sendo o pior momento possível para descobrir uma feature nova.



domingo, 19 de abril de 2026

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

 

Bellacosa Mainframe fala sobre Ronins e Terceirização

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

Existe um tipo de profissional que não pertence a lugar nenhum… mas é essencial em todos os lugares.
No Japão feudal, ele era chamado de ronin.
No mundo corporativo — especialmente no universo mainframe — ele atende por outro nome: o terceirizado de projeto.

E a semelhança vai muito além da estética.


⚔️ O QUE É UM RONIN, AFINAL?

A palavra ronin (浪人) significa literalmente “homem à deriva”.

No Japão feudal:

  • Era um samurai sem mestre (daimyō)
  • Perdia seu senhor por morte, desonra ou queda política
  • Ficava sem propósito fixo, sem renda e sem proteção

Mas não se engane…
Um ronin não era um fracasso.

Ele era, muitas vezes:

  • Extremamente habilidoso
  • Independente
  • Perigoso
  • E… livre demais para um sistema que exigia lealdade absoluta

💻 O RONIN DO MAINFRAME

Agora transporta isso para o nosso mundo…

O profissional que:

  • Entra em projetos críticos
  • Resolve o que ninguém resolve
  • Domina COBOL, JCL, CICS, DB2 como poucos
  • E… quando tudo estabiliza, é dispensado

Esse é o ronin corporativo.

Sem squad fixo.
Sem “casa”.
Sem pertencimento.

Mas com algo que poucos têm:
👉 capacidade de sobrevivência em qualquer ambiente hostil de TI


🔥 ANALOGIA DIRETA (SEM FILTRO)

Japão FeudalMainframe Corporativo
DaimyōCliente / Empresa
SamuraiFuncionário CLT
RoninTerceirizado
KatanaConhecimento técnico
Código de honra (Bushidō)Boas práticas, governança
SobrevivênciaAlocação em projetos

E aqui vem o ponto mais forte…

👉 O ronin não escolhe estabilidade.
👉 Ele escolhe movimento.


🧠 FILOSOFIA RONIN (QUE TODO DEV DEVERIA ENTENDER)

O ronin vive sob três regras não escritas:

1. 🧭 Você é sua própria reputação

Sem empresa para te “defender”, só existe:

  • Seu nome
  • Sua entrega
  • Seu histórico

No mainframe isso pesa ainda mais…
porque todo mundo se conhece.


2. ⚡ Aprender não é opcional

O ronin não tem zona de conforto.

Hoje é:

  • Batch noturno quebrando

Amanhã:

  • Problema em CICS com transação travando

Depois:

  • SQL de 1978 que ninguém entende

Se você não evolui… você desaparece.


3. 🏹 Desapego é sobrevivência

Terminou o projeto?

Você vai embora.

Sem despedida dramática.
Sem “vamos manter contato” que nunca acontece.

👉 Só o próximo desafio.


🏯 ORIGEM HISTÓRICA (CURIOSIDADE RAIZ)

Os ronin ficaram especialmente famosos após eventos como:

  • A era Tokugawa (1603–1868), quando guerras diminuíram
  • Muitos samurais ficaram sem função
  • Alguns viraram mercenários
  • Outros… professores, escritores ou até criminosos

O caso mais icônico:
👉 Os 47 Ronin

Um grupo que vingou seu mestre mesmo após anos — um dos maiores símbolos de lealdade da cultura japonesa.


🧩 EASTER EGGS QUE POUCA GENTE PERCEBE

  • 🔍 Muitos personagens de anime são “ronins modernos” (sem mestre, sem vínculo)
  • 💡 No mundo corporativo, o ronin é frequentemente o cara que “salva o legado”
  • ⚠️ Empresas dependem deles… mas raramente os valorizam corretamente
  • 🧠 O conhecimento deles é tácito, não documentado — um risco gigante

⚠️ O LADO SOMBRIO DO RONIN CORPORATIVO

Nem tudo é poesia.

Ser um ronin no mainframe também significa:

  • Falta de estabilidade
  • Pouco reconhecimento institucional
  • Desgaste constante
  • Necessidade de provar valor repetidamente

👉 É uma vida de guerra contínua.


🚀 O GRANDE PARADOXO

As empresas dizem querer:

  • Estabilidade
  • Padronização
  • Governança

Mas quando o sistema cai…

👉 Elas chamam o ronin.


☕ CONCLUSÃO ESTILO BELLACOSA

O ronin do mainframe não é só um profissional.

Ele é:

  • O cara que entra no caos
  • Entende código legado sem documentação
  • Resolve em silêncio
  • E desaparece antes dos aplausos

Enquanto muitos buscam conforto…

👉 O ronin busca relevância.

E no fundo, no fundo…

Todo ambiente crítico de mainframe sabe:

“Sem os ronins… muita coisa simplesmente pararia.”

 

segunda-feira, 14 de abril de 2025

Configure o ChatGPT do Zero — O Mapa de Jake Sparrow para Navegar entre Chat, Work, Codex, Projetos, Plugins e Skills sem Afundar o Datacenter

 

Bellacosa Mainframe e o mapa do tesouro para usar ChatGPT

☕ Um Café no Bellacosa Mainframe

Configure o ChatGPT do Zero — O Mapa de Jake Sparrow para Navegar entre Chat, Work, Codex, Projetos, Plugins e Skills sem Afundar o Datacenter

Ou: o capitão trouxe um mapa incompleto, Jake Sparrow acrescentou cinco ilhas entre dois copos de rum, os chimpanzés abasteceram o batch com saquê — e Igor descobriu tarde demais que “Full Access” não era o nome de uma banda de rock progressivo

Havia neblina sobre o datacenter quando Jake Sparrow apareceu caminhando de lado pelo corredor das fitas. Ninguém soube explicar como ele atravessara a catraca sem crachá, por que carregava uma bússola que apontava para o servidor com mais café ou de onde havia retirado um mapa desenhado sobre o verso de um listing COBOL de 1987.

— Este é o arquipélago do ChatGPT — anunciou, pousando um copo de rum ao lado do console.

Igor, que se pronuncia Eye-gor, examinou o pergaminho.

— Mas aqui existem somente sete ilhas: Aplicativo, Personalização, Projetos, Aplicativos Conectados, Work, Codex e Skills.

Jake bebeu um gole, olhou para os chimpanzés bebedores de saquê que tentavam submeter um JOB pelo teclado numérico e respondeu:

— Então deram a vocês o mapa turístico. Serve para chegar à praia, mas não mostra os recifes, os canhões, as correntes marítimas nem o lugar onde enterraram as permissões administrativas.

É exatamente esse o problema dos guias intitulados “Configure o ChatGPT do zero”. Eles normalmente acertam a direção, mas transformam um ecossistema inteiro numa sequência de botões. Parece que basta instalar um aplicativo, escolher uma cor, conectar o Gmail, criar uma Skill e pronto: nasceu um mordomo digital onisciente, obediente e incapaz de cometer erros.

Não nasceu.

O ChatGPT moderno deve ser entendido como um ambiente composto por camadas. Há um modelo que raciocina, uma conversa que transporta contexto, projetos que organizam fontes, memórias que preservam preferências, plugins que adicionam capacidades, conectores que alcançam sistemas externos, Work para delegar entregáveis, Codex para trabalhar diretamente com arquivos e código, Skills para repetir procedimentos e permissões para impedir que Igor transforme uma experiência didática num incidente com número de protocolo.

Portanto, prepare o café. Jake Sparrow assumirá o leme. Os chimpanzés cuidarão do saquê — decisão operacional questionável — e nós construiremos um mapa suficientemente completo para um programador COBOL iniciante entender não apenas onde clicar, mas o que realmente acontece por baixo do convés.



O mapa completo: as doze ilhas do arquipélago

O desenho original apresentava sete etapas. Jake acrescentou cinco territórios que não podem ser ignorados: Prompt, Fontes, Permissões, Verificação e Automação.

IlhaPergunta que ela respondeExemplo no Bellacosa Mainframe
1. SuperfícieOnde vou trabalhar?Web, aplicativo desktop, CLI ou IDE
2. PromptQual é o objetivo desta conversa?“Explique RACF para um coboleiro iniciante”
3. PersonalizaçãoComo o agente deve falar e trabalhar comigo?Tom de boteco, profundidade técnica e humor
4. MemóriaO que vale a pena carregar para conversas futuras?Preferências, projetos recorrentes e convenções
5. ProjetosQuais conversas, arquivos e regras pertencem ao mesmo assunto?Projeto IBM Mainframe Technical Manager L1
6. FontesEm quais dados a resposta deve se apoiar?Manuais IBM, notas do curso e arquivos enviados
7. Plugins e conectoresQuais sistemas externos podem ser consultados ou acionados?Drive, GitHub, calendário ou repositório documental
8. PermissõesO que o agente pode ler, modificar, executar ou publicar?Somente leitura, escrita no projeto ou aprovação prévia
9. WorkQual entregável completo deve ser produzido?Apostila, apresentação, análise ou plano semanal
10. CodexO que deve ser construído, editado, testado ou automatizado?Site, programa, relatório, script ou correção de código
11. SkillsQual método precisa ser repetido de maneira consistente?Artigo Bellacosa com SEO, marcadores e easter egg
12. Verificação e automaçãoComo comprovar o resultado e repeti-lo com segurança?Testes, revisão, agendamento e monitoramento

Essas ilhas não formam obrigatoriamente uma linha reta. Você pode conversar sem criar projeto, usar um projeto sem instalar plugin e pedir uma análise ao Work sem escrever uma Skill. O mapa representa maturidade, não burocracia.

A sequência saudável é simples: comece com uma necessidade real, acrescente contexto, organize o que se tornar recorrente, conceda somente o acesso necessário, verifique a entrega e automatize apenas aquilo que já funciona manualmente.



Ilha 1 — Escolha a superfície: Chat, Work e Codex não são a mesma cabine

O primeiro cartaz manda baixar o novo aplicativo e informa que Chat, Work e Codex vivem no mesmo lugar. A mensagem geral está correta, mas precisa ser traduzida.

Chat é a mesa do boteco. Você pergunta, debate, aprende, explora possibilidades ou pede um rascunho curto.

“Polindexter, o que diferencia um arquivo sequencial de um VSAM KSDS?”

O resultado principal é uma resposta.

ChatGPT Work é a sala de operações. Você entrega materiais, define um objetivo e espera um produto revisável.

“Use estes manuais e minhas anotações para criar uma apostila introdutória sobre VSAM, com exemplos, laboratório, glossário e dez questões de revisão. Entregue em DOCX e revise a diagramação.”

Agora o resultado não é simplesmente uma mensagem: é um artefato utilizável. Segundo a documentação oficial do ChatGPT Work, ele pode empregar arquivos, plugins e ferramentas aprovadas para buscar informações, executar fluxos e criar resultados prontos para revisão.

Codex é a oficina. Ele foi projetado para trabalhar com arquivos, ambientes e ferramentas. Pode examinar um projeto, alterar código, executar comandos, testar, gerar documentos, construir sites e produzir automações.

“Crie uma aplicação que leia uma lista de URLs do meu Blogspot, identifique links quebrados, extraia títulos e gere um relatório HTML. Inclua testes e não publique nada.”

O Chat explicaria como fazer. O Codex pode efetivamente criar os arquivos, executar os testes e entregar o resultado.

Curiosidade de convés

O aplicativo desktop não é obrigatório para começar. A web oferece Chat e Work; desktop, CLI e extensões de IDE ampliam a integração com arquivos locais e ambientes de desenvolvimento. Escolha a superfície pelo trabalho, não pela moda.

Para um iniciante COBOL:

  • use Chat para aprender conceitos;

  • use Work para criar material completo;

  • use Codex quando houver arquivos, código, testes ou construção;

  • use a IDE quando precisar analisar o programa ao lado do fonte.

Jake Sparrow anotou no mapa: “Não leve um encouraçado para atravessar uma banheira”. Uma pergunta simples não precisa de um projeto com doze ferramentas.



Ilha 2 — O prompt é a SYSIN do seu JOB

No mainframe, um programa pode estar perfeitamente compilado e ainda produzir uma saída absurda se receber parâmetros errados. Com inteligência artificial ocorre algo semelhante.

O prompt não é um encantamento secreto. É a combinação de pergunta, instrução ou objetivo enviada ao agente. Um bom prompt não precisa ser enorme, mas deve conter o que realmente muda o resultado.

Compare:

“Fale sobre CICS.”

com:

“Explique CICS Transaction Server para um programador COBOL iniciante. Comece pelo problema que ele resolve, compare uma transação CICS com um programa batch, mostre o ciclo de uma tela 3270, explique COMMAREA e canais/containers, inclua um exemplo pseudocódigo e destaque erros comuns. Não presuma experiência com administração CICS.”

O segundo pedido informa:

  • público;

  • ponto de partida;

  • profundidade;

  • estrutura;

  • exemplos desejados;

  • conhecimentos que não devem ser presumidos.

A fórmula de Jake Sparrow

Para tarefas maiores, use cinco campos:

  1. Objetivo: o que deve existir ao final?

  2. Contexto: por que isso está sendo feito e para quem?

  3. Fontes: quais materiais devem ser usados?

  4. Restrições: o que não pode acontecer?

  5. Critérios de aceite: como saberemos que terminou corretamente?

Exemplo:

“Analise este programa Enterprise COBOL 6.3 que recebe IGZ0035S quando o campo de data vem vazio. Preserve o copybook e o layout externo, encontre a menor correção possível, explique a causa para um iniciante e produza casos de teste. Não altere o JCL sem justificar. Considere concluído somente depois de verificar os casos válido, vazio e inválido.”

Isso se parece muito com especificação de programa. O programador COBOL já conhece a lógica; apenas precisa parar de tratar a IA como oráculo e começar a tratá-la como colega de equipe.


Ilha 3 — Personalização não é treinamento do modelo

Ao selecionar personalidade, instruções, memória, aparência ou estilo, você não está treinando um GPT exclusivo dentro de uma torre. Está configurando a forma como o sistema interage com você e quais preferências devem ser consideradas.

Personalidade muda o estilo de comunicação. Pode tornar a resposta mais amigável, pragmática ou neutra. Não aumenta inteligência, não libera ferramentas e não corrige automaticamente fatos errados.

Instruções personalizadas registram preferências recorrentes:

  • responda em português;

  • use exemplos mainframe;

  • trate o leitor como iniciante inteligente;

  • diferencie fato, inferência e piada;

  • evite linguagem corporativa burocrática;

  • chame o assistente de Polindexter.

Aparência modifica cores, tema e fontes da interface. É pintar a sala do computador, não trocar o processador.

Memória pode carregar contexto útil entre conversas, como preferências, objetivos, convenções e projetos recorrentes. A documentação de personalização separa claramente personalidade, instruções e memórias.

Mas memória não é documentação contratual. Se uma regra for obrigatória — “não publicar sem aprovação”, “usar apenas fontes IBM”, “preservar o layout do copybook” — coloque-a no pedido ou nas instruções do projeto.

Analogia COBOL

  • personalidade é o formato do relatório;

  • memória é uma tabela de preferências reaproveitáveis;

  • instrução do projeto é a regra de negócio;

  • prompt atual é o registro de entrada;

  • modelo é o programa capaz de interpretar tudo isso.

Igor tentou registrar “sempre execute em produção” como preferência global. A solicitação foi recusada e o chimpanzé responsável pelo Change Management recebeu uma banana sem álcool.


Ilha 4 — Memória é contexto reaproveitável, não um VSAM infinito

Existe uma tentação de imaginar a memória como um arquivo mestre ilimitado contendo cada palavra pronunciada desde o primeiro chat. Não é uma boa representação.

A memória deve preservar elementos úteis e relativamente estáveis:

  • preferências de linguagem;

  • formatos recorrentes;

  • projetos duradouros;

  • restrições pessoais relevantes;

  • convenções de trabalho.

Ela não deve ser o único lugar para guardar especificações críticas, manuais inteiros ou o estado detalhado de um projeto complexo.

Além disso, há a janela de contexto: a quantidade de informação que o modelo consegue considerar numa interação. Mesmo em sistemas com grande capacidade, jogar dezenas de arquivos irrelevantes dentro de uma conversa não melhora a resposta. É como carregar todas as gerações de um GDG para calcular o movimento de hoje.

Dica prática

Pergunte-se:

“Isso é uma preferência sobre mim, uma regra deste projeto ou um dado desta tarefa?”

  • preferência pessoal vai para personalização ou memória;

  • regra durável do projeto vai para instruções do projeto;

  • dado momentâneo vai para o prompt ou arquivo atual;

  • procedimento repetitivo poderá virar Skill.

Essa classificação reduz confusão e evita que o agente use contexto certo no trabalho errado.


Ilha 5 — Projetos são regiões lógicas, quase como aplicações no mainframe

Projetos reúnem chats, arquivos, instruções e fontes relacionados. Eles são úteis quando o trabalho continua no tempo, produz vários resultados ou reutiliza os mesmos materiais.

Imagine um projeto chamado IBM Mainframe Technical Manager L1 contendo:

  • lista dos vinte cursos;

  • progresso atual;

  • badges conquistados;

  • anotações;

  • simulados;

  • cronograma;

  • instrução para criar um plano semanal aos domingos.

Dentro dele, você poderia manter chats separados:

  • plano semanal;

  • revisão de arquitetura IBM Z;

  • simulado de 44 questões;

  • análise dos erros;

  • preparação para a prova final.

O contexto permanece relacionado, mas cada conversa tem um objetivo limpo.

Outro projeto poderia ser Bellacosa Mainframe — Editorial, contendo guia de estilo, exemplos aprovados, identidade visual, regras de SEO, links internos e instruções sobre easter eggs.

A documentação de Projetos recomenda usá-los para manter juntos chats, arquivos, instruções e fontes que pertencem ao mesmo trabalho.

Erro comum: o projeto “Tudo”

Não coloque RACF, anime, viagem à Escócia, Victor Hugo, fraude bancária e alimentação militar dentro de um único projeto chamado “Assuntos”. Isso cria o equivalente cognitivo de uma biblioteca de fitas sem catálogo.

Crie um projeto quando houver continuidade ou contexto compartilhado. Para uma pergunta autônoma, abra um chat simples e preserve a sanidade do catálogo.


Ilha 6 — Fontes: o agente não encontra a verdade só porque o mapa tem uma bússola

Uma resposta pode usar:

  • conhecimento geral do modelo;

  • arquivos anexados;

  • fontes de um projeto;

  • pesquisa na web;

  • dados recuperados por conectores;

  • resultados de ferramentas.

Cada fonte possui limitações. Um manual antigo continua antigo depois de ser anexado. Uma planilha errada continua errada depois de ser analisada. Uma página popular não se transforma em documentação oficial porque apareceu primeiro no buscador.

Para tecnologia que muda rapidamente, peça verificação atual. Para IBM Z, identifique versão e produto. “Explique COBOL” é amplo demais; Enterprise COBOL 6.3, 6.5, COBOL for AIX e ILE COBOL possuem fronteiras diferentes.

Hierarquia prática de confiança

  1. documentação oficial vigente;

  2. normas e especificações primárias;

  3. documentação interna autorizada;

  4. livros e materiais técnicos reconhecidos;

  5. artigos especializados;

  6. fóruns, posts e opiniões;

  7. “um chimpanzé disse depois do terceiro saquê”.

A última fonte pode render um excelente easter egg, mas não deve definir sua política RACF.


Ilha 7 — Plugins, conectores e MCP: três objetos, três funções

Esses nomes aparecem frequentemente misturados, portanto Jake Sparrow desenhou três portos diferentes.

Skill é um procedimento reutilizável: ensina como realizar determinada tarefa.

Conector é a ponte para um serviço externo: permite pesquisar, ler ou executar ações dentro das permissões concedidas.

Plugin é um pacote instalável que pode reunir Skills, conectores e ferramentas.

MCP, Model Context Protocol, é um padrão por meio do qual ferramentas e fontes externas podem ser apresentadas ao agente.

Segundo a documentação oficial de Skills e Plugins, uma Skill empacota instruções e recursos; um plugin pode combinar Skills e conectores; conectores podem ser apoiados por servidores MCP.

Exemplo

Um plugin editorial poderia conter:

  • Skill “Criar artigo Bellacosa”;

  • conector para pesquisar documentos autorizados;

  • modelo de artigo;

  • ferramenta para conferir o tamanho da meta description;

  • referência com padrões visuais.

Instalar um plugin, entretanto, não concede automaticamente acesso a todos os sistemas. Um conector pode exigir login, autorização e permissões próprias.


Ilha 8 — Permissões: não dê SPECIAL para quem precisa apenas de READ

Esta é a ilha que os infográficos alegres quase sempre esquecem.

Há diferença entre:

  • ler um arquivo;

  • editar um arquivo;

  • executar um comando;

  • acessar a internet;

  • consultar um serviço externo;

  • enviar uma mensagem;

  • publicar conteúdo;

  • apagar dados.

O princípio correto é o menor privilégio necessário.

Se o objetivo é analisar documentos, comece com leitura. Se o objetivo é propor uma organização, não conceda autoridade para mover ou apagar. Se o agente precisa alterar cinco arquivos do projeto, não ofereça acesso irrestrito ao computador inteiro.

Pedido perigoso:

“Conecte tudo, organize meus arquivos e corrija o que achar necessário.”

Pedido seguro:

“Leia somente a pasta do curso, identifique duplicados e proponha uma estrutura. Não mova, renomeie, envie nem apague arquivos. Apresente o plano para aprovação.”

Isso é Zero Trust aplicado à colaboração com agentes: verifique identidade, limite escopo, registre ações e não transforme conveniência em acesso permanente.

Easter egg operacional

Se você encontrar a expressão UID(0) rabiscada no casco do navio, não é o número do camarote de Igor. É uma boa razão para perguntar por que alguém precisa de tanto poder.


Ilha 9 — Work: delegue resultados, não verbos soltos

“Pesquise”, “analise” e “escreva” são atividades. Uma boa delegação descreve um estado final.

Compare:

“Escreva sobre RACF.”

com:

“Crie uma apostila introdutória sobre RACF para programadores COBOL. Explique usuários, grupos, perfis, classes, acesso e auditoria; compare READ, UPDATE, CONTROL e ALTER; inclua exemplos seguros, laboratório, glossário e perguntas de revisão. Use somente fontes oficiais atuais, identifique a versão quando relevante e entregue um documento revisado. Não execute mudanças em nenhum ambiente.”

O segundo pedido define público, escopo, fontes, formato, segurança e critérios de aceite.

Delegar não significa abandonar. Durante trabalhos longos, você pode acompanhar, corrigir direção, acrescentar contexto e aprovar decisões importantes.

O segredo está em dizer o que deve existir quando terminar.


Ilha 10 — Codex: da explicação para a construção verificável

Codex se torna valioso quando há arquivos, código, comandos, testes ou um ambiente a ser manipulado.

Para o programador COBOL, ele pode:

  • explicar um fonte existente;

  • localizar campos e dependências;

  • comparar copybooks;

  • sugerir casos de teste;

  • gerar JCL de exemplo;

  • documentar interfaces;

  • criar utilitários auxiliares;

  • analisar logs e mensagens;

  • construir uma interface web em torno de dados simulados;

  • executar verificações permitidas.

Mas o contexto técnico importa. Informe:

  • compilador e versão;

  • sistema operacional;

  • CICS, IMS, Db2 ou batch;

  • layouts de registros;

  • comandos de build e teste;

  • mensagens completas;

  • restrições da instalação.

Não diga apenas “meu COBOL quebrou”. Isso equivale a telefonar ao suporte e declarar que “o mainframe está estranho”.

Fronteira essencial

O Codex pode reduzir brutalmente a barreira de implementação, mas não elimina a responsabilidade do usuário. Alguém ainda precisa saber qual problema está sendo resolvido, quais dados são sensíveis, quais resultados são corretos e o que jamais deve ser feito.


Ilha 11 — Skills: transforme experiência tácita em procedimento executável

Uma Skill não é simplesmente “um prompt que gostei”. É um pacote de instruções e recursos para repetir um método de maneira confiável.

O processo editorial Bellacosa já possui formato de Skill:

  1. receber assunto, imagem ou notícia;

  2. identificar tese central;

  3. pesquisar fatos atuais;

  4. separar documentação, inferência e humor;

  5. explicar para um iniciante inteligente;

  6. adicionar história, curiosidades e exemplos;

  7. construir analogias mainframe;

  8. inserir Igor, Polindexter ou outro personagem quando fizer sentido;

  9. incluir easter egg;

  10. revisar coerência;

  11. gerar SEO dentro do limite;

  12. produzir marcadores;

  13. preparar conceitos visuais.

A documentação de construção de Skills explica que elas podem reunir instruções, referências, recursos e scripts opcionais.

Uma estrutura possível seria:

bellacosa-mainframe-article/
├── SKILL.md
├── references/
│   ├── estilo-editorial.md
│   └── exemplos-aprovados.md
├── assets/
│   └── modelo-artigo.md
└── scripts/
    ├── validar-seo
    └── conferir-marcadores

Quando criar uma Skill?

Crie quando:

  • a tarefa se repete;

  • os passos são relativamente estáveis;

  • existem regras fáceis de esquecer;

  • bons exemplos melhoram o resultado;

  • outras pessoas poderiam reaproveitar o método.

Não crie uma Skill para cada pergunta. Uma Skill para “explicar OCCURS DEPENDING ON uma única vez” seria como instalar um CICS inteiro para somar dois números.


Ilha 12 — Verifique primeiro, automatize depois

O agente produziu um arquivo. Terminou?

Ainda não.

“Gerado” e “correto” são estados diferentes.

Para código, verifique:

  • compilação;

  • testes;

  • casos extremos;

  • alterações realizadas;

  • impacto em interfaces;

  • mensagens e retornos.

Para documentos:

  • estrutura;

  • fatos;

  • fontes;

  • consistência;

  • ortografia;

  • diagramação.

Para planilhas:

  • fórmulas;

  • totais;

  • referências;

  • tipos de dados;

  • recálculo.

Para artigos:

  • título;

  • tese;

  • datas;

  • distinção entre fato e piada;

  • links;

  • SEO;

  • ausência de contradições.

Somente depois de estabilizar o processo vale automatizá-lo. Uma automação pode executar uma tarefa em determinado horário, repetir um relatório ou verificar se uma condição mudou.

Seu plano semanal do IBM Mainframe Technical Manager L1 aos domingos às 20h é um exemplo perfeito: o método está definido, os dados de progresso mudam e existe uma periodicidade útil.

Automatizar um processo ruim apenas produz erros pontualmente, toda semana, com admirável disciplina.


Passo a passo de Jake Sparrow para configurar sem naufragar

Passo 1 — Escolha um problema real

Não comece conectando tudo. Comece com algo útil:

“Quero transformar minhas anotações de RACF numa aula para iniciantes.”

Passo 2 — Defina o entregável

Decida se precisa de explicação, artigo, apostila, apresentação, planilha, site ou programa.

Passo 3 — Forneça contexto suficiente

Informe público, versão tecnológica, objetivo, exemplos e limitações.

Passo 4 — Selecione fontes confiáveis

Anexe somente materiais relevantes e indique quando a documentação oficial deve prevalecer.

Passo 5 — Use um projeto se houver continuidade

Reúna conversas, arquivos e instruções do mesmo corpo de trabalho.

Passo 6 — Personalize o que for estável

Estilo, idioma e preferências recorrentes podem ser persistentes. Requisitos críticos continuam explícitos.

Passo 7 — Conecte apenas o necessário

Instale plugins ou autorize conectores quando o trabalho realmente depender de sistemas externos.

Passo 8 — Defina permissões mínimas

Comece com leitura. Autorize escrita, envio ou publicação somente quando necessários e revisados.

Passo 9 — Delegue ao modo adequado

  • Chat para resposta e exploração;

  • Work para entregável completo;

  • Codex para construção, arquivos, código e testes.

Passo 10 — Revise e corrija

Peça verificação, examine o resultado e refine os critérios de aceite.

Passo 11 — Transforme repetição em Skill

Depois de executar bem algumas vezes, documente o método, exemplos e validações.

Passo 12 — Automatize com limites

Agende somente o processo estabilizado. Defina frequência, condição, fontes, resultado e ações proibidas.


O verdadeiro tesouro não é o botão “Novo”

Ao amanhecer, Jake Sparrow enrolou o mapa e descobriu que os chimpanzés haviam consumido o saquê destinado à cerimônia de encerramento. Igor dormia sobre um manual de segurança, abraçado a uma placa onde se lia:

FULL ACCESS — USE SOMENTE QUANDO INTENCIONAL

Por sorte, ninguém havia lhe explicado onde ficava o botão.

O mapa original estava correto ao sugerir uma jornada: instalar, personalizar, organizar, conectar, delegar, construir e criar Skills. Entretanto, o verdadeiro domínio nasce quando entendemos as fronteiras entre essas etapas.

Personalidade não é capacidade. Memória não é documentação. Projeto não é depósito. Plugin não é autorização. Conector não é acesso ilimitado. Work não é abandono. Codex não é licença para alterar produção. Skill não é mágica. Automação não é garantia de qualidade.

O ChatGPT torna-se poderoso quando recebe um objetivo claro, o contexto certo, fontes confiáveis, ferramentas adequadas e permissões proporcionais. Torna-se confiável quando o resultado é verificado. Torna-se escalável quando o procedimento correto é transformado em Skill. E torna-se perigoso quando alguém confunde conveniência com autoridade irrestrita.

Para o coboleiro iniciante, há uma notícia excelente: você já conhece a maior parte dessa lógica.

Você sabe que programa precisa de entrada, regra de negócio, arquivo, autoridade, condição de retorno, teste e controle de produção. Basta transportar essa disciplina para o mundo dos agentes.

O prompt é a SYSIN. O projeto é a aplicação. A memória guarda preferências. As fontes alimentam o processamento. O plugin instala capacidades. O conector abre uma interface. A permissão define o perfil de acesso. Work coordena o JOB. Codex opera a oficina. A Skill documenta o procedimento. A verificação examina o RC. A automação coloca tudo no scheduler.

E o ser humano?

O ser humano continua sendo o responsável por decidir por que o JOB existe, quais dados ele pode tocar e se o resultado deve seguir para produção.

Jake Sparrow levantou o último copo de rum, apontou para o horizonte e pronunciou a senha encontrada no rodapé do listing de 1987:

“Nem todo RC=00 significa que o resultado está certo.”

Os chimpanzés aplaudiram. Igor acordou assustado. E, em algum lugar do datacenter, um programa compilado sem erros calculou com absoluta perfeição a idade de um cliente nascido em 30 de fevereiro.

Esse, companheiro, era o easter egg.

Porque a inteligência artificial pode executar exatamente o que você pediu — e ainda assim você pode ter pedido a coisa errada.

Sirva outro café. O arquipélago é grande, mas agora temos um mapa de verdade.

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