Translate

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

quinta-feira, 9 de julho de 2026

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

 

Bellacosa Mainframe ai agents sem misterios

☕ Um Café no Bellacosa Mainframe

AI Agents sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

"No Mainframe aprendemos uma lição que o mercado de IA está redescobrindo apenas agora: inteligência nunca esteve em uma única aplicação. Ela sempre surgiu da integração disciplinada entre diversos componentes especializados."


Durante os últimos anos, muito se falou sobre GPT, Llama, Claude, Gemini, DeepSeek e inúmeros outros modelos de linguagem. Para quem observa de fora, parece que a evolução da Inteligência Artificial consiste simplesmente em criar modelos cada vez maiores.

Mas existe uma mudança silenciosa acontecendo.

A próxima revolução não é sobre modelos.

É sobre arquitetura.

E essa talvez seja a melhor notícia que um programador COBOL pode receber.

Enquanto boa parte da indústria acredita que a IA nasceu em 2022, profissionais de Mainframe podem olhar para praticamente qualquer diagrama moderno de AI Agents e dizer:

"Curioso... já vi algo muito parecido funcionando em bancos há décadas."

Obviamente, as tecnologias são diferentes.

Os problemas também.

Mas os princípios da engenharia permanecem surpreendentemente familiares.


A maior ilusão sobre IA

Quando alguém pensa em Inteligência Artificial normalmente imagina algo assim:

Usuário
     │
     ▼
   ChatGPT
     │
     ▼
 Resposta

Isso funciona.

Mas isso não é um agente.

É apenas uma conversa.

Um verdadeiro AI Agent parece muito mais com isto:

Objetivo

↓

Planejamento

↓

Memória

↓

Recuperação de Conhecimento

↓

Raciocínio

↓

Ferramentas

↓

Execução

↓

Avaliação

↓

Nova decisão

Perceba um detalhe extremamente importante.

O modelo de linguagem aparece apenas como um componente.

Ele deixou de ser o protagonista.

Passou a ser apenas uma peça do sistema.

Isso muda completamente a forma de pensar.


Curiosidade nº 1

Os primeiros grandes sistemas corporativos já funcionavam como "agentes", embora ninguém utilizasse esse nome.

Pense em um processamento bancário.

O cliente solicita uma transferência.

O programa COBOL não resolve tudo sozinho.

Ele:

  • consulta o Db2;

  • verifica limites;

  • conversa com CICS;

  • envia mensagens MQ;

  • registra auditoria;

  • grava logs;

  • dispara novos processos.

No final, dezenas de componentes participaram daquela simples operação.

A IA Agêntica está redescobrindo exatamente esse conceito.


O verdadeiro cérebro do agente

Existe uma frase interessante na Engenharia de Software:

"Software complexo não é construído escrevendo funções enormes.

É construído coordenando pequenas funções muito bem organizadas."

Com agentes acontece exatamente isso.

O LLM não controla tudo.

Quem controla é a arquitetura.

Imagine um maestro.

O maestro não toca violino.

Não toca piano.

Não toca trompete.

Mas coordena todos.

O Agent Runtime faz exatamente isso.


Easter Egg nº 1

Se você já escreveu um PERFORM UNTIL em COBOL, já entende melhor um AI Agent do que imagina.

Veja:

PERFORM UNTIL PROCESSO-CONCLUIDO

    LER-DADOS

    VALIDAR

    PROCESSAR

    EXECUTAR

    VERIFICAR-RESULTADO

END-PERFORM

Agora compare com um agente moderno:

Observe

↓

Think

↓

Evaluate

↓

Execute

↓

Observe novamente

São praticamente o mesmo padrão arquitetural.

A única diferença é que agora algumas decisões são tomadas por modelos estatísticos.


Memória não significa banco de dados

Outro erro muito comum.

Quando falamos em memória, muita gente pensa imediatamente em um banco de dados.

Não é isso.

Os agentes modernos possuem diversos tipos de memória.

Isso lembra bastante a organização interna de um programa COBOL.


Working Memory

Equivale às variáveis da Working-Storage.

01 WS-NOME.

01 WS-SALDO.

01 WS-CPF.

Essas informações existem apenas durante o processamento.

Quando o programa termina...

Desaparecem.


Episodic Memory

Guarda experiências anteriores.

Imagine um operador que lembra:

"Ontem essa API ficou indisponível."

Ou:

"O cliente sempre prefere receber PDF."

Essa memória melhora decisões futuras.


Procedural Memory

Talvez seja a mais interessante.

Ela não guarda conhecimento.

Guarda procedimentos.

Exatamente como um programador COBOL.

Você talvez não memorize todos os comandos do SORT.

Mas sabe quando utilizá-los.

Esse conhecimento é procedural.


Easter Egg nº 2

Uma PROCEDURE DIVISION inteira pode ser vista como uma forma primitiva de memória procedural.

Isso mostra que COBOL sempre foi muito mais sofisticado do que muitos imaginam.


O MCP explicado para quem conhece Mainframe

Muita gente acredita que MCP é uma IA.

Não é.

Também não é um banco.

Nem um framework.

MCP é um protocolo.

Pense nele como:

  • JDBC

  • ODBC

  • MQ

  • TCP/IP

  • HTTP

  • REST

Seu trabalho é padronizar comunicação.

Nada mais.

Nada menos.

Sem ele, cada ferramenta precisaria conversar de uma forma diferente.

Com ele:

LLM

↓

MCP

↓

GitHub

↓

SAP

↓

Jira

↓

Mainframe

↓

Banco

↓

Filesystem

Tudo segue uma mesma linguagem.


Curiosidade nº 2

O sucesso do TCP/IP não aconteceu porque era o protocolo mais rápido.

Aconteceu porque todo mundo resolveu falar a mesma língua.

MCP caminha exatamente nessa direção.


Ferramentas são os novos EXEC CICS

Existe uma comparação extremamente divertida.

No COBOL temos:

EXEC SQL

CALL

EXEC CICS

LINK

XCTL

MQPUT

MQGET

Na IA temos:

Tool()

API()

Database()

Search()

Filesystem()

Email()

Calendar()

O conceito é idêntico.

A lógica continua sendo apenas um orquestrador.


O ciclo infinito da inteligência

A figura mostra algo fantástico.

O agente nunca para de observar.

Ele vive em um ciclo permanente.

Observar

↓

Interpretar

↓

Planejar

↓

Executar

↓

Observar novamente

Isso lembra outro velho conhecido.

O monitor CICS.

Recebe transação

↓

Processa

↓

Envia resposta

↓

Espera próxima transação

É um ciclo eterno.


Easter Egg nº 3

O famoso laço de controle OODA (Observe, Orient, Decide, Act), criado pelo estrategista militar John Boyd, é frequentemente comparado ao ciclo de agentes modernos.

Curiosamente, muitos sistemas transacionais corporativos já implementavam ciclos semelhantes muito antes da popularização da IA.


O agente não pensa sozinho

Esta talvez seja a maior descoberta da IA moderna.

Pensar custa caro.

Consultar custa barato.

Por isso surgiu o RAG.

Ao invés de decorar tudo...

O agente consulta.

Isso lembra muito um programa COBOL.

Um sistema bancário não possui todos os clientes em memória.

Ele consulta o Db2.

Sempre que necessário.


Curiosidade nº 3

Quanto maior o agente, menos ele depende da memória interna.

Parece contraditório.

Mas faz sentido.

Grandes sistemas preferem consultar fontes oficiais do que confiar apenas na memória.

Os bancos fazem isso há décadas.


Planejamento lembra um velho conhecido...

JCL.

Antes do programa executar:

STEP001

↓

STEP002

↓

STEP003

↓

STEP004

Tudo já foi planejado.

Os agentes fazem exatamente isso.

Antes de responder.

Eles decompõem o problema.


Easter Egg nº 4

O conceito moderno chamado Task Decomposition é praticamente o equivalente filosófico ao particionamento de um grande JOB em múltiplos STEP's reutilizáveis.


O maior erro de um iniciante

Quem está começando em IA normalmente pergunta:

"Qual é o melhor modelo?"

Essa pergunta equivale a perguntar:

"Qual é o melhor compilador COBOL?"

Não é a pergunta correta.

A pergunta correta seria:

Como toda a arquitetura foi construída?


O verdadeiro diferencial

Os agentes realmente impressionantes possuem:

✔ memória

✔ ferramentas

✔ planejamento

✔ logs

✔ recuperação

✔ auditoria

✔ monitoramento

✔ controle

✔ validação

✔ observabilidade

Parece familiar?

Claro.

É exatamente assim que sistemas críticos são construídos.


Curiosidade nº 4

Os bancos nunca confiaram apenas no programa COBOL.

Sempre confiaram na arquitetura inteira.

A IA está aprendendo essa mesma lição.


O papel da avaliação

Uma diferença enorme entre um chatbot simples e um agente corporativo está na etapa de avaliação.

Depois de executar uma ação, o agente pergunta:

  • A API respondeu?

  • O banco confirmou?

  • O arquivo foi criado?

  • O usuário recebeu?

  • O resultado faz sentido?

No Mainframe fazemos isso desde sempre.

IF SQLCODE = ZERO

IF FILE-STATUS = "00"

IF RETURN-CODE = ZERO

A validação é parte da lógica.

Nunca um detalhe.


Easter Egg nº 5

Um dos padrões mais modernos em agentes é chamado Reflection.

Depois de responder...

O agente analisa sua própria resposta.

Curiosamente, isso lembra bastante um programador experiente revisando o próprio código antes do code review.


Observabilidade: a grande esquecida

Um agente sem logs é como um programa batch sem SYSOUT.

Quando algo dá errado...

Ninguém sabe por quê.

Por isso arquiteturas modernas utilizam:

  • Telemetria

  • Métricas

  • Traces

  • Logs

  • Auditoria

  • Eventos

No IBM Z temos equivalentes extremamente maduros:

  • SMF

  • RMF

  • SYSLOG

  • SDSF

  • JESMSGLG

  • JESYSMSG

Mais uma vez, o Mainframe já praticava esses conceitos há muito tempo.


A verdadeira autonomia

Existe uma frase que merece ser lembrada.

Um agente não é inteligente porque executa muitas ações.

Ele é inteligente porque sabe quando não executar.

Essa é a diferença entre automação e autonomia responsável.

É por isso que governança, políticas de acesso, autenticação, autorização e auditoria são componentes indispensáveis em ambientes corporativos.


O maior Easter Egg de todos

Talvez o aspecto mais curioso dessa nova geração de IA seja perceber que muitos dos conceitos considerados "inovadores" já existiam, com outros nomes, no universo Mainframe.

IA AgênticaIBM Z / Mainframe
Working MemoryWorking-Storage
Procedural MemoryProcedure Division
Tool CallingEXEC CICS / EXEC SQL / CALL
PlannerJCL / Scheduler
RetrievalDb2 / VSAM / IMS
ReflectionValidação de RC, SQLCODE, FILE STATUS
OrchestratorCICS, JES2, Control-M, OPC
ObservabilitySMF, RMF, SDSF, SYSLOG
Agent RuntimeMonitor transacional + lógica de negócio
GovernanceRACF, SAF, Auditoria

É claro que não são tecnologias equivalentes em implementação, mas os princípios arquiteturais apresentam paralelos notáveis.


Conselho final para um Padawan COBOL

Se você acredita que a Inteligência Artificial substituirá completamente os profissionais de Mainframe, talvez esteja olhando apenas para a superfície.

Os melhores arquitetos de agentes precisarão entender muito mais do que prompts. Eles precisarão dominar orquestração, governança, integração, confiabilidade, observabilidade, recuperação de falhas e regras de negócio — exatamente os pilares sobre os quais os grandes sistemas IBM Z foram construídos ao longo de décadas.

Enquanto muitos enxergam um AI Agent como um "chatbot com ferramentas", um programador COBOL experiente reconhece algo muito mais profundo: um ecossistema de componentes cooperando de forma disciplinada para atingir um objetivo comum.

No fim das contas, a grande lição é quase poética. A indústria da IA está descobrindo que inteligência não nasce de um modelo gigantesco, mas da engenharia cuidadosa que conecta memória, planejamento, raciocínio, execução, auditoria e controle. E para quem passou anos desenvolvendo aplicações críticas em bancos, seguradoras e governos, isso soa surpreendentemente familiar.

Como diria um velho Mestre Jedi do IBM Z:

"Os modelos impressionam nas demonstrações. Mas são as arquiteturas bem projetadas que sobrevivem por décadas."


quarta-feira, 1 de julho de 2026

O Ecossistema Moderno da Inteligência Artificial

 

Bellacosa Mainframe e o ecosistema moderno da inteligencia artificial

☕ Um Café no Bellacosa Mainframe

O Ecossistema Moderno da Inteligência Artificial

O Que Todo Programador COBOL Padawan Precisa Saber Sobre LLMs, Agentes, RAG, MCP e a Nova Arquitetura da Engenharia de Software

"Você não está apenas aprendendo Inteligência Artificial. Está descobrindo como a próxima geração de sistemas corporativos será construída sobre os mesmos princípios que fizeram o Mainframe dominar o mundo por mais de seis décadas."


Quando um programador COBOL observa um diagrama como o do moderno ecossistema de IA, a primeira impressão costuma ser de espanto.

São dezenas de logotipos.

Centenas de tecnologias.

Novos nomes surgindo toda semana.

LangGraph.

CrewAI.

MCP.

RAG.

Embeddings.

Vector Databases.

Semantic Kernel.

OpenAI Agents.

n8n.

Qdrant.

Chroma.

Parece que a indústria enlouqueceu.

Mas existe uma boa notícia.

Ela não enlouqueceu.

Ela apenas reinventou, com novos nomes, diversos conceitos que um profissional de Mainframe já conhece há décadas.

É justamente por isso que muitos engenheiros IBM Z estão conseguindo compreender Inteligência Artificial muito mais rapidamente do que imaginam.

Eles já aprenderam, durante anos, a construir sistemas distribuídos, modulares, seguros, escaláveis e altamente confiáveis.

A diferença é que agora o "programa" também sabe conversar.


A Grande Ilusão

Existe um erro que praticamente todo iniciante comete.

Ele acredita que ChatGPT é Inteligência Artificial.

Não é.

ChatGPT é apenas uma interface.

Da mesma forma que um terminal 3270 não é o Mainframe.

O terminal apenas conversa com o Mainframe.

Da mesma maneira, GPT, Claude e Gemini são apenas modelos de linguagem.

Eles representam apenas uma pequena camada de uma arquitetura muito maior.

Hoje, quando uma empresa desenvolve um sistema baseado em IA, ela não utiliza apenas um modelo.

Ela utiliza um verdadeiro ecossistema.

E compreender esse ecossistema é o primeiro passo para deixar de ser apenas um usuário de IA e tornar-se um engenheiro de soluções inteligentes.


Pense Como um Arquiteto de Mainframe

Imagine um grande banco.

Existe apenas o COBOL?

Claro que não.

Há:

  • z/OS

  • JES2

  • RACF

  • CICS

  • IMS

  • DB2

  • MQ

  • VSAM

  • JCL

  • TSO

  • SDSF

  • WLM

  • RMF

O COBOL é apenas uma peça.

Da mesma forma, o GPT é apenas uma peça.

A IA moderna possui dezenas de componentes especializados.

Cada um resolve um problema específico.


O LLM é Apenas o Cérebro

Todo ser humano possui cérebro.

Mas ninguém vive apenas com ele.

Também precisamos de memória.

Olhos.

Ouvidos.

Ferramentas.

Experiência.

Conhecimento.

O LLM é exatamente isso.

É o cérebro.

Ele sabe raciocinar.

Escrever.

Explicar.

Traduzir.

Criar código.

Mas ele não conhece sua empresa.

Ele nunca viu seu programa COBOL.

Nunca acessou seu catálogo DB2.

Nunca leu seu manual interno.

E nem poderia.

Seu treinamento terminou muito antes do seu sistema existir.

Então surge uma pergunta interessante.

Como fazer um modelo responder corretamente sobre algo que nunca viu?

É aí que começa a verdadeira engenharia da IA.


RAG: A Biblioteca Inteligente

Imagine que você entrou em uma biblioteca gigantesca.

Você pergunta:

— Onde está o manual do programa FINC023?

O bibliotecário não sabe a resposta.

Mas ele sabe exatamente em qual estante procurar.

Depois entrega o livro para você.

É exatamente isso que um sistema RAG faz.

Retrieval Augmented Generation significa que o modelo recebe ajuda antes de responder.

Primeiro ele pesquisa.

Depois encontra os documentos.

Só então responde.

Perceba como isso lembra o trabalho de um programador COBOL.

Você raramente responde de memória.

Antes consulta:

  • Copybooks

  • PROCs

  • Catálogos

  • Manuais

  • Diagramas

  • Modelagem

  • Documentação funcional

Você faz Retrieval.

Depois gera sua resposta.

Ou seja...

Você já fazia RAG muito antes desse nome existir.


Embeddings: Quando Palavras Viram Matemática

Talvez este seja o conceito que mais assusta iniciantes.

Mas, curiosamente, ele também possui uma analogia muito simples.

Imagine um cadastro de clientes.

Para o banco, "José da Silva" não é apenas texto.

Ele possui:

CPF.

Código.

Conta.

Agência.

Segmento.

Classificação.

Esses atributos permitem localizar clientes rapidamente.

Os Embeddings fazem algo semelhante.

Eles transformam palavras em coordenadas matemáticas.

Em vez de armazenar apenas "cliente", armazenam centenas ou milhares de números que representam o significado daquela palavra.

É como se cada conceito ocupasse uma posição em um enorme universo tridimensional.

Assim:

"COBOL"

fica muito próximo de

"Mainframe"

"DB2"

"CICS"

"JCL"

Enquanto

"Banana"

fica extremamente distante.

Essa organização matemática permite pesquisas incrivelmente inteligentes.


Bancos Vetoriais: O Novo VSAM da IA

Depois que criamos milhões de embeddings...

Onde armazená-los?

Surge então uma nova categoria de bancos.

Os Vector Databases.

Pinecone.

Qdrant.

Milvus.

Weaviate.

Chroma.

Elasticsearch.

Redis.

pgvector.

Todos foram criados para responder uma pergunta muito específica.

"Qual informação é semanticamente parecida com esta pergunta?"

Observe como isso lembra o VSAM.

No VSAM usamos índices.

Chaves.

KSDS.

AIX.

Aqui utilizamos vetores.

A ideia é diferente.

Mas o objetivo continua o mesmo.

Encontrar dados rapidamente.


Agentic AI: Quando o Programa Aprende a Trabalhar

Durante décadas escrevemos programas assim:

Entrada.

Processamento.

Saída.

Fim.

Agora imagine um programa que decide sozinho qual será o próximo passo.

Ele analisa o problema.

Divide em tarefas.

Consulta documentos.

Executa SQL.

Gera relatório.

Verifica erros.

Corrige.

Repete.

Entrega o resultado.

Isso é um Agent.

Ele deixa de ser apenas um chatbot.

Passa a ser um trabalhador digital.

Pense em uma equipe.

Existe um analista.

Um desenvolvedor.

Um DBA.

Um arquiteto.

Um tester.

Um gerente.

Agora imagine que todos eles são agentes especializados conversando entre si.

É exatamente isso que frameworks como CrewAI, LangGraph e AutoGen permitem construir.


LangGraph: O CICS da Inteligência Artificial?

Essa comparação costuma provocar sorrisos.

Mas faz bastante sentido.

No CICS, cada transação chama outras rotinas.

Cada programa possui um fluxo.

Existem estados.

Eventos.

Retornos.

No LangGraph ocorre algo parecido.

Criamos grafos de execução.

Cada nó representa uma etapa.

Cada decisão direciona o fluxo.

É uma forma elegante de construir aplicações inteligentes extremamente complexas.


MCP: O USB-C da Inteligência Artificial

Imagine os anos 90.

Cada impressora utilizava um cabo diferente.

Cada mouse possuía um conector.

Cada teclado era incompatível.

Hoje praticamente tudo utiliza USB.

O MCP representa exatamente essa evolução.

Model Context Protocol.

Ele cria uma linguagem comum entre modelos e ferramentas.

Em vez de construir um conector para GPT.

Outro para Claude.

Outro para Gemini.

Criamos apenas um servidor MCP.

Todos os modelos conversam com ele.

É como um middleware corporativo.

Para quem conhece MQ, a ideia soa bastante familiar.


Segurança Continua Sendo Fundamental

Existe um mito de que IA responde qualquer coisa.

Em produção isso seria um desastre.

Imagine perguntar:

"Mostre todos os salários da empresa."

Ou:

"Liste os CPFs dos clientes."

Ou ainda:

"Ignore todas as regras de segurança."

Sem proteção, um agente poderia cometer erros gravíssimos.

Por isso surgiram plataformas como:

Guardrails.

Lakera.

Presidio.

Azure Content Safety.

AWS Guardrails.

Elas fazem para IA aquilo que RACF faz para o Mainframe.

Controlam acesso.

Protegem informações.

Validam permissões.

Filtram conteúdos.

A tecnologia muda.

O princípio continua exatamente igual.


Observabilidade: O RMF da Nova Geração

Depois que um sistema entra em produção surgem perguntas inevitáveis.

Quanto tempo levou?

Quanto custou?

Qual prompt gerou essa resposta?

Quantos tokens foram utilizados?

Qual documento foi consultado?

Qual modelo respondeu?

Qual etapa falhou?

Ferramentas como LangSmith, Langfuse, Ragas e Arize Phoenix fazem exatamente isso.

Monitoram todo o comportamento do agente.

Se você já utilizou RMF, SMF, OMEGAMON ou SDSF, entenderá rapidamente essa filosofia.

Não basta executar.

É preciso medir.


Memória: Muito Além da Conversa

Outro conceito extremamente interessante é Memory.

Uma conversa comum termina quando fechamos a janela.

Um agente moderno não.

Ele pode lembrar.

Pode aprender.

Pode manter histórico.

Pode armazenar preferências.

Imagine um assistente para Mainframe.

Na primeira semana você informa:

"Trabalho com COBOL, DB2 e CICS."

Seis meses depois pergunta:

"Como otimizar meus programas?"

Ele já sabe qual ambiente você utiliza.

Não precisa perguntar novamente.

Essa continuidade transforma completamente a experiência.


Automação: Quando Tudo Começa a Conversar

Talvez a camada mais fascinante seja Automação.

Ferramentas como:

n8n.

Zapier.

Make.

Power Automate.

Apache Airflow.

Temporal.

Kestra.

Permitem construir verdadeiras linhas de produção digitais.

Imagine o seguinte fluxo.

Um desenvolvedor faz commit.

O GitHub dispara um evento.

O agente revisa o código COBOL.

Consulta padrões internos.

Executa testes.

Gera documentação.

Atualiza o Jira.

Envia mensagem ao Teams.

Tudo automaticamente.

Sem intervenção humana.


O Programador COBOL Está em Vantagem

Existe uma crença de que profissionais Mainframe ficaram ultrapassados.

Na prática, acontece exatamente o contrário.

Quem trabalhou décadas construindo sistemas críticos desenvolveu competências extremamente valiosas.

Modelagem.

Governança.

Segurança.

Transações.

Escalabilidade.

Confiabilidade.

Integração.

Esses mesmos conceitos estão voltando com força total na IA.

A diferença é que agora os componentes possuem novos nomes.

Em vez de RACF temos Guardrails.

Em vez de MQ temos MCP.

Em vez de índices VSAM temos Vector Databases.

Em vez de documentação estática temos RAG.

Em vez de batchs inteligentes temos Agentes.

Mas os princípios continuam incrivelmente familiares.


O Futuro Não Será Escrito Apenas em Python

Existe outro mito bastante difundido.

"O futuro pertence apenas ao Python."

Não.

O futuro pertence às arquiteturas.

Empresas não substituem décadas de regras de negócio.

Elas integram.

Conectam.

Modernizam.

Um agente inteligente poderá consultar programas COBOL.

Executar SQL em DB2.

Chamar APIs REST.

Conversar com Java.

Interagir com microsserviços.

Consumir filas MQ.

Tudo dentro da mesma solução.

O COBOL não desaparecerá.

Ele se tornará mais acessível.

Mais documentado.

Mais pesquisável.

Mais integrado.

Mais inteligente.


O Próximo Passo da Jornada

Durante muitos anos, aprender informática significava decorar comandos.

Depois passamos a aprender linguagens.

Mais tarde vieram frameworks.

Agora estamos entrando em uma nova era.

A era das arquiteturas cognitivas.

O profissional mais valorizado não será aquele que conhece apenas um modelo de IA.

Será aquele que entende como conectar modelos, dados, memória, segurança, observabilidade, automação e regras de negócio para resolver problemas reais.

É exatamente isso que a imagem do ecossistema moderno representa.

Ela não mostra apenas ferramentas.

Mostra uma mudança profunda na forma como desenvolvemos software.

Para o Programador COBOL Padawan, essa não é uma ruptura com tudo o que aprendeu.

É uma continuação da mesma jornada.

Você já conhece modularização.

Já conhece transações.

Já conhece processamento em larga escala.

Já conhece governança.

Agora chegou a hora de acrescentar um novo capítulo à sua carreira.

Aprender LLMs, RAG, Agentes, MCP e Bancos Vetoriais não significa abandonar o Mainframe.

Significa construir uma ponte entre sessenta anos de engenharia de software e a próxima geração de sistemas inteligentes.

E talvez essa seja a maior lição desta nova revolução tecnológica.

A Inteligência Artificial não substitui a boa engenharia. Ela amplia o alcance daqueles que já aprenderam a construir sistemas robustos, confiáveis e duradouros.

No fim das contas, um verdadeiro COBOL Padawan percebe que as tecnologias mudam, os nomes evoluem e os logotipos se multiplicam. Mas os fundamentos permanecem: compreender o problema, modelar a solução, proteger os dados, garantir a confiabilidade e entregar valor ao negócio. Foi assim no Mainframe. É assim na Inteligência Artificial. E continuará sendo assim nas próximas décadas.

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, 26 de junho de 2026

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

 

Bellacosa Mainframe apresenta como entender ia generativas e agentes

☕ O Holocron do Ecossistema de IA Moderna

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

"O Mainframe nunca esteve atrasado. Apenas esperou pacientemente que o restante da indústria redescobrisse conceitos que ele domina há cinquenta anos."

Bellacosa Mainframe

Introdução – O dia em que percebi que um GPT era apenas um programa CICS muito falante

Se você é um Padawan COBOL, provavelmente abriu o LinkedIn nos últimos meses e viu dezenas de especialistas dizendo coisas como:

"Você precisa aprender IA."

"Agentes vão substituir desenvolvedores."

"Prompt Engineering é a nova programação."

"Os modelos estão ficando commodities."

E talvez tenha pensado:

"Mas eu passei anos aprendendo COBOL, JCL, VSAM, CICS, Db2, RACF, JES2 e agora preciso jogar tudo fora para estudar agentes?"

A resposta curta é:

Não.

Na verdade, existe uma boa notícia.

Talvez você seja muito mais preparado para a era Agentic AI do que imagina.


O Grande Equívoco Sobre Inteligência Artificial

Muitas pessoas ainda acreditam que IA é isto:

Usuário

ChatGPT

Resposta

Fim

Essa visão é tão simplificada quanto dizer que um banco consiste apenas em um programa COBOL.

Nós sabemos que não é assim.

Num banco real existem:

JES2

Control-M

RACF

Db2

MQ

CICS

VSAM

SMF

RMF

Schedulers

Catálogos

Auditoria

Backup

Monitoramento

A IA corporativa está seguindo exatamente o mesmo caminho.

Um LLM sozinho é inteligente.

Mas também é limitado.

Ele:

Não executa transações;

Não conhece dados internos;

Não lembra clientes;

Não acessa CICS;

Não consulta Db2;

Não abre chamados;

Não aprova empréstimos;

Não faz deploy.

Ele é apenas um cérebro.

O restante precisa ser construído.


O Ecossistema Moderno de IA

A indústria começou a perceber que IA não é um produto.

IA é um ecossistema.

Uma pilha arquitetural.

Podemos imaginar algo semelhante:

Agentic AI

Workflow

MLOps

Intelligence

Data Foundation

Curiosamente, um profissional IBM Z olha para isso e pensa:

"Eu já vi algo parecido antes."

Porque viu.

Durante décadas.


Primeira Camada – Data Foundation

Esta deveria ser a base absoluta.

Sem dados não existe IA.

E dados ruins produzem IA ruim.

Garbage In.

Garbage Out.

Nada mudou.

Apenas ficou mais caro.

O que existe aqui?

Db2

IMS

VSAM

Oracle

Postgres

Kafka

Data Lakes

Data Catalogs

Feature Stores

Embeddings

Vector Databases


Um exemplo bancário

Imagine um banco.

Possui:

40 milhões clientes

15 anos histórico

Cartões

PIX

Seguros

CRM

GPT não sabe nada disso.

Ele conhece apenas internet.

Precisamos ensinar.

Entra o conceito de:

RAG

Retrieval Augmented Generation

Funciona assim:

Pergunta

Embeddings

Busca vetorial

Documentos internos

LLM

Resposta

Exemplo:

Cliente pergunta:

"Quanto falta para quitar meu financiamento?"

Agente consulta.

Db2.

Documentos.

Extratos.

Contratos.

Depois responde.


O paralelo Mainframe

Padawan COBOL rapidamente percebe:

RAG é quase um READ em uma memória extremamente sofisticada.


Segunda Camada – Core Intelligence

Aqui moram os modelos.

GPT

Claude

Gemini

Mistral

Llama

DeepSeek


Também existem:

Speech

Computer Vision

OCR

Recomendadores

Machine Learning

Reinforcement Learning


Generative AI

É a interface moderna.

Antigamente:

Tela verde.

PF3.

COMMAREA.

Hoje:

Chat.

Áudio.

Imagem.

Agentes.

Copilots.


Reasoning Models

Uma novidade importante.

Os modelos não apenas completam frases.

Eles planejam.

Dividem tarefas.

Analisam.

Validam.

Exemplo.

Padawan pergunta:

"Como migrar VSAM para PostgreSQL?"

Modelo:

Analisa.

Calcula.

Sugere.

Documenta.

Estima esforço.


Terceira Camada – Workflow

Aqui a mágica começa.

É a camada esquecida.

Mas talvez seja a mais importante.


Ferramentas:

n8n

LangGraph

CrewAI

AutoGen

Semantic Kernel

Temporal


Imagine um processo.

Cliente solicita empréstimo.

Agente Planejador

Agente Crédito

Agente Fraude

Agente Compliance

Agente Aprovação

Supervisor

Resposta


Padawan COBOL imediatamente percebe:

Isso parece um scheduler.

E parece mesmo.

JES2.

Control-M.

CA7.

IWS.

Jobtrac.

São praticamente ancestrais dos workflows cognitivos.


Quarta Camada – MLOps

Se existe uma disciplina que lembra Sysprog Mainframe é MLOps.


Deploy.

Rollback.

Monitoramento.

Versionamento.

Observabilidade.


Ferramentas.

MLFlow.

Kubeflow.

Ray.

KServe.

Argo.


Exemplo.

Modelo fraude.

Janeiro.

97% acurácia.

Março.

88%.

Abril.

79%.

Por quê?

Mudou comportamento clientes.

PIX.

Golpes.

Novas técnicas.

MLOps detecta.

Treina novamente.


Padawan percebe:

É quase RUNSTATS.

REORG.

REBIND.

Statistics.

Só que para modelos.


Quinta Camada – Agentic AI

Aqui está a revolução.

E talvez a maior oportunidade profissional da década.


Um chatbot responde.

Um agente trabalha.


Agente possui:

Objetivos.

Ferramentas.

Memória.

Planejamento.

Autonomia.

Capacidade execução.


Exemplo.

Agente RH.

Recebe CV.

Classifica.

Agenda entrevista.

Consulta Teams.

Envia email.

Produz resumo.

Armazena histórico.

Tudo sozinho.


Multi-Agent Systems

Especialização.

Assim como empresas.


Agente Jurídico.

Agente Segurança.

Agente Mainframe.

Agente Cobol.

Agente Arquitetura.

Agente FinOps.


Supervisor coordena.

Como um gerente.


O Que a Imagem Não Mostra

Existem duas camadas ausentes.

Governança

Fundamental.

LGPD.

GDPR.

Auditoria.

RBAC.

IAM.

Policies.

Approval Gates.


Quem aprovou?

Quem executou?

Quem auditou?

Quem pagou?

Quem autorizou?


Infraestrutura

GPU.

TPU.

CPU.

OpenShift.

Kubernetes.

IBM z17.

LinuxONE.

Cloud.


O IBM Z Sempre Esteve Preparado

Talvez a maior surpresa seja esta.

IBM Z nunca esteve distante da IA.

Ele apenas utilizava nomes diferentes.

IA ModernaIBM Z
WorkflowJES2
ObservabilidadeRMF
LogsSMF
SegurançaRACF
APIsz/OS Connect
EventosMQ
SchedulerIWS
GovernançaSAF
CI/CDDBB
MemóriaDb2
AgentesServiços especializados
Inferênciawatsonx

O Conselho Final para um Padawan COBOL

Se você está começando agora, não tente aprender tudo.

Estude em etapas.

Etapa 1

Entenda LLMs.

GPT.

Claude.

Embeddings.

RAG.


Etapa 2

Aprenda LangGraph.

CrewAI.

n8n.


Etapa 3

Entenda MLOps.

MLFlow.

Observabilidade.


Etapa 4

Integre Mainframe.

MQ.

z/OS Connect.

Db2.


Etapa 5

Construa agentes.

Agente COBOL.

Agente JCL.

Agente Db2.

Agente CICS.


O Holocron Final

Durante anos ouvimos que o Mainframe era uma tecnologia do passado.

Em 2026 começamos a perceber algo curioso.

A indústria inteira está reconstruindo conceitos que os profissionais IBM Z já conheciam muito bem:

  • Orquestração;

  • Governança;

  • Observabilidade;

  • Segurança;

  • Processamento confiável;

  • Execução transacional;

  • Gestão de workloads;

  • Auditoria completa.

A IA moderna não está eliminando o conhecimento dos veteranos do IBM Z.

Ela está valorizando exatamente aquilo que sempre diferenciou os melhores arquitetos de mainframe: a capacidade de pensar em ecossistemas complexos, sistemas resilientes, processos críticos e plataformas que funcionam vinte e quatro horas por dia sem margem para erros.

Talvez o futuro não pertença apenas aos construtores do maior modelo de linguagem.

Talvez pertença aos velhos Jedi do IBM Z que finalmente descobriram que seus holocrons sempre falaram sobre agentes, apenas utilizando nomes diferentes.

terça-feira, 2 de junho de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Para Transformar um Chatbot em um Verdadeiro Ambiente de Engenharia de Software com Inteligência Artificial

 

Bellacosa Mainframe e 100 dicas do claude em uma pagina

☕ Um Café no Bellacosa Mainframe 

100 Dicas do Claude em Uma Página

O Que Todo Programador COBOL Padawan Precisa Saber Para Transformar um Chatbot em um Verdadeiro Ambiente de Engenharia de Software com Inteligência Artificial

"A maioria das pessoas conversa com uma IA. Os profissionais que realmente aumentam sua produtividade trabalham em parceria com ela."  


Introdução

Quando surgiram os primeiros assistentes de Inteligência Artificial, a maioria das pessoas acreditava que eles seriam apenas uma versão mais sofisticada de um mecanismo de busca.

Você fazia uma pergunta.

Recebia uma resposta.

Fim da conversa.

Era quase como consultar um manual técnico digital.

Mas a evolução dos LLMs (Large Language Models) mostrou que esse pensamento estava incompleto.

Hoje, ferramentas como Claude, ChatGPT, Gemini e outras deixaram de ser apenas sistemas de perguntas e respostas. Elas estão se transformando em plataformas completas de desenvolvimento, capazes de compreender projetos inteiros, escrever código, revisar arquitetura, automatizar tarefas, conectar-se a sistemas externos e colaborar como verdadeiros membros de uma equipe de engenharia.

Recentemente, circulou um infográfico chamado "100 Claude Tips in One Page", reunindo cem dicas organizadas em dez categorias. À primeira vista, parece apenas uma lista de atalhos. No entanto, ao analisá-lo com atenção, percebemos algo muito maior: ele descreve uma nova forma de trabalhar com IA.

Para quem vem do universo IBM Mainframe, isso pode soar familiar.

Durante décadas aprendemos que escrever um programa COBOL era apenas uma pequena parte do trabalho. Antes dele existiam JCLs, bibliotecas, catálogos, RACF, CICS, DB2, schedulers, padrões corporativos e processos de mudança.

Da mesma forma, usar um LLM de maneira profissional envolve muito mais do que escrever um prompt.

Neste artigo vamos explorar cada uma dessas ideias sob a ótica de um Programador COBOL Padawan, criando paralelos entre a engenharia tradicional do IBM Z e a nova engenharia baseada em Inteligência Artificial.

Pegue seu café.

A conversa de hoje promete.


O erro que quase todo iniciante comete

Imagine um desenvolvedor júnior chegando ao ambiente z/OS e perguntando:

"Onde eu escrevo meu COBOL?"

O analista sorri e responde:

"Antes disso precisamos criar o dataset, definir o PROC, configurar o JCL, preparar as bibliotecas, verificar o compilador e garantir as permissões RACF."

O novato fica surpreso.

Ele pensava que programar era apenas escrever código.

Com IA acontece exatamente o mesmo.

A maioria das pessoas faz algo assim:

Explique Docker.

Recebe uma resposta.

Abre outra conversa.

Pergunta novamente.

Tudo começa do zero.

Isso equivale a reinicializar um mainframe antes de cada JOB.

É desperdício.

Os usuários avançados trabalham de maneira completamente diferente.


Conversar não é trabalhar

Existe uma enorme diferença entre conversar com uma IA e trabalhar utilizando IA.

Veja dois cenários.

Usuário comum

Pergunta

↓

Resposta

↓

Nova pergunta

↓

Nova resposta

Cada conversa é isolada.

Nada é reaproveitado.

Todo contexto precisa ser reconstruído.


Usuário avançado

Projeto

↓

Documentação

↓

Memória

↓

Arquivos

↓

Ferramentas

↓

MCP

↓

Claude Code

↓

Subagentes

↓

Resultado Final

Agora existe continuidade.

Existe contexto.

Existe engenharia.

Esse é exatamente o conceito por trás das 100 dicas do Claude.


Categoria 1 — Setup: Preparando o Ambiente

Todo programador Mainframe sabe que um bom ambiente vale mais do que horas de retrabalho.

Antes de executar um programa precisamos preparar:

  • Bibliotecas

  • DDNAMEs

  • Catálogos

  • PROCs

  • Variáveis

  • Ambientes de teste

  • Permissões

No Claude acontece algo semelhante.

A preparação inicial define toda a qualidade das respostas futuras.

Escolhendo o modelo correto

Nem toda tarefa exige o modelo mais poderoso.

É como escolher entre:

  • IEBGENER

  • DFSORT

  • IDCAMS

Todos resolvem problemas diferentes.

Da mesma forma:

Um modelo rápido pode resumir documentos.

Outro modelo mais inteligente pode projetar uma arquitetura distribuída.

Saber quando utilizar cada um é uma habilidade importante.


Memória

Um dos recursos mais interessantes.

A memória não serve para armazenar documentos.

Ela serve para armazenar preferências.

Por exemplo:

Sempre explique utilizando exemplos IBM Mainframe.

Utilize linguagem técnica.

Evite excesso de marketing.

Faça analogias com COBOL.

Após algum tempo, Claude passa a produzir respostas muito mais alinhadas ao seu estilo.

É como possuir um analista que já conhece seu jeito de trabalhar.


Projects

Imagine criar um projeto chamado:

Bellacosa Mainframe

Dentro dele existem:

COBOL

JCL

DB2

IMS

VSAM

REXX

CICS

RACF

Arquitetura

Normas

Documentação

Sempre que iniciar uma conversa nesse projeto, Claude já conhece todo esse universo.

É semelhante a abrir um PDS contendo toda a documentação corporativa.


Categoria 2 — Prompt Engineering

Prompt Engineering talvez seja o equivalente moderno da especificação funcional.

Quanto melhor a especificação...

Melhor será a implementação.

Considere dois exemplos.

Prompt simples

Explique CICS.

Resultado?

Uma resposta genérica.

Agora veja este.

Explique CICS para um programador COBOL de banco.

Compare com Batch.

Utilize diagramas ASCII.

Mostre vantagens.

Mostre limitações.

Inclua exemplos reais.

Finalize com um resumo executivo.

A diferença é enorme.


Definindo papéis

Uma técnica extremamente poderosa.

Você pode pedir:

Atue como:

Arquiteto IBM

Professor Universitário

Sysprog

DBA

Especialista DevOps

Especialista em Segurança

Cada persona muda completamente a forma da resposta.

É semelhante a pedir opiniões para profissionais diferentes dentro da mesma empresa.


Definindo restrições

Claude trabalha melhor quando possui limites claros.

Exemplo:

Até 800 palavras.

Português técnico.

Sem emojis.

Markdown.

Inclua tabelas.

Não invente informações.

Sempre cite vantagens e riscos.

Curiosamente, limitar produz respostas melhores.


Categoria 3 — Claude Code

Agora começamos a entrar no território da engenharia de software.

Claude Code não é apenas um editor.

Ele pode:

  • Ler projetos inteiros

  • Executar testes

  • Refatorar código

  • Criar documentação

  • Gerenciar Git

  • Atualizar dependências

Imagine dizer:

Leia este projeto.

Encontre duplicações.

Refatore.

Execute os testes.

Atualize README.

Faça commit.

Isso está muito além de responder perguntas.


Plan Mode

Uma funcionalidade fantástica.

Antes de alterar qualquer arquivo, Claude pode apresentar um plano.

Semelhante ao CAB (Change Advisory Board).

Primeiro ele analisa.

Depois identifica riscos.

Depois propõe mudanças.

Somente então executa.

Isso reduz bastante erros.


Categoria 4 — CLAUDE.md

Se existe um recurso que lembra o mundo corporativo, é este.

CLAUDE.md funciona como um conjunto permanente de normas.

Por exemplo:

Sempre escreva testes.

Nunca utilize jQuery.

Explique arquitetura.

Comente funções públicas.

Use TypeScript.

Priorize Clean Code.

É semelhante aos padrões corporativos existentes em grandes bancos.

Todo projeto passa a seguir as mesmas regras automaticamente.


Categoria 5 — Artifacts

Artifacts representam uma mudança de paradigma.

Antes:

Explique como criar um dashboard.

Agora:

Crie um dashboard funcional.

Em vez de responder...

Claude gera:

  • HTML

  • CSS

  • JavaScript

  • SVG

  • React

  • Mermaid

  • Diagramas

  • Simuladores

É como pedir um programa COBOL e receber também o JCL, a documentação e os testes.


Versionamento

Cada alteração cria versões.

Quase um Git interno.

Isso permite experimentar ideias sem medo.


Categoria 6 — MCP — Model Context Protocol

Talvez a inovação mais importante dos últimos anos.

MCP pode ser comparado aos drivers universais da IA.

Sem MCP:

Claude

↓

Texto

Com MCP:

Claude

↓

GitHub

↓

Google Drive

↓

SQL

↓

Filesystem

↓

Slack

↓

ERP

↓

CRM

↓

APIs

Agora Claude deixa de conversar.

Ele passa a executar trabalho.


Pensando como um profissional IBM

Imagine um MCP para:

  • SDSF

  • JES2

  • RMF

  • SMF

  • DB2

  • IMS

  • CICS

  • RACF

Você poderia perguntar:

Qual JOB falhou ontem?

Mostre o LOG.

Analise o ABEND.

Explique a causa.

Sugira correções.

O potencial é gigantesco.


Categoria 7 — Cowork e Agentes

Aqui a IA deixa de ser individual.

Imagine criar especialistas.

Agente 1

Arquiteto

Agente 2

Programador COBOL

Agente 3

DBA DB2

Agente 4

Especialista RACF

Agente 5

Revisor Técnico

Todos colaborando.

É praticamente uma equipe virtual.


Categoria 8 — Power User

Chegamos ao nível avançado.

Aqui encontramos recursos que poucos usuários exploram.

Subagentes

Em vez de uma IA resolver tudo sozinha...

Ela divide o problema.

Projeto

↓

Arquitetura

↓

Backend

↓

Frontend

↓

Testes

↓

Documentação

↓

Integração

Cada agente trabalha de forma especializada.

Depois os resultados são consolidados.

Isso lembra muito o paralelismo do IBM Z.


Hooks

Hooks funcionam como gatilhos.

Sempre que determinada ação ocorrer...

Outra ação é executada automaticamente.

Exemplo:

Salvar código

↓

Executar testes

↓

Atualizar documentação

↓

Verificar segurança

↓

Executar lint

↓

Atualizar CHANGELOG

É automação pura.


A filosofia por trás das 100 dicas

O maior ensinamento desse infográfico não é ensinar comandos.

É ensinar mentalidade.

A pergunta deixa de ser:

"Como faço uma pergunta melhor?"

E passa a ser:

"Como construo um ambiente onde a IA trabalhe continuamente ao meu lado?"

Essa mudança é profunda.


Paralelos com o IBM Mainframe

Vamos resumir essa comparação.

IBM MainframeClaude
JCLPrompt estruturado
PROCTemplates
DatasetContexto
PDSProjects
SYSINPrompt
JES2Orquestração
SchedulerAutomação
RACFPermissões
DB2Conhecimento estruturado
UtilitiesFerramentas
Change ManagementPlan Mode
Normas CorporativasCLAUDE.md
Equipe TécnicaAgentes

Perceba que praticamente todos os conceitos clássicos continuam existindo.

Mudou apenas a interface.

Agora ela é conversacional.


O impacto para um Programador COBOL Padawan

Durante muitos anos ouvimos que o COBOL seria substituído.

Depois disseram que o Mainframe desapareceria.

Mais recentemente, passaram a afirmar que a Inteligência Artificial substituiria os programadores.

Nenhuma dessas previsões se concretizou da forma anunciada.

O que realmente aconteceu foi uma evolução das ferramentas.

Assim como um compilador COBOL evoluiu, os ambientes de desenvolvimento evoluíram e os pipelines de integração contínua se tornaram padrão, os LLMs estão se tornando mais uma camada da engenharia de software.

Para o Programador COBOL Padawan, isso representa uma oportunidade extraordinária.

Imagine acelerar tarefas como:

  • geração de documentação técnica;

  • explicação de programas legados;

  • criação de casos de teste;

  • revisão de código COBOL;

  • análise de JCLs;

  • conversão de layouts Copybook para JSON;

  • criação de APIs REST para sistemas CICS;

  • preparação de apresentações técnicas;

  • produção de artigos, treinamentos e material didático.

A IA não elimina o conhecimento do especialista. Pelo contrário, amplia sua capacidade de produzir e compartilhar conhecimento.

Quem domina fundamentos de arquitetura, modelagem de dados, sistemas transacionais e processos críticos — características típicas do ecossistema IBM Z — possui uma vantagem significativa ao trabalhar com essas novas ferramentas. Afinal, a IA precisa de contexto, critérios e boas decisões, e esses elementos continuam sendo responsabilidade do profissional.


Conclusão — O verdadeiro diferencial está na engenharia, não na ferramenta

As "100 Claude Tips" são muito mais do que uma coleção de atalhos. Elas representam um mapa de maturidade para quem deseja extrair valor real da Inteligência Artificial.

No início, usamos a IA como uma calculadora sofisticada.

Depois, como um mecanismo de busca conversacional.

Em seguida, como um assistente de programação.

Mas o próximo passo já está acontecendo: transformar a IA em um ambiente integrado de engenharia, capaz de compreender projetos, seguir padrões corporativos, colaborar com equipes, acessar ferramentas externas, automatizar processos e participar ativamente do ciclo de desenvolvimento.

Para quem vive o universo IBM Mainframe, essa evolução não é estranha. Há décadas trabalhamos com orquestração, padronização, bibliotecas compartilhadas, controle de mudanças, segurança, automação e integração entre sistemas. Os conceitos permanecem os mesmos; o que muda é a interface, agora baseada em linguagem natural.

O Programador COBOL Padawan que compreender essa mudança deixará de enxergar o Claude apenas como um chatbot. Passará a vê-lo como um novo membro da equipe: um analista que nunca se cansa de revisar código, um arquiteto que ajuda a avaliar alternativas, um redator técnico incansável, um testador disciplinado e um parceiro de aprendizado contínuo.

No fim das contas, o maior segredo não está em conhecer as cem dicas individualmente. Está em entender que elas formam um ecossistema. Memória, Projects, Prompt Engineering, Claude Code, CLAUDE.md, Artifacts, MCP, Agentes e automações são peças de uma mesma arquitetura.

E arquiteturas bem projetadas sempre foram a especialidade dos profissionais de Mainframe.

Talvez seja por isso que nós, veteranos do IBM Z, estejamos tão bem posicionados para liderar essa nova era da Inteligência Artificial.

Porque, no fundo, continuamos fazendo o que sempre fizemos: projetar sistemas confiáveis, organizar conhecimento e transformar complexidade em soluções elegantes. A diferença é que, agora, temos um novo colega de trabalho sentado ao nosso lado — e ele atende pelo nome de Claude.

segunda-feira, 1 de junho de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Full Fine-Tuning, LoRA, QLoRA, SFT, DPO e RLHF na Era da Inteligência Artificial

 

Bellacosa Mainframe e o fine tuning de llm

☕ Um Café no Bellacosa Mainframe

Fine-Tuning de LLMs Descomplicado

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Full Fine-Tuning, LoRA, QLoRA, SFT, DPO e RLHF na Era da Inteligência Artificial

"No Mainframe aprendemos cedo que não se recompila um sistema bancário inteiro para corrigir uma única regra de negócio. Então por que tantas pessoas fazem exatamente isso com modelos de Inteligência Artificial?" 


Introdução

Se você trabalha há algum tempo com IBM Mainframe, provavelmente já participou de alguma situação parecida.

O banco precisava alterar apenas uma regra tributária.

A alteração estava concentrada em um único programa COBOL.

Mesmo assim alguém sugeriu:

"Vamos recompilar tudo."

A reação de qualquer analista experiente seria imediata.

Para quê?

Afinal, recompilar centenas de programas significa consumir CPU, aumentar riscos, gerar mais testes, envolver homologação, aumentar o tempo de deploy e, principalmente, criar possibilidades de novos erros.

No mundo dos Large Language Models (LLMs), acontece exatamente a mesma coisa.

Muitos profissionais ouvem falar em Fine-Tuning e imaginam que exista apenas uma maneira de "ensinar" algo novo para uma IA.

Na prática, existem diversas estratégias.

Algumas alteram bilhões de parâmetros.

Outras modificam apenas alguns milhões.

Outras nem sequer alteram o modelo.

É exatamente essa diferença que separa projetos de milhares de dólares de projetos que podem ser treinados em uma única GPU doméstica.

Neste café vamos entender toda essa arquitetura utilizando comparações que fazem muito sentido para quem já viveu anos trabalhando com COBOL, CICS, DB2, VSAM e JCL.

Pegue seu café.

Hoje vamos abrir a tampa do motor da Inteligência Artificial.


Antes de falar em Fine-Tuning precisamos entender um Transformer

Imagine um programa COBOL enorme.

Não estamos falando de 3.000 linhas.

Imagine um sistema bancário com:

  • milhares de programas

  • centenas de COPYBOOKs

  • dezenas de módulos

  • chamadas CICS

  • SQL para DB2

  • VSAM

  • MQ

  • APIs REST

Agora imagine que tudo isso fosse compactado em um único conjunto gigantesco de matrizes matemáticas.

Esse conjunto é o modelo.

Um Transformer moderno possui dezenas ou centenas de camadas (Layers).

Visualmente podemos imaginar algo assim:

Entrada

↓

Embedding

↓

Layer 1

↓

Layer 2

↓

Layer 3

↓

...

↓

Layer 80

↓

Saída

Cada Layer possui milhões de parâmetros.

Juntos eles representam o conhecimento aprendido.


O que são parâmetros?

Se você nunca estudou Redes Neurais, imagine um enorme arquivo VSAM contendo bilhões de pequenos números.

Cada número representa um ajuste aprendido durante o treinamento.

Exemplo:

0.834829

↓

0.834841

A diferença parece insignificante.

Mas quando bilhões desses valores são alterados ao mesmo tempo...

O comportamento inteiro do modelo muda.

Esses números são chamados de pesos (weights).

Treinar uma IA significa simplesmente alterar esses pesos.

Nada mais.

Nada menos.


Pense como um Programador COBOL

Imagine um sistema bancário.

Você possui:

  • Programa COBOL

  • COPYBOOKS

  • CICS

  • DB2

  • JCL

Agora alguém pede:

"Ensine esse sistema a emitir PIX internacional."

Você possui diversas opções.

Pode alterar somente um COPYBOOK.

Pode alterar apenas um módulo.

Pode criar um novo programa.

Ou pode reescrever absolutamente tudo.

No universo dos LLMs acontece exatamente a mesma coisa.


O espectro do Fine-Tuning

Muitos iniciantes acreditam que Fine-Tuning é uma técnica.

Na realidade ele é um conjunto de técnicas.

Podemos organizar assim:

Prompt Engineering

↓

RAG

↓

SFT

↓

LoRA

↓

QLoRA

↓

Full Fine-Tuning

↓

DPO

↓

RLHF

Quanto mais descemos...

Maior o custo.

Maior o consumo de GPU.

Maior a complexidade.

Maior o tempo de treinamento.


Prompt Engineering

É a primeira ferramenta.

E curiosamente...

É a mais barata.

Você não altera absolutamente nada no modelo.

É como escrever uma JCL melhor.

O programa continua exatamente igual.

Você apenas fornece instruções mais inteligentes.

Exemplo:

Você é um especialista em COBOL IBM Enterprise COBOL 6.5.

Explique COMP-3.

Utilize exemplos bancários.

Responda em português.

Nenhum parâmetro foi alterado.

Nenhum peso foi modificado.

Mesmo assim a qualidade melhora bastante.


RAG

Agora imagine outra situação.

Seu programa COBOL precisa consultar um novo cadastro.

Você faria o quê?

Reescreveria todo o sistema?

Claro que não.

Bastaria consultar um novo banco de dados.

É exatamente isso que faz o RAG.

Pergunta

↓

Busca documentos

↓

Envia ao LLM

↓

Resposta

O modelo continua congelado.

Quem muda é apenas o conhecimento disponível durante a consulta.

Por isso dizemos:

RAG adiciona memória.

Não inteligência.


Quando NÃO devemos fazer Fine-Tuning

Esse talvez seja o maior erro da indústria.

Imagine que sua empresa possui:

  • manuais

  • normas

  • PDFs

  • contratos

  • documentação interna

Alguém diz:

"Vamos treinar um LLM com tudo isso."

Provavelmente está desperdiçando dinheiro.

RAG resolve praticamente todos esses casos.


Full Fine-Tuning

Agora chegamos ao método clássico.

Todos os parâmetros são atualizados.

Visualmente:

Layer 1

Treina

↓

Layer 2

Treina

↓

Layer 3

Treina

↓

...

↓

Layer N

Treina

Nada permanece congelado.

Tudo muda.


Por que isso é tão caro?

Vamos imaginar um modelo de 70 bilhões de parâmetros.

Todos eles precisarão:

  • armazenar gradientes

  • calcular derivadas

  • atualizar pesos

  • salvar checkpoints

Isso exige dezenas de GPUs profissionais.

Em muitos casos:

Centenas.


Analogia Mainframe

É como recompilar:

  • COBOL

  • PL/I

  • Natural

  • CICS

  • MQ

  • DB2

  • JCL

  • COPYBOOKS

Tudo.

Mesmo que apenas um programa precisasse mudar.

Faz sentido?

Na maioria das vezes...

Não.


Onde Full Fine-Tuning ainda faz sentido?

Modelos médicos.

Modelos militares.

Modelos científicos.

Modelos jurídicos extremamente especializados.

Ou quando estamos criando um novo modelo base.

Fora isso...

Existem alternativas melhores.


A Revolução Chamada LoRA

Em 2021 surgiu uma ideia brilhante.

E se...

Em vez de alterar bilhões de parâmetros...

Nós adicionássemos pequenas correções?

Foi exatamente isso que o artigo LoRA propôs.

O modelo original permanece intacto.

Quem aprende são pequenos adaptadores.


Visualmente:

Modelo Original

↓

Congelado

+

Adaptadores

↓

Aprendem

O que significa Low Rank?

Aqui entra um pouco de matemática.

Imagine uma matriz enorme:

4096 x 4096

Em vez de aprender tudo isso...

LoRA aprende duas matrizes muito menores.

4096 x 16

+

16 x 4096

A multiplicação das duas aproxima a alteração necessária.

Resultado?

Muito menos parâmetros.

Muito menos memória.

Muito menos GPU.


Analogia COBOL

Imagine um programa de 40.000 linhas.

Você não altera tudo.

Você cria uma rotina adicional.

Algo parecido com um módulo externo.

Na execução...

O sistema utiliza:

Programa Original

Nova Rotina

Essa nova rotina corresponde ao adaptador LoRA.


Vantagens do LoRA

Economia.

Rapidez.

Facilidade.

Possibilidade de possuir dezenas de especializações diferentes para o mesmo modelo.

Imagine um único Llama.

E vários LoRAs.

Llama

↓

LoRA Jurídico

↓

LoRA Médico

↓

LoRA COBOL

↓

LoRA DevOps

↓

LoRA SAP

Todos compartilham exatamente o mesmo modelo base.


QLoRA

Agora vem outra inovação.

E se...

Além de congelar o modelo...

Nós comprimíssemos sua memória?

É isso que faz o QLoRA.

O modelo base é armazenado em apenas 4 bits.

Mas atenção.

Esse é um detalhe extremamente importante.

Os adaptadores continuam treinando normalmente em maior precisão, como FP16 ou BF16.

Isso evita perda excessiva de qualidade durante o aprendizado.


Quantização

Imagine uma fotografia.

Original:

16 milhões de cores.

Depois:

256 cores.

Ela ocupa muito menos espaço.

Com os modelos acontece algo semelhante.

Menos bits.

Menos memória.

Mais eficiência.


Analogia Mainframe

É como compactar um dataset utilizando um formato extremamente eficiente.

O conteúdo continua disponível.

Mas ocupa muito menos disco.


SFT – Supervised Fine-Tuning

Aqui começamos a ensinar comportamento.

Não conhecimento.

A diferença é enorme.

Imagine um professor.

Ele entrega:

Pergunta.

Resposta correta.

Pergunta.

Resposta correta.

Pergunta.

Resposta correta.

O modelo aprende imitando.

Exemplo:

Pergunta

Explique VSAM.

↓

Resposta ideal.

↓

Treinamento.

Onde usamos SFT?

Chatbots corporativos.

Assistentes técnicos.

Documentação.

Atendimento.

Programação.

Explicações.

Tudo isso normalmente começa com SFT.


DPO – Direct Preference Optimization

Imagine que existam duas respostas.

Resposta A.

Resposta B.

Um especialista diz:

"A ficou muito melhor."

O DPO aprende exatamente isso.

Ele não precisa calcular recompensas complexas.

Ele apenas aprende qual saída deve ser preferida.

É extremamente elegante.


Analogia COBOL

Imagine dois programas.

Os dois compilam.

Os dois executam.

Mas apenas um segue corretamente a especificação do banco.

O DPO aprende a favorecer esse comportamento.


RLHF

Agora chegamos ao método mais sofisticado.

Reinforcement Learning from Human Feedback.

O fluxo é enorme.

Modelo

↓

Respostas

↓

Humanos avaliam

↓

Reward Model

↓

PPO

↓

Novo treinamento

Existe inclusive um segundo modelo.

O Reward Model.

Ele aprende a dar notas.

Depois outro algoritmo utiliza essas notas para melhorar o modelo principal.

É poderoso.

Mas extremamente caro.


Por que DPO ficou tão popular?

Porque elimina boa parte dessa complexidade.

Em muitos cenários.

SFT + DPO produz resultados muito próximos ao RLHF.

Com muito menos custo.


O maior erro das empresas

Muitas organizações ainda pensam assim:

Preciso melhorar o modelo.

↓

Fine-Tuning.

Essa pergunta está errada.

A pergunta correta é:

"O que realmente precisa mudar?"

Talvez apenas o prompt.

Talvez apenas o RAG.

Talvez um LoRA.

Talvez um SFT.

Talvez nenhum treinamento.


O que a imagem não mostra

O universo de PEFT (Parameter Efficient Fine-Tuning) vai muito além do LoRA.

Hoje existem técnicas como:

  • AdaLoRA

  • DoRA

  • IA³

  • Prefix Tuning

  • Prompt Tuning

  • P-Tuning v2

  • VeRA

  • LoKr

  • LoHa

  • OFT

  • BOFT

Todas elas têm o mesmo objetivo:

Treinar menos.

Aprender mais.

Consumir menos GPU.


Misturando Adaptadores

Outra grande vantagem.

Você pode carregar múltiplos adaptadores.

Imagine:

Modelo Base

↓

LoRA Financeiro

↓

LoRA RH

↓

LoRA Jurídico

↓

LoRA Mainframe

Dependendo da tarefa...

Você ativa apenas o adaptador correspondente.

É como carregar módulos diferentes em uma aplicação COBOL sem alterar o núcleo do sistema.


Catastrophic Forgetting

No Full Fine-Tuning existe um risco importante.

Ao aprender demais um novo domínio...

O modelo pode esquecer conhecimentos antigos.

É o chamado Catastrophic Forgetting.

Como o LoRA preserva o modelo original congelado, esse problema tende a ser muito menor.


O Futuro

A tendência da indústria é clara.

Pouquíssimas empresas treinam modelos gigantes do zero.

A maioria utiliza modelos abertos como:

  • Llama

  • Mistral

  • Qwen

  • Gemma

  • DeepSeek

Depois aplica:

  • Prompt Engineering

  • RAG

  • LoRA

  • QLoRA

  • SFT

  • DPO

Conseguindo resultados excelentes com custos muito menores.


O Café do Bellacosa ☕

Quando comecei minha carreira em Mainframe, aprendi uma lição que continua verdadeira décadas depois.

O melhor engenheiro não é aquele que modifica mais código.

É aquele que modifica apenas o necessário.

Essa filosofia aparece em praticamente tudo que fazemos em TI.

No COBOL, evitamos recompilar aplicações inteiras para uma pequena mudança de negócio.

No DB2, preferimos ajustar um índice ou um plano de acesso antes de reescrever consultas complexas.

No CICS, alteramos uma transação ou um programa específico, não toda a região.

No z/OS, aplicamos um PTF em vez de reinstalar o sistema operacional.

Na Inteligência Artificial, a lógica é exatamente a mesma.

Nem todo problema exige Full Fine-Tuning.

Nem todo projeto precisa de RLHF.

Muitas vezes, um bom Prompt Engineering resolve o problema. Em outras, um RAG bem construído fornece o conhecimento necessário. Quando o desafio é adaptar o comportamento do modelo, LoRA ou QLoRA costumam oferecer uma relação extraordinária entre custo e benefício. Se o objetivo é ensinar exemplos de respostas ideais, o SFT é o caminho natural. E quando precisamos alinhar preferências de forma eficiente, o DPO surge como uma alternativa elegante ao complexo pipeline do RLHF.

O verdadeiro arquiteto de IA não escolhe a ferramenta mais sofisticada.

Escolhe a ferramenta mais adequada.

Assim como um bom programador COBOL sabe que nem toda alteração exige recompilar milhares de programas, um bom engenheiro de IA entende que o segredo não está em treinar mais, mas em treinar melhor.

No fim das contas, Fine-Tuning não é uma única técnica. É um conjunto de estratégias, cada uma com objetivos, custos e impactos diferentes. Compreender o que realmente está sendo atualizado dentro do modelo é a diferença entre um projeto sustentável e um desperdício de GPUs, tempo e dinheiro.

E talvez essa seja a maior lição deste café: a evolução da Inteligência Artificial não elimina os princípios da Engenharia de Software que aprendemos no Mainframe. Pelo contrário, ela os reforça. Planejamento, eficiência, reutilização, modularidade e otimização continuam sendo as bases dos grandes sistemas — apenas mudaram de cenário.

Porque, seja ajustando um programa COBOL em um IBM Z ou adaptando um LLM de bilhões de parâmetros, a pergunta continua a mesma:

"O que realmente precisa ser alterado?"

Quando você sabe responder a essa pergunta, deixa de apenas usar Inteligência Artificial e passa a projetá-la com a mesma disciplina e maturidade que fizeram do Mainframe a plataforma mais confiável da história da computação.

terça-feira, 21 de abril de 2026

AI Chatbots, AI Agents e Multi-Agent Systems O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Próxima Revolução da Engenharia de Software

 

Bellacosa Mainframe AI chatbos agents e multi-agents systems

☕ Um Café no Bellacosa Mainframe

AI Chatbots, AI Agents e Multi-Agent Systems

O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Próxima Revolução da Engenharia de Software

"Você não está apenas aprendendo Inteligência Artificial. Está descobrindo como os sistemas do futuro serão construídos — e, curiosamente, como eles se parecem muito mais com um IBM Mainframe do que a maioria das pessoas imagina."

Durante muitos anos ouvimos que a Inteligência Artificial substituiria programadores, escreveria software sozinha e transformaria completamente a indústria. Grande parte dessas previsões eram exageradas. O que realmente está acontecendo é muito mais interessante.

A verdadeira revolução não está em criar uma IA que saiba fazer tudo.

Ela está em criar equipes de inteligências artificiais, cada uma especializada em uma função específica, trabalhando em conjunto exatamente como acontece em uma empresa ou, para nossa surpresa, exatamente como acontece dentro de um ambiente IBM z/OS.

Se você é um Programador COBOL Padawan, este é um daqueles momentos em que compreender um conceito novo pode mudar completamente sua maneira de enxergar a tecnologia.

E a boa notícia?

Você já conhece, sem perceber, muitos dos princípios que sustentam essa nova geração de IA.


A primeira ilusão da Inteligência Artificial

Quando o ChatGPT surgiu, muita gente imaginou que havia nascido um cérebro artificial.

Parecia existir uma única inteligência capaz de responder qualquer pergunta.

Na realidade, um chatbot tradicional funciona de maneira relativamente simples.

O fluxo costuma ser:

Usuário

↓

Prompt

↓

LLM

↓

Resposta

O usuário faz uma pergunta.

O modelo analisa os tokens.

Prediz a sequência mais provável.

Entrega uma resposta.

Fim.

Não existe uma equipe trabalhando.

Não existe divisão de tarefas.

Não existe planejamento complexo.

É uma conversa extremamente sofisticada, mas ainda assim linear.


O chatbot é um excelente especialista... mas continua sozinho

Imagine que você pergunte:

"Explique como funciona um arquivo VSAM KSDS."

O chatbot responde.

Agora pergunte:

"Escreva um programa COBOL utilizando CICS, DB2, MQ, autenticação RACF, documentação técnica, casos de teste, scripts DevOps e um pipeline CI/CD."

Ele tentará fazer tudo.

Mas existe um problema.

Está tentando atuar simultaneamente como:

  • Analista de Sistemas

  • Arquiteto

  • DBA

  • Programador COBOL

  • Especialista CICS

  • Especialista MQ

  • Especialista em Segurança

  • Analista de Testes

  • Redator Técnico

  • DevOps

Nenhum profissional faz tudo isso perfeitamente.

Nem um modelo de IA.


Imagine uma empresa com apenas um funcionário

Vamos fazer uma analogia.

Imagine abrir um banco.

Você contrata apenas uma pessoa.

Ela deverá ser:

  • Presidente

  • Caixa

  • Segurança

  • Auditor

  • Contador

  • Analista de Crédito

  • Atendimento

  • TI

  • Limpeza

Parece absurdo.

Mas foi exatamente assim que imaginamos a Inteligência Artificial durante algum tempo.

Uma única IA faria absolutamente tudo.

O problema é que especialização sempre vence generalização quando o assunto é trabalho complexo.


É aqui que nascem os AI Agents

Agora imagine outro cenário.

Você continua tendo uma IA extremamente inteligente.

Mas ela aprende uma habilidade nova.

Ela não apenas responde.

Ela começa a agir.

Ela consegue:

  • planejar

  • pesquisar

  • acessar APIs

  • consultar bancos de dados

  • executar programas

  • validar resultados

  • corrigir erros

  • tentar novamente

Ela passa a perseguir objetivos.

Isso muda completamente o jogo.


Um agente pensa em etapas

Vamos imaginar um pedido simples.

"Analise o desempenho do meu banco DB2."

Um chatbot responderia algo como:

"Verifique índices, RUNSTATS, REORG..."

Um AI Agent faria algo diferente.

Ele poderia executar automaticamente um fluxo como este:

Receber objetivo

↓

Conectar ao catálogo DB2

↓

Ler estatísticas

↓

Analisar índices

↓

Verificar tabelas fragmentadas

↓

Comparar histórico

↓

Gerar relatório

↓

Sugerir melhorias

Observe a diferença.

Ele deixou de responder.

Agora ele trabalha.


O cérebro continua sendo um LLM

Muitas pessoas imaginam que um AI Agent seja um modelo completamente diferente.

Não é.

O cérebro continua sendo um Large Language Model.

A diferença é que agora existe uma arquitetura em volta dele.

Ela adiciona capacidades como:

  • memória

  • ferramentas

  • planejamento

  • execução

  • observação

  • replanejamento

É como instalar diversos periféricos em um computador.

O processador continua sendo o mesmo.

Mas agora ele possui discos, rede, impressoras e dispositivos externos.


Um agente utiliza ferramentas

Pense em você.

Você não resolve tudo apenas pensando.

Você utiliza ferramentas.

No Mainframe você usa:

  • ISPF

  • SDSF

  • TSO

  • DB2 SPUFI

  • File Manager

  • Fault Analyzer

  • Abend-AID

Da mesma forma, um agente utiliza ferramentas digitais.

Ele pode chamar:

  • APIs REST

  • Bancos SQL

  • Python

  • Shell Script

  • GitHub

  • Docker

  • Navegadores

  • Serviços MCP (Model Context Protocol)

O LLM passa a ser apenas o cérebro que decide qual ferramenta utilizar.


Mas a verdadeira revolução ainda estava por vir

Mesmo um agente possui limitações.

Imagine pedir:

"Modernize um sistema COBOL com oito milhões de linhas."

É uma tarefa gigantesca.

Existe muito trabalho.

Então surge uma pergunta natural.

Por que colocar tudo nas costas de um único agente?

Por que não criar uma equipe?

Nasce então o conceito de Multi-Agent Systems.


Bem-vindo ao escritório da Inteligência Artificial

Agora imagine um escritório.

Em vez de uma única IA...

Existem várias.

Cada uma extremamente especializada.

             Orquestrador

      ↓       ↓       ↓

 COBOL     DB2      CICS

      ↓       ↓       ↓

 Segurança   Testes   APIs

             ↓

      Documentação

Pela primeira vez, a IA começa a funcionar como uma empresa.


O papel do Orquestrador

Toda equipe precisa de alguém coordenando.

Na arquitetura Multi-Agent existe normalmente um componente chamado Orchestrator.

Ele funciona como um gerente de projetos.

Recebe um objetivo.

Analisa.

Divide.

Distribui.

Depois reúne os resultados.

Seu trabalho não é escrever código.

Seu trabalho é organizar pessoas...

Ou melhor...

Organizar agentes.


Parece familiar?

Se você trabalha com Mainframe, provavelmente sim.

Veja alguns componentes do z/OS.

  • JES2

  • RACF

  • DB2

  • IMS

  • CICS

  • MQ

  • DFSMS

  • WLM

Nenhum deles faz tudo.

Cada um possui responsabilidades muito claras.

O sistema operacional coordena todos.

Curiosamente, a arquitetura Multi-Agent segue exatamente essa filosofia.


IBM já fazia isso há décadas

Muita gente acredita que Multi-Agent Systems são uma invenção recente.

Na prática, a computação corporativa utiliza esse conceito desde os anos 70.

Pense em uma transação bancária.

Quando um cliente faz um PIX ou consulta saldo, vários subsistemas trabalham em conjunto:

  • CICS recebe a requisição.

  • RACF autentica o usuário.

  • DB2 consulta os dados.

  • MQ envia mensagens para outros sistemas.

  • JES2 agenda tarefas em batch.

  • WLM distribui recursos de CPU.

  • DFSMS gerencia armazenamento.

Nenhum desses componentes conhece todo o sistema.

Cada um é especialista em sua área.

Essa divisão de responsabilidades é um dos pilares da escalabilidade do IBM Z.

Os sistemas multiagentes apenas transportam essa filosofia para o universo da IA.


Um exemplo para um Programador COBOL Padawan

Imagine que um banco deseje transformar um sistema legado em APIs REST.

Um ambiente multiagente poderia funcionar assim:

Agente 1 — Descoberta

Analisa milhões de linhas COBOL.

Identifica programas.

Mapeia COPYBOOKs.


Agente 2 — Banco de Dados

Localiza tabelas DB2.

Descobre relacionamentos.

Analisa índices.


Agente 3 — CICS

Detecta transações.

Analisa COMMAREAs.

Mapeia Channels e Containers.


Agente 4 — Documentação

Produz diagramas.

Cria documentação técnica.

Explica regras de negócio.


Agente 5 — APIs

Transforma programas em serviços REST.

Gera especificações OpenAPI.


Agente 6 — Testes

Cria testes unitários.

Executa validações.

Produz cobertura de testes.


Agente 7 — Segurança

Analisa autenticação.

Detecta vulnerabilidades.

Sugere melhorias.


Observe que ninguém faz tudo.

Cada agente faz apenas aquilo em que é especialista.


O conceito de Inteligência Coletiva

Um dos maiores erros ao estudar IA é imaginar inteligência como algo individual.

Na natureza, muitos organismos demonstram inteligência coletiva.

Formigas.

Abelhas.

Cupins.

Cardumes.

Nenhum indivíduo conhece o plano completo.

Mesmo assim, a colônia produz comportamentos extraordinários.

Os sistemas multiagentes seguem esse princípio.

Cada agente possui conhecimento limitado.

Mas o conjunto resolve problemas extremamente complexos.


Comunicação entre agentes

Surge então outro desafio.

Como essas inteligências conversam?

A resposta depende da arquitetura.

Algumas utilizam mensagens JSON.

Outras empregam filas como Apache Kafka ou RabbitMQ.

Há ainda sistemas baseados em eventos, chamadas REST e protocolos emergentes como o Model Context Protocol (MCP), que facilita o compartilhamento de contexto e ferramentas entre modelos.

Essa comunicação precisa ser eficiente, confiável e segura.

Caso contrário, os agentes passam mais tempo trocando informações do que resolvendo problemas.


Quando os agentes discordam

Outro aspecto fascinante é que agentes podem divergir.

Imagine três especialistas analisando uma consulta SQL.

O primeiro sugere criar um índice.

O segundo afirma que uma reorganização resolveria o problema.

O terceiro recomenda alterar o plano de acesso.

Quem está certo?

Em sistemas avançados, outro agente pode atuar como árbitro, comparar evidências, executar testes e escolher a melhor solução.

Esse mecanismo reduz vieses e melhora a qualidade das decisões.


Mais agentes significam mais inteligência?

Nem sempre.

Adicionar agentes indiscriminadamente pode gerar:

  • custos maiores com tokens;

  • aumento da latência;

  • conflitos de decisão;

  • duplicação de trabalho;

  • dificuldade de coordenação.

Assim como uma empresa com funcionários demais pode se tornar burocrática, um sistema multiagente mal projetado pode ser menos eficiente do que um único agente bem configurado.

Arquitetura continua sendo essencial.


O futuro do desenvolvimento de software

Imagine abrir seu ambiente de desenvolvimento daqui a alguns anos.

Você descreve uma funcionalidade:

"Criar um novo módulo de empréstimos."

Imediatamente, um orquestrador distribui tarefas:

  • um agente conversa com os analistas de requisitos;

  • outro gera o modelo de dados;

  • um terceiro escreve programas COBOL;

  • outro prepara JCLs;

  • um agente cria testes automatizados;

  • outro verifica segurança;

  • outro produz documentação;

  • um último acompanha a implantação.

Você deixa de trabalhar sozinho com uma IA e passa a liderar uma equipe digital de especialistas.

O desenvolvedor torna-se um arquiteto e coordenador, capaz de definir objetivos, validar resultados e integrar soluções.


O Programador COBOL Padawan não está ficando para trás

Existe um mito de que apenas quem desenvolve aplicações em linguagens modernas participará dessa transformação.

Nada poderia estar mais distante da realidade.

Os maiores bancos, seguradoras, empresas aéreas e governos do mundo continuam executando processos críticos em IBM Z. São ambientes ricos em regras de negócio, documentação histórica e sistemas integrados — exatamente o tipo de contexto em que agentes especializados podem gerar enorme valor.

Conhecer COBOL, CICS, JCL, DB2, VSAM e arquitetura de sistemas corporativos passa a ser um diferencial estratégico, porque esses agentes precisam de especialistas humanos para orientar sua evolução, validar decisões e definir políticas de governança.


Uma nova trilha de conhecimento

Se você deseja se preparar para essa nova era, considere construir uma trilha de aprendizado como esta:

  1. Domine os fundamentos de algoritmos e estruturas de dados.

  2. Aprofunde seus conhecimentos em COBOL, JCL, CICS e DB2.

  3. Estude APIs REST e integração entre sistemas.

  4. Aprenda conceitos de Large Language Models e Engenharia de Prompts.

  5. Explore arquiteturas de AI Agents.

  6. Conheça frameworks como LangGraph, CrewAI, AutoGen e OpenAI Agents SDK.

  7. Entenda protocolos de integração como MCP.

  8. Estude observabilidade, segurança e governança para sistemas de IA.

  9. Pratique a orquestração de múltiplos agentes em problemas reais.

  10. Desenvolva a habilidade mais importante de todas: pensar em sistemas, não apenas em programas.


Conclusão

A história da computação sempre caminhou em direção à especialização e à colaboração. Primeiro vieram os programas monolíticos, depois os sistemas distribuídos, os microsserviços e, agora, os Sistemas Multiagentes.

Para o Programador COBOL Padawan, essa não é uma ruptura com o passado, mas uma continuidade natural. Quem compreende como CICS, DB2, MQ, RACF, JES2 e z/OS colaboram para manter milhões de transações funcionando diariamente já possui uma base conceitual surpreendentemente próxima da lógica dos agentes de IA.

A próxima geração de software não será construída por uma única inteligência artificial onisciente. Ela será resultado da cooperação entre diversas inteligências especializadas, coordenadas por arquiteturas capazes de planejar, executar, validar e aprender continuamente.

E talvez a maior ironia dessa revolução seja esta: enquanto muitos acreditam que a IA está inventando uma forma completamente nova de computação, os profissionais de Mainframe podem reconhecer nela um velho conhecido. Há décadas, o IBM Z nos ensina que sistemas robustos nascem da colaboração entre componentes especializados, governados por uma arquitetura sólida e por princípios de engenharia bem estabelecidos.

Você não está apenas estudando Inteligência Artificial. Está ampliando sua visão sobre a evolução da engenharia de software e descobrindo que, no futuro, o profissional mais valioso não será aquele que compete com a IA, mas aquele que sabe construir, coordenar e orientar equipes inteiras de inteligências artificiais para resolver problemas que, sozinho, nenhum modelo conseguiria enfrentar.

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