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

sábado, 7 de dezembro de 2024

Stargate Copilot — O dia em que o programador COBOL atravessou o portal da IA corporativa

 

Bellacosa Mainframe e o ms copilot para devs cobol

☕ Um Café no Bellacosa Mainframe

Stargate Copilot — O dia em que o programador COBOL atravessou o portal da IA corporativa

Ou: você entrou achando que Microsoft Copilot era um sujeito que resumiria sua reunião no Teams e descobriu do outro lado do portal agentes, Graph, Fabric, APIs, identidade, governança, Power Automate e um velho programa COBOL esperando tranquilamente no CICS

Imagine a cena.

Você é um jovem programador COBOL.

Ainda está naquele estágio saudável da carreira em que olha para:

IDENTIFICATION DIVISION.
PROGRAM-ID. XPTO001.

e sente uma mistura de respeito, curiosidade e uma pequena vontade de perguntar:

— Mas por que diabos isso começa com um parágrafo dizendo o nome do programa se eu já sei o nome do programa?

Calma.

Você ainda verá coisas muito mais estranhas.

Um belo dia alguém da arquitetura chega com uma imagem gigantesca chamada:

MICROSOFT COPILOT ECOSYSTEM

Na imagem aparecem Power Platform, Power BI, Copilot Studio, Entra ID, Purview, Defender, Dynamics, OneDrive, SharePoint, Teams, Microsoft Fabric, OneLake, Azure AI, GitHub Copilot, Azure DevOps, Bing, Edge, Logic Apps, Functions, SQL e uma quantidade de logotipos suficiente para fazer um programador COBOL procurar discretamente a tecla PF3.

Não aperte PF3 ainda.

Porque existe uma maneira curiosamente simples de entender tudo isso.

E, ironicamente, quem conhece mainframe talvez tenha mais facilidade do que muita gente imagina.

Pegue um café.

Ative o chevron.

Hoje vamos atravessar o Stargate da IA corporativa.



🌌 1. O primeiro erro: achar que Copilot é “o ChatGPT da Microsoft”

Foi assim que muita gente conheceu a coisa.

Abriu o Word:

“Copilot, melhore este texto.”

Abriu o Outlook:

“Resuma esta conversa.”

Entrou no Teams:

“O que aconteceu na reunião enquanto eu estava fingindo que prestava atenção?”

Abriu o PowerPoint:

“Crie uma apresentação.”

Muito útil.

Mas isso corresponde apenas à primeira camada.

Podemos representar assim:

USUÁRIO
   |
   v
COPILOT
   |
   v
RESPOSTA

Você pergunta.

Ele responde.

Fim.

É o equivalente cognitivo de um programa batch extremamente simples:

INPUT
  |
PROCESS
  |
OUTPUT

Para uma primeira experiência é ótimo.

Mas a Microsoft está construindo algo muito maior ao redor dessa ideia.

O ponto central é:

Copilot não deve ser entendido apenas como um produto. Ele está se transformando numa interface para um ecossistema empresarial de IA.

E isso muda completamente a arquitetura.



🌀 2. Chevron 1 locked: produtividade

No primeiro planeta encontramos o Microsoft 365 Copilot.

Word.

Excel.

PowerPoint.

Outlook.

Teams.

SharePoint.

OneDrive.

É o planeta mais confortável porque o humano continua no comando.

Ele pergunta:

“Resuma os emails de hoje.”

O sistema procura contexto.

Um modelo gera uma resposta.

E o humano decide o que fazer.

A lógica ainda é:

HUMANO
   |
   v
PERGUNTA
   |
   v
IA
   |
   v
RESPOSTA
   |
   v
HUMANO EXECUTA

Isso é produtividade assistida.

Pode economizar cinco minutos.

Pode economizar meia hora.

Pode economizar algumas horas por semana.

Excelente.

Mas ainda não transformamos o processo.

Mudamos apenas a produtividade de uma etapa.

É a diferença entre colocar um compilador COBOL mais rápido e redesenhar toda a cadeia de processamento.



🧠 3. O Microsoft Graph: o MALP enviado antes da equipe

Quem assistia a Stargate SG-1 lembra do MALP.

Antes de mandar O’Neill, Carter, Daniel Jackson e Teal’c atravessarem alegremente um buraco de minhoca para um planeta onde poderia haver Goa’uld esperando do outro lado, enviava-se uma pequena máquina.

Ela verificava o terreno.

Atmosfera.

Ambiente.

Imagens.

Possíveis problemas.

O Microsoft Graph cumpre uma função vagamente comparável dentro da história do Copilot: ajuda a fornecer contexto organizacional.

Quando você pergunta:

“O que ficou decidido sobre o Projeto X?”

a resposta pode depender de:

  • emails;

  • documentos;

  • reuniões;

  • calendários;

  • arquivos;

  • conversas;

  • conteúdo no SharePoint;

  • informações disponíveis ao usuário.

O Microsoft 365 Copilot usa grounding e o Microsoft Graph para enriquecer a solicitação com contexto relevante. E há uma regra fundamental: o acesso continua limitado às permissões do usuário autenticado.

Isso merece atenção.

Copilot não significa:

SELECT *
FROM EMPRESA;

Significa algo mais parecido com:

SELECT INFORMACAO
FROM ORGANIZACAO
WHERE USUARIO_TEM_PERMISSAO = TRUE;

Pelo menos conceitualmente.

E o jovem COBOL pode reconhecer imediatamente a importância disso.

Porque uma coisa é saber responder.

Outra completamente diferente é saber a que dados você pode ter acesso para responder.



🔎 4. Grounding: evitando mandar a IA explorar Abydos com um mapa de Marte

Um modelo de linguagem possui conhecimento geral.

Mas a sua empresa possui conhecimento específico.

Imagine perguntar:

“Qual foi a decisão sobre o projeto Phoenix?”

Para um modelo genérico isso significa aproximadamente nada.

Phoenix pode ser:

  • projeto de software;

  • cliente;

  • sistema interno;

  • codinome;

  • tabela;

  • incidente;

  • nome do gato do diretor.

O grounding adiciona contexto.

Conceitualmente:

PROMPT ORIGINAL
"Qual foi a decisão sobre Phoenix?"
        |
        v
RECUPERAÇÃO DE CONTEXTO
        |
        +--> email
        +--> Teams
        +--> documento
        +--> reunião
        |
        v
PROMPT ENRIQUECIDO
        |
        v
LLM
        |
        v
RESPOSTA CONTEXTUAL

É uma diferença enorme.

Sem grounding:

IA sabe coisas.

Com grounding:

IA sabe coisas e consegue relacionar sua pergunta ao contexto autorizado da organização.

Esse é um dos pilares da IA corporativa.



📚 5. A grande biblioteca onde ninguém sabe onde guardou nada

Toda empresa grande possui uma versão da mesma tragédia.

Existe um documento importante.

Em algum lugar.

Talvez no SharePoint.

Talvez no OneDrive.

Talvez num email.

Talvez numa pasta chamada:

FINAL

dentro de:

FINAL_V2

dentro de:

FINAL_V2_AGORA_VAI

dentro de:

FINAL_V2_AGORA_VAI_CORRIGIDO_JOSE_3

A IA empresarial tenta transformar esse caos documental em conhecimento pesquisável.

Daí entram recursos de pesquisa semântica, Graph, índices e sistemas de recuperação.

Pesquisa tradicional pergunta:

“Onde aparece exatamente a palavra XPTO?”

Pesquisa semântica tenta chegar mais perto de:

“Que documentos estão falando aproximadamente sobre aquilo que o usuário quer saber?”

Para um programador COBOL isso é uma mudança semelhante a sair de:

SEARCH STRING

para:

SEARCH MEANING

Não é mágica.

É recuperação de informação + representação semântica + contexto + ranking + segurança.

Mas para o usuário parece mágica.



☠️ 6. A armadilha: Copilot também encontra sua bagunça mais depressa

Agora entra uma das melhores pegadinhas dessa arquitetura.

Considere:

CONTRATO_CONFIDENCIAL.PDF

Por algum erro histórico, José possui acesso.

José jamais descobriu isso.

O documento está enterrado em um SharePoint de 2017.

Logo:

falha existe
+
ninguém percebe
=
aparente tranquilidade

Então chega uma IA capaz de pesquisar profundamente os dados aos quais José já possui acesso.

José pergunta:

“Quais contratos mencionam aquisição da Empresa Y?”

E aparece justamente aquilo.

O Copilot não necessariamente criou o problema.

O problema já existia.

A IA simplesmente colocou um holofote em cima dele.

Por isso uma frase merece entrar na parede do datacenter:

IA transforma dívida de governança em dívida operacional visível.

Purview, políticas de dados, classificação de informação e revisão de permissões deixam de ser acessórios.

Viraram pré-requisitos.

A própria arquitetura Microsoft reforça que o Copilot respeita o escopo de acesso do usuário e que serviços como Purview e controles do SharePoint fazem parte da estratégia de segurança e governança.



🔐 7. Entra ID: “Jaffa, kree!” mas com autenticação multifator

Agora chegamos à identidade.

Em sistemas empresariais você jamais deveria começar perguntando:

“O que esta aplicação consegue fazer?”

Primeiro pergunte:

“Quem é você?”

Depois:

“O que você tem autorização para fazer?”

Entra ID ocupa parte importante dessa função no ecossistema Microsoft.

Tradicionalmente pensávamos em identidades como:

HUMANOS
APLICAÇÕES
SERVICE ACCOUNTS
WORKLOADS

Mas agentes de IA criaram uma nova criatura.

AGENT

Se um agente puder:

  • consultar dados;

  • chamar uma API;

  • alterar CRM;

  • criar um pedido;

  • acionar outro agente;

  • executar um workflow;

então precisamos responder:

Quem é ele?

Quem criou?

Quem é responsável?

O que pode acessar?

Em nome de quem trabalha?

Quando sua autorização termina?

Como auditamos tudo?

A Microsoft já possui Microsoft Entra Agent ID para autenticação, autorização, governança e auditoria de identidades de agentes.

Aqui começa algo fascinante:

EMPRESA DE 2030?

40.000 humanos
3.000 aplicações
1.000 service accounts
70.000 agentes

Não sei se os números serão exatamente esses.

Mas a direção arquitetural é essa:

agentes tornam-se uma nova população digital corporativa.



🤖 8. Chevron 2: de Copilot para Agent

Aqui atravessamos a fronteira importante.

Copilot clássico:

HUMANO
   |
   v
PROMPT
   |
   v
RESPOSTA

Agente:

OBJETIVO
   |
   v
AGENT
   |
   +--> consulta conhecimento
   |
   +--> escolhe ferramenta
   |
   +--> executa ação
   |
   +--> interpreta resultado
   |
   +--> continua

E agente autônomo adiciona outra diferença:

não precisa necessariamente esperar uma pergunta.

Pode existir um evento.

Por exemplo:

FATURA VENCIDA
      |
      v
TRIGGER
      |
      v
AGENTE

A documentação atual do Copilot Studio descreve agentes autônomos capazes de reagir a eventos, decidir e executar tarefas dentro de permissões, limites e guardrails definidos.

Portanto passamos de:

Prompt-driven AI

para:

Event-driven AI

Programador COBOL veterano neste momento começa a sorrir.

Porque evento disparando processamento?

Isso não parece inteiramente extraterrestre.


 

⚙️ 9. Power Automate: o braço mecânico do robô

Imagine uma inteligência fabulosa que diz:

“Descobri que precisamos bloquear o cartão.”

Excelente.

Agora bloqueie.

Silêncio.

O modelo sabe o que deveria acontecer, mas não necessariamente possui uma operação capaz de fazer aquilo.

É aí que entram ferramentas, flows, conectores, APIs e automações.

No Copilot Studio, agent flows podem ser usados como ferramentas que agentes chamam durante execução para recuperar informações ou realizar ações. Esses fluxos podem ser disparados manualmente, por eventos, agentes ou agenda.

Exemplo:

AGENT
  |
  | "preciso verificar crédito"
  v
FLOW
  |
  +--> GET CUSTOMER
  +--> CHECK CREDIT
  +--> GET DEBT
  +--> UPDATE CRM
  +--> SEND NOTIFICATION

Agora o agente ganhou mãos.


🧮 10. A lição mais importante para o COBOLero: não deixe o LLM fazer o trabalho do programa

Esta vale ouro.

Imagine:

“Calcule os juros desta operação financeira de R$ 72 milhões conforme regra contratual XYZ.”

Você pode pedir ao modelo para improvisar.

Ou pode ser um adulto responsável.

A arquitetura correta tende a separar:

LLM
|
| interpreta intenção
|
v
FUNÇÃO DETERMINÍSTICA
|
| calcula
|
v
RESULTADO

Algo como:

AGENT:
"Precisamos calcular juros."

        |
        v

CALCULAR-JUROS

        |
        v

COBOL / JAVA / FUNCTION / API

        |
        v

VALOR EXATO

Isso é particularmente bonito porque agent flows são apresentados pela Microsoft como determinísticos: regras definidas, caminho previsível, entradas iguais produzindo o mesmo comportamento esperado.

Então guarde:

LLM interpreta. Programa calcula.

Claro que existem exceções.

Mas como regra mental para iniciante, é excelente.

Você não substitui determinismo por probabilidade só porque probabilidade virou moda.


🧱 11. Aqui o jovem programador percebe que COBOL não morreu outra vez

Agora chegamos ao portal favorito do Bellacosa Mainframe.

Um gerente entra no Teams e pergunta:

“Por que a operação do cliente ABC foi recusada?”

Vamos montar um cenário possível.

MICROSOFT TEAMS
      |
      v
COPILOT
      |
      v
AGENT
      |
      +--> CRM
      |
      +--> SharePoint
      |
      +--> Fabric
      |
      v
POWER AUTOMATE / API
      |
      v
API MANAGEMENT
      |
      v
z/OS CONNECT
      |
      v
CICS
      |
      v
COBOL
      |
      v
Db2

Observe cuidadosamente.

O mainframe não desapareceu.

O COBOL não desapareceu.

O CICS não desapareceu.

O Db2 não desapareceu.

Eles mudaram de posição na experiência.

O usuário talvez nunca veja uma tela 3270.

Mas lá embaixo:

EXEC CICS LINK

continua trabalhando tranquilamente.

Essa é a grande lição para quem está começando em COBOL:

Modernização não significa necessariamente substituição. Muitas vezes significa exposição, integração e composição.

O velho programa pode virar uma capacidade empresarial acessível através de API.


🏛️ 12. System of Engagement versus System of Record

Essa distinção ajuda demais.

Imagine:

Teams
Copilot
Web
Mobile

como systems of engagement.

São os lugares nos quais humanos interagem.

E:

CICS
IMS
Db2
Core banking
ERP

como systems of record.

São lugares onde a transação séria acontece.

Então:

EXPERIENCE
    |
    v
INTELLIGENCE
    |
    v
ORCHESTRATION
    |
    v
INTEGRATION
    |
    v
SYSTEM OF RECORD

Essa arquitetura não elimina legado.

Ela transforma legado em serviço consumível.


🧵 13. Microsoft Fabric: o planeta dos dados

Agora entra Fabric.

A organização possui dados espalhados:

CRM
ERP
financeiro
produção
telemetria
logs
vendas
clientes
estoque

Durante décadas construímos algo parecido:

DADOS
  |
  v
ETL
  |
  v
DATA WAREHOUSE
  |
  v
BI
  |
  v
DASHBOARD
  |
  v
HUMANO

Apareceu uma bolinha vermelha.

O analista observa.

Liga para alguém.

Abre ticket.

Manda email.

Esperamos.

Com agentes, podemos começar a pensar:

DADOS
  |
  v
FABRIC
  |
  v
MODELO SEMÂNTICO
  |
  v
INSIGHT
  |
  v
AGENTE
  |
  v
INVESTIGA
  |
  v
PROPÕE AÇÃO
  |
  v
APROVAÇÃO
  |
  v
EXECUTA

O dashboard deixa de ser necessariamente o último ponto do processo.

Vira um sensor.


🚨 14. Power BI vê fumaça; agente chama os bombeiros

Exemplo simples.

Um dashboard detecta:

VENDAS -35%
REGIÃO SUL
PRODUTO XPTO

No modelo tradicional:

alerta
 |
 v
gerente vê amanhã
 |
 v
manda email
 |
 v
analista investiga

Modelo agentic possível:

ALERTA
   |
   v
AGENT
   |
   +--> consulta estoque
   +--> consulta preço
   +--> consulta incidentes
   +--> consulta campanhas
   |
   v
"causa provável:
erro de preço após atualização"
   |
   v
cria incidente
   |
   v
notifica responsável

Se a política permitir:

solicita correção

Se a política não permitir:

AGUARDA HUMANO

A diferença é brutal.


🧯 15. Nunca confunda inteligência com autoridade

Aqui está uma regra fundamental.

PODE PENSAR
   !=
PODE LER

PODE LER
   !=
PODE ALTERAR

PODE ALTERAR
   !=
PODE APROVAR

PODE APROVAR
   !=
PODE EXECUTAR QUALQUER COISA

Um agente pode concluir:

“A melhor ação seria estornar R$ 2 milhões.”

Isso não significa que deveria poder executar:

ESTORNAR 2000000

sozinho.

Arquitetura madura:

AGENTE RACIOCINA
       |
       v
POLÍTICA
       |
       v
VALIDAÇÃO DETERMINÍSTICA
       |
       v
APROVAÇÃO HUMANA
       |
       v
TRANSAÇÃO
       |
       v
AUDITORIA

O objetivo não é construir um Goa’uld financeiro com acesso irrestrito ao core banking.


👮 16. Purview, Defender e segurança: porque os Replicators também automatizavam muito bem

Há algo que todo fã de Stargate deveria respeitar.

Automação sem controle pode escalar uma pequena bobagem até ela começar a comer a galáxia.

Os Replicators eram, afinal, extremamente eficientes.

O mesmo vale para agentes.

Um humano pode levar quinze minutos para cometer um erro.

Um agente pode realizar centenas de ações antes de alguém dizer:

“Espera. Quem autorizou isso?”

Por isso precisamos:

  • identidade;

  • least privilege;

  • auditoria;

  • classificação;

  • políticas;

  • segregação de funções;

  • limites;

  • human-in-the-loop;

  • observabilidade.

A velocidade da automação multiplica tanto o benefício quanto o erro.


🛰️ 17. Observabilidade: precisamos inventar o SMF dos agentes

E aqui o mainframeiro encontra terreno conhecido.

No z/OS nós gostamos de registros.

SMF.

RMF.

JES.

SYSLOG.

CICS logs.

Db2 traces.

Porque quando alguém pergunta:

“O que aconteceu às 03:17?”

não podemos responder:

“A máquina teve um sentimento.”

Precisamos reconstruir o ocorrido.

Agora imagine:

AGENT A
  |
  v
AGENT B
  |
  v
FLOW
  |
  v
API
  |
  v
CICS
  |
  v
DB2

Algo saiu errado.

Precisamos saber:

qual evento iniciou?
qual contexto foi recuperado?
qual modelo respondeu?
qual ferramenta foi escolhida?
quais parâmetros foram enviados?
qual identidade executou?
qual permissão foi usada?
qual API foi chamada?
qual RC voltou?
o agente tentou novamente?
qual decisão final tomou?

Pronto.

Nasceu o conceito:

SMF para agentes.

Não precisa ser literalmente SMF.

Mas filosoficamente é exatamente isso.

O livro-caixa da atividade digital.


💥 18. O S0C7 cognitivo

O velho COBOL conhece:

S0C7
S0C4
Uxxxx
SQLCODE
RESP
RESP2
RETURN-CODE

Agora chegam novos primos:

GROUNDING FAILURE
TOOL NOT FOUND
PERMISSION DENIED
TIMEOUT
HALLUCINATED PARAMETER
AGENT LOOP
CONTEXT OVERFLOW
POLICY VIOLATION
CONNECTOR FAILURE

A produção não deixou de ser produção porque colocamos IA nela.

Ao contrário.

Ficou mais interessante.

E talvez mais perigosa.


🛠️ 19. GitHub Copilot: não é só completar MOVE

Outro erro comum:

“GitHub Copilot serve para escrever código mais depressa.”

Serve.

Mas isso é apenas a camada superficial.

Imagine o SDLC:

REQUISITO
   |
   v
DESIGN
   |
   v
CÓDIGO
   |
   v
TESTE
   |
   v
REVIEW
   |
   v
SECURITY
   |
   v
CI/CD
   |
   v
PRODUÇÃO
   |
   v
OPERAÇÃO

Se você mede somente:

linhas geradas por IA

está olhando um pedaço pequeno.

Perguntas melhores:

Quanto caiu o tempo para implementar mudança?

Quantos defeitos chegam à produção?

Quanto aumentou cobertura de teste?

Quanto tempo leva code review?

Quanto conhecimento de sistema legado pode ser recuperado?

Agora imagine um programa COBOL de 9.000 linhas sem documentação.

Um assistente pode ajudar a:

  • explicar parágrafos;

  • sugerir testes;

  • encontrar possíveis dependências;

  • gerar documentação inicial;

  • explicar copybooks;

  • comparar versões;

  • criar exemplos de chamada.

Mas nunca esqueça:

a IA pode ajudar a ler o programa; não significa que compreendeu perfeitamente quarenta anos de regra de negócio escondida ali.

O comentário:

* CALCULA TAXA ESPECIAL

talvez tenha sido escrito em 1998 por alguém que já se aposentou.

E “especial” pode significar absolutamente qualquer coisa.


🧪 20. Laboratório para o jovem COBOLero

Vamos montar mentalmente um pequeno projeto.

Objetivo:

usuário pergunta o saldo de uma conta através de um agente.

Temos um programa legado:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. GETSALDO.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       01 WS-SALDO      PIC S9(11)V99 COMP-3.

       PROCEDURE DIVISION.

           PERFORM CONSULTAR-CONTA
           GOBACK.

Obviamente simplificado.

Queremos chegar a:

"Qual o saldo da conta 123?"

Arquitetura:

COPILOT
   |
   v
AGENT
   |
   v
GET-ACCOUNT-BALANCE TOOL
   |
   v
API
   |
   v
z/OS CONNECT
   |
   v
CICS
   |
   v
GETSALDO
   |
   v
DB2

A resposta volta:

DB2
 |
 v
COBOL
 |
 v
API
 |
 v
AGENT
 |
 v
"Saldo disponível: R$ 4.327,18"

Agora acrescente segurança:

USER
 |
 v
ENTRA
 |
 v
AUTHORIZATION
 |
 v
AGENT

Depois governança:

Pode consultar saldo? SIM
Pode transferir? NÃO
Pode consultar outra conta? DEPENDE

Depois auditoria:

WHO
WHEN
WHAT
ACCOUNT
ACTION
RESULT

Pronto.

Você acabou de atravessar boa parte do ecossistema sem precisar decorar 47 logotipos.


📐 21. Pense em camadas, não em produtos

Essa é uma das melhores dicas deste artigo.

Não tente memorizar:

Power alguma coisa, Fabric alguma coisa, Copilot não sei o quê.

Pense em função arquitetural.

┌─────────────────────────────┐
│ EXPERIÊNCIA                 │
│ Teams / Word / Outlook      │
├─────────────────────────────┤
│ IA / AGENTES                │
│ Copilot / Copilot Studio    │
├─────────────────────────────┤
│ ORQUESTRAÇÃO / AUTOMAÇÃO    │
│ Power Automate / Logic Apps │
├─────────────────────────────┤
│ CONHECIMENTO / DADOS        │
│ Graph / Fabric / Search     │
├─────────────────────────────┤
│ INTEGRAÇÃO                  │
│ APIs / Connectors           │
├─────────────────────────────┤
│ SYSTEMS OF RECORD           │
│ CICS / IMS / Db2 / ERP      │
└─────────────────────────────┘

IDENTIDADE → Entra
GOVERNANÇA → Purview
SEGURANÇA  → Defender
AUDITORIA  → Logs / telemetry

Os produtos mudarão.

Os nomes mudarão.

Marketing inventará mais três nomes antes de você terminar o café.

As funções arquiteturais permanecem muito mais estáveis.


📈 22. Cinco níveis de maturidade

Uma forma prática de analisar empresas:

Nível 1 — Assistente

HUMANO → COPILOT → RESPOSTA

Exemplo:

“Resuma esta reunião.”


Nível 2 — Conhecimento

HUMANO
  |
COPILOT
  |
DADOS ORGANIZACIONAIS

Exemplo:

“O que decidimos sobre o Cliente XPTO?”


Nível 3 — Ação

HUMANO
  |
AGENT
  |
TOOL
  |
SISTEMA

Exemplo:

“Abra um chamado.”


Nível 4 — Orquestração

AGENT
 |
 +--> FINANCE AGENT
 +--> CRM AGENT
 +--> LEGAL AGENT
 +--> ERP AGENT

Exemplo:

“Prepare o onboarding do fornecedor.”


Nível 5 — Processo autônomo controlado

EVENT
 |
 v
AGENT
 |
 v
DECISION
 |
 v
TOOLS
 |
 v
POLICY
 |
 v
HUMAN APPROVAL WHEN REQUIRED
 |
 v
TRANSACTION
 |
 v
AUDIT

Nesse ponto não estamos mais discutindo “um chatbot”.

Estamos falando de:

um processo empresarial instrumentado por IA.


💰 23. ROI: pare de contar emails escritos

Organizações no nível 1 perguntam:

“Quantos minutos economizamos escrevendo emails?”

Não está errado.

Mas é limitado.

Em níveis maiores procure:

TIME TO RESOLUTION
PROCESS CYCLE TIME
HUMAN TOUCHES
ERROR RATE
COST PER TRANSACTION
ESCALATION RATE
STRAIGHT-THROUGH PROCESSING
AGENT SUCCESS RATE

Imagine um processo.

Antes:

4 horas

Depois do Copilot:

3h40

Legal.

Mas automação agentic talvez permita:

4 horas
  |
  v
40 minutos
  |
  v
8 minutos
  |
  v
2 minutos

Aí já estamos falando de economia do processo.

Não de digitação.


🧟 24. O job zumbi também atravessou o Stargate

Toda empresa possui processos que ninguém sabe por que existem.

No mainframe:

JOBXPTO

roda todo domingo às 02:00 desde 1987.

Ninguém sabe exatamente por quê.

Mas ninguém tem coragem de desligar.

Agora imagine transformar processos ruins em agentes.

Você pode criar:

um agente zumbi.

Ele executa automaticamente uma regra sem sentido em velocidade fantástica.

Moral:

Automatizar porcaria produz porcaria automatizada.

Antes de agentificar um processo:

  1. descubra por que existe;

  2. elimine passos inúteis;

  3. documente regras;

  4. defina ownership;

  5. estabeleça controles;

  6. só então automatize.

Nunca coloque warp drive num carrinho com roda quadrada.

Sim, misturei Star Trek dentro de Stargate.

Esse é o Easter egg número dois.


🥷 25. Uma regra Bellacosa para começar

Para cada automação com IA faça seis perguntas:

1. QUEM?
2. O QUÊ?
3. COM QUAIS DADOS?
4. COM QUAL AUTORIDADE?
5. O QUE ACONTECE SE DER ERRADO?
6. ONDE ESTÁ O LOG?

Se alguém não conseguir responder uma delas, ainda não terminou a arquitetura.

Especialmente:

Onde está o log?

Porque a frase:

“A IA decidiu”

não serve como análise de incidente.


🧠 26. Curiosidade: estamos reinventando muita coisa velha

Toda nova onda tecnológica chega anunciando que tudo mudou.

E muda muita coisa mesmo.

Mas também reencontra problemas antigos.

Agentes precisam de:

  • fila;

  • prioridade;

  • identidade;

  • autorização;

  • isolamento;

  • timeout;

  • retries;

  • transação;

  • recuperação;

  • logs;

  • métricas;

  • governança;

  • capacity planning.

Um mainframeiro de 1985 observa a discussão moderna sobre agentes e pensa:

“Muito bonito. Agora me diga qual é o RC.”

Essa talvez seja a ponte cultural mais interessante entre mainframe e IA.

A tecnologia é nova.

Os problemas operacionais frequentemente não são.


🔁 27. Retry não pode significar “tente eternamente”

Imagine:

AGENT
 |
 v
API FAIL
 |
 v
RETRY
 |
 v
FAIL
 |
 v
RETRY
 |
 v
FAIL

Se você não definir limite, nasce a famosa:

espiral da formiga digital.

O agente insiste porque ninguém lhe explicou quando parar.

Em produção precisamos de:

MAX RETRIES
BACKOFF
TIMEOUT
CIRCUIT BREAKER
ESCALATION
DEAD LETTER

O equivalente cognitivo de:

IF RETRY-COUNT > 3
   PERFORM ABORT-PROCESS
END-IF

Persistência é virtude.

Loop infinito é incidente.


🧑‍✈️ 28. O’Neill pergunta a coisa simples que salva todo mundo

Samantha Carter pode explicar o wormhole.

Daniel Jackson traduz a inscrição.

Teal’c sabe que aquilo provavelmente é tecnologia Goa’uld.

Então Jack O’Neill pergunta:

“Isso explode?”

Todo projeto de IA precisa de alguém assim.

No meio de:

semantic grounding, multi-agent orchestration, autonomous workflow, vector retrieval...

alguém deve perguntar:

“Se o modelo responder errado, o que acontece?”

Essa pergunta vale mais que quinze slides.

Se a resposta for:

“Nada. O humano apenas recebe sugestão.”

Risco menor.

Se a resposta for:

“Ele transfere dinheiro.”

Temos outra conversa.


🧪 29. Passo a passo para estudar isso sem enlouquecer

Para o programador COBOL iniciante eu seguiria esta ordem:

Primeiro: domine o seu terreno.

Aprenda:

COBOL
JCL
Db2
CICS
VSAM
z/OS

Não abandone fundamento porque apareceu IA.

Segundo: aprenda HTTP e REST.

Entenda:

GET
POST
PUT
DELETE
JSON
status codes
authentication

É a ponte entre mundos.

Terceiro: aprenda APIs no z/OS.

Descubra como programas e transações podem ser expostos com segurança.

Quarto: entenda identidade.

OAuth.

Tokens.

Scopes.

Roles.

Least privilege.

Quinto: estude automação.

Flows.

Logic Apps.

Power Automate.

Mensageria.

Eventos.

Sexto: só então mergulhe em agentes.

Porque agente sem entender os sistemas abaixo vira mágica.

E engenheiro não pode operar produção baseado em mágica.


🗺️ 30. O mapa final do Stargate

Agora podemos desenhar tudo.

                     USER
                      |
                      v
             MICROSOFT 365
      Teams / Outlook / Word
                      |
                      v
              COPILOT / AGENT
                      |
           +----------+----------+
           |                     |
           v                     v
       KNOWLEDGE               TOOLS
           |                     |
     Graph / Search          Power Automate
     Fabric / Data           APIs / Flows
           |                     |
           +----------+----------+
                      |
                      v
                 INTEGRATION
                      |
                      v
          ENTERPRISE SYSTEMS
        SAP / CRM / MAINFRAME
                      |
                      v
             CICS / IMS / Db2
                      |
                      v
                   COBOL

Ao redor de tudo:

==================================
IDENTITY       = ENTRA
GOVERNANCE     = PURVIEW
SECURITY       = DEFENDER
OBSERVABILITY  = LOGS
POLICY         = GUARDRAILS
==================================

Agora aquela imagem gigantesca começa a parecer menos assustadora.


🏺 31. Easter egg — o programa que ninguém podia desligar

Existe uma antiga lenda no SGC.

Durante anos havia no mainframe um programa chamado:

SGC00042

Ninguém sabia quem escreveu.

Os comentários diziam apenas:

*> DO NOT REMOVE.
*> DANIEL SAYS IT IS IMPORTANT.

Toda madrugada:

//SGCJOB JOB ...
//STEP01 EXEC PGM=SGC00042

consumia 0,0001 MSU.

Um arquiteto decidiu modernizar.

Transformou em microserviço.

Colocou Kubernetes.

Service Mesh.

API Gateway.

Observabilidade.

Copilot.

Agente autônomo.

Vector Database.

O custo passou para US$ 17.000 por mês.

Depois de seis meses descobriram o que o programa fazia.

IF CHEVRON-COUNT = 7
   MOVE 'OPEN' TO GATE-STATUS
END-IF.

O programa voltou para o mainframe.

Ninguém comentou.

No relatório oficial escreveram:

Strategic workload repatriation.

O velho operador apenas tomou café.


☕ 32. A grande conclusão

Quando alguém disser:

“Microsoft Copilot é uma ferramenta de produtividade”

responda:

Sim.

Mas parecida com dizer:

“CICS é uma tela verde.”

A frase descreve aquilo que o usuário vê.

Não o sistema inteiro.

O ecossistema de Copilot está evoluindo para conectar:

HUMANOS
+
CONHECIMENTO
+
DADOS
+
MODELOS
+
AGENTES
+
WORKFLOWS
+
APIs
+
SISTEMAS
+
IDENTIDADE
+
SEGURANÇA
+
GOVERNANÇA

A unidade fundamental deixa gradualmente de ser:

PROMPT
   |
   v
ANSWER

e passa a poder ser:

EVENT
  |
  v
CONTEXT
  |
  v
REASONING
  |
  v
POLICY
  |
  v
ACTION
  |
  v
TRANSACTION
  |
  v
AUDIT
  |
  v
FEEDBACK

E aqui está talvez a conclusão mais importante para quem está começando agora em COBOL:

você não chegou atrasado.

Na realidade, está entrando numa profissão no momento em que dois mundos começam a se encontrar.

De um lado:

COBOL
CICS
Db2
IMS
JCL

sistemas construídos para serem previsíveis, transacionais, auditáveis e confiáveis.

Do outro:

LLMs
Copilots
Agents
Semantic Search
Natural Language

sistemas construídos para interpretar contexto, intenção e linguagem.

O futuro empresarial provavelmente não pertence exclusivamente a nenhum deles.

Pertence à composição:

probabilidade na interpretação, determinismo na transação.

A IA pergunta:

“O que o humano está tentando fazer?”

O agente decide:

“Qual capacidade devo chamar?”

A política pergunta:

“Ele pode?”

O COBOL responde:

“Passe os parâmetros corretamente e eu executo.”

O Db2 grava.

O log registra.

O auditor dorme.

E em algum lugar do datacenter um velho programa que nasceu quando Stargate SG-1 ainda passava na televisão recebe uma chamada REST, processa quinze milhões de dólares em menos de um segundo e volta:

RETURN-CODE = 0

O jovem programador olha para aquilo.

Olha para o Copilot.

Olha novamente para o COBOL.

E finalmente entende:

o Stargate nunca serviu para destruir o planeta antigo.

Servia para conectá-lo a outros mundos.

Chevron seven...

locked.

☕🌀

E o batch continua rodando.

https://eljefemidnightlunch.blogspot.com/2026/08/dick-vigarista-ia-e-o-concurso-pay-to.html

https://eljefemidnightlunch.blogspot.com/2026/08/organizacoes-tabajara-mainframe-seus.html

https://eljefemidnightlunch.blogspot.com/2026/08/dick-vigarista-ia-e-o-concurso-pay-to.html




segunda-feira, 29 de janeiro de 2024

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

 

Bellacosa Mainframe apresenta o MS Copilot

☕ Um Café no Bellacosa Mainframe

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

Ou: como GitHub Copilot, Microsoft 365 Copilot, Researcher, Analyst, Work IQ, Notebooks, Copilot Studio, agentes, testes, segurança e governança transformaram um autocomplete em uma pequena agência espacial corporativa — e por que ninguém no Gun Club apertaria ENTER antes de perguntar qual USERID estava autorizado a disparar o projétil

Há tecnologias que chegam anunciando uma revolução.

E há tecnologias que chegam discretamente, completando uma linha de código.

O Copilot pertence à segunda categoria.

Em 2021, a cena parecia quase inocente.

Um programador digitava:

IF WS-SALDO < ZERO

e uma inteligência artificial sugeria a continuação.

Nada particularmente ameaçador.

Era quase como ter um estagiário invisível sentado ao lado dizendo:

— Talvez você queira escrever PERFORM TRATA-ERRO.

Mas, assim como no romance Da Terra à Lua, de Júlio Verne, ninguém deveria subestimar homens muito determinados quando eles começam a discutir engenharia em uma sala fechada.

No romance, o Gun Club começa pensando em construir um canhão.

Depois alguém pergunta:

— E se atirássemos alguma coisa na Lua?

Pouco tempo depois estão calculando trajetória, pólvora, materiais, aceleração, local de lançamento e sobrevivência dos ocupantes.

Com o Copilot aconteceu algo curiosamente parecido.

Começamos perguntando:

“Você consegue completar minha função?”

Depois:

“Você consegue conversar sobre meu código?”

Em seguida:

“Consegue entender todo meu repositório?”

Logo apareceu:

“Consegue alterar vários arquivos?”

Depois:

“Consegue compilar?”

Então:

“Consegue executar os testes?”

Finalmente chegamos perigosamente perto de:

“Consegue receber uma tarefa, estudar o problema, modificar o sistema, testar, corrigir os erros e preparar o Pull Request enquanto eu tomo café?”

Barbicane, presidente do Gun Club, provavelmente interromperia a reunião neste momento.

— Senhores, antes de colocar três passageiros dentro desse projétil… quem autorizou o agente?

Bem-vindo ao Copilot moderno.

Prepare o café.

Hoje vamos da Terra à Lua.

Mas primeiro precisamos entender quem está segurando o fósforo.



1. Antes do foguete existia o autocomplete

Para compreender o Microsoft Copilot atual, precisamos voltar ao começo.

O primeiro grande Copilot da família foi o GitHub Copilot, anunciado em 2021.

Sua proposta original era relativamente simples:

PROGRAMADOR
     ↓
DIGITA CÓDIGO
     ↓
COPILOT OBSERVA
     ↓
SUGERE CONTINUAÇÃO

Quem já utilizou autocomplete tradicional poderia pensar:

— Então inventaram um autocomplete com esteroides.

Não exatamente.

Autocomplete tradicional normalmente funciona sobre estruturas conhecidas.

Por exemplo:

MOVE
PERFORM
DISPLAY
OPEN
CLOSE

A ferramenta conhece palavras-chave, variáveis, métodos ou APIs.

O GitHub Copilot começou a demonstrar uma capacidade diferente.

Ele conseguia considerar:

  • comentários;

  • código ao redor;

  • nomes de variáveis;

  • padrões;

  • funções anteriores;

  • intenção provável.

Se você escrevesse algo como:

* VALIDAR CPF DO CLIENTE

a IA poderia tentar produzir uma implementação.

Isso era impressionante.

Mas ainda havia um detalhe fundamental:

o Copilot sugeria.

Quem executava o trabalho continuava sendo o programador.

Era o equivalente ao Gun Club desenhando o projétil no quadro-negro.

O canhão ainda não havia sido carregado.



2. 2022 — o experimento vira produto

Em 2022, o GitHub Copilot tornou-se produto comercial.

Esse momento é importante porque muda o status da tecnologia.

Sai:

experiência curiosa

entra:

ferramenta diária de desenvolvimento

Programadores começam a utilizar IA como companheira real de codificação.

A expressão usada durante muito tempo foi:

AI pair programmer.

Ou seja:

programador em dupla com inteligência artificial.

Para um iniciante COBOL, imagine algo parecido com trabalhar ao lado de um programador mais experiente que observa você escrever:

       IF WS-CUSTOMER-STATUS = 'A'

e sugere:

           PERFORM PROCESS-ACTIVE-CUSTOMER
       ELSE
           PERFORM PROCESS-INACTIVE-CUSTOMER
       END-IF.

Só que aquele “programador” não entende negócios como um colega humano.

Ele calcula probabilidades.

Isso é importantíssimo.

Copilot não pensa:

“Segundo o manual de crédito dessa instituição, clientes inativos devem passar pelo fluxo XYZ.”

Ele pode inferir padrões a partir do contexto disponível.

E inferência não é regra de negócio.

Guarde isso.

Voltaremos a essa cápsula explosiva mais tarde.



3. 2023 — Barbicane decide que o projétil também precisa conversar

Em 2023 acontece uma expansão enorme.

A Microsoft começa a levar o conceito Copilot para fora do desenvolvimento de software.

Primeiro tivemos o Bing com IA.

Depois apareceu o Microsoft 365 Copilot.

Aqui ocorre a primeira transformação estrutural importante.

O modelo deixa de ser apenas:

PROMPT
   ↓
LLM
   ↓
RESPOSTA

e passa a se aproximar de:

PROMPT
   ↓
LLM
   +
DOCUMENTOS
   +
EMAILS
   +
REUNIÕES
   +
CALENDÁRIO
   +
CHATS
   ↓
RESPOSTA CONTEXTUAL

Eis o verdadeiro nascimento do Copilot corporativo.

Agora você poderia perguntar:

“Resuma tudo o que aconteceu no Projeto Apollo esta semana.”

Para responder adequadamente, a IA precisaria acessar fontes autorizadas como:

  • mensagens;

  • reuniões;

  • documentos;

  • apresentações;

  • planilhas;

  • e-mails.

Isso transforma completamente o problema.

O desafio deixa de ser apenas gerar linguagem.

Passa a ser:

encontrar o contexto correto.



4. Microsoft Graph — a cartografia antes do lançamento

Júlio Verne adorava mapas, cálculos e medições.

Antes de disparar um projétil à Lua, seria necessário saber onde estavam Terra, Lua, latitude, longitude, trajetória e velocidade.

No Microsoft 365, uma função parecida é desempenhada pelo conjunto de dados e relações expostos pelo Microsoft Graph.

O Graph conecta objetos corporativos como:

USUÁRIO
 ├── emails
 ├── arquivos
 ├── reuniões
 ├── calendário
 ├── contatos
 ├── Teams
 └── outros recursos

Imagine que você pergunte:

“O que ficou decidido sobre a migração do sistema COBOL?”

O modelo sozinho não sabe.

Ele precisa procurar evidências.

Talvez exista:

EMAIL
"migração aprovada"

ATA DA REUNIÃO
"aguardando orçamento"

PLANILHA
"status: pending"

TEAMS
"arquitetura ainda em avaliação"

Temos agora um problema muito mais interessante.

Não basta encontrar informação.

Precisamos interpretar conflitos.

É por isso que um bom prompt não deveria pedir apenas:

“Resuma o projeto.”

Melhor seria:

“Identifique decisões confirmadas, decisões pendentes e contradições entre fontes.”

Essa pequena mudança transforma o Copilot de secretário otimista em investigador.


5. 2023 — nasce o Copilot Studio

Aqui nossa história começa a ficar realmente verniana.

Imagine Barbicane dizendo:

— Não quero apenas utilizar o canhão. Quero construir meus próprios projéteis.

É aproximadamente essa a mudança representada pelo Copilot Studio.

Microsoft 365 Copilot é essencialmente algo que você utiliza.

Copilot Studio permite construir e customizar agentes.

Simplificando:

MICROSOFT 365 COPILOT
        ↓
UTILIZAR IA

COPILOT STUDIO
        ↓
CONSTRUIR SOLUÇÕES COM IA

Com ele você pode criar um agente que conheça:

  • determinados documentos;

  • APIs corporativas;

  • regras específicas;

  • ferramentas;

  • fluxos de trabalho;

  • fontes empresariais.

Por exemplo:

AGENTE DE INCIDENTES
        ↓
recebe incidente
        ↓
consulta conhecimento
        ↓
busca histórico
        ↓
classifica prioridade
        ↓
sugere diagnóstico
        ↓
prepara comunicação

Agora observe a mudança.

Um chatbot responde perguntas.

Um agente participa de um processo.


6. O que exatamente transforma um chatbot em agente?

Essa pergunta merece uma boa xícara.

Chatbot:

PERGUNTA
   ↓
RESPOSTA

Agente:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
ESCOLHA DE FERRAMENTAS
   ↓
EXECUÇÃO
   ↓
OBSERVAÇÃO DO RESULTADO
   ↓
NOVA DECISÃO

Exemplo de chatbot:

“Como identificar dados duplicados no Db2?”

Resposta:

SELECT ID_PEDIDO,
       COUNT(*)
FROM PEDIDOS
GROUP BY ID_PEDIDO
HAVING COUNT(*) > 1;

Pronto.

Agora imagine um agente:

“Descubra por que houve cobranças duplicadas ontem.”

Ele pode precisar:

1. localizar logs
2. consultar banco
3. identificar duplicidades
4. comparar timestamps
5. verificar retries da API
6. consultar alterações recentes
7. produzir hipótese
8. gerar relatório

Isso já é outra classe de sistema.


7. Researcher — Michel Ardan entra na biblioteca

Em 2025 surge o Researcher.

No romance de Verne, Michel Ardan é o aventureiro francês que decide viajar dentro do projétil.

Se existisse um Researcher naquela época, talvez ele perguntasse:

“Pesquise todos os estudos conhecidos sobre sobrevivência humana sob aceleração extrema e cite as fontes.”

Essa é exatamente a ideia.

Researcher foi pensado para pesquisas aprofundadas e multietapas.

Um prompt simples:

“Compare IBM Z e plataforma distribuída.”

pode produzir uma resposta comum.

Mas:

“Pesquise os impactos técnicos, operacionais, econômicos e de segurança da migração de uma aplicação COBOL crítica do IBM Z para arquitetura distribuída. Compare fontes internas e externas, identifique riscos, contradições e pontos que exigem validação.”

é uma missão de Researcher.

Sua lógica pode ser representada assim:

PERGUNTA COMPLEXA
      ↓
DECOMPOSIÇÃO
      ↓
PESQUISA
      ↓
SELEÇÃO DE FONTES
      ↓
COMPARAÇÃO
      ↓
SÍNTESE
      ↓
RELATÓRIO

O segredo aqui é multietapas.


8. Analyst — J. T. Maston encontra uma planilha

Barbicane fazia cálculos.

Maston provavelmente teria adorado Excel.

O Analyst entra na família Copilot para tarefas orientadas a dados.

Imagine fornecer:

INCIDENTES.XLSX
CPU.CSV
DEPLOYS.CSV
DB2-TIMES.CSV

e perguntar:

“Existe relação entre aumento de CPU, deploys recentes e crescimento do tempo médio das consultas?”

Isso exige algo diferente de resumo textual.

Precisamos:

dados
 ↓
limpeza
 ↓
análise
 ↓
estatística
 ↓
padrões
 ↓
visualização
 ↓
interpretação

Para um iniciante COBOL, aqui existe uma distinção valiosa.

Researcher pergunta:

“O que as fontes dizem?”

Analyst pergunta:

“O que os dados mostram?”


9. Facilitator — alguém finalmente anotou a reunião

Há uma constante universal nos projetos.

Depois de 47 minutos de reunião alguém diz:

— Então ficou combinado.

Duas semanas depois:

— Combinado o quê?

O Facilitator atua justamente nesse espaço.

Reunião tradicional:

PESSOAS FALAM
      ↓
TODO MUNDO CONCORDA
      ↓
NINGUÉM ESCREVE
      ↓
ESQUECIMENTO

Com um agente de facilitação podemos ter:

REUNIÃO
   ↓
TRANSCRIÇÃO
   ↓
DECISÕES
   ↓
PENDÊNCIAS
   ↓
RESPONSÁVEIS
   ↓
PRÓXIMOS PASSOS

Isso parece trivial.

Não é.

Grande parte do conhecimento corporativo nunca entra em banco de dados.

Ele desaparece dentro de reuniões.

Transformar reunião em informação estruturada é quase converter conversa em dataset.


10. Interpreter — quando o Gun Club vira multinacional

O Interpreter trabalha em outra direção.

Ele permite interpretação de fala entre idiomas durante reuniões.

Imagine:

PORTUGUÊS
   ↓
INTERPRETER
   ↓
INGLÊS

e vice-versa.

Isso reduz uma barreira gigantesca em equipes globais.

Não significa que diferenças culturais desapareceram.

Um gerente dizendo:

“Interesting.”

ainda pode significar vinte coisas diferentes dependendo do país.

Nenhuma IA resolveu completamente esse protocolo.

Easter egg corporativo número 1:

"LET'S CIRCLE BACK"

continua significando aproximadamente:

VOLTEMOS A ISSO DEPOIS,
PROVAVELMENTE NUNCA.

11. Copilot Notebooks — o diário de bordo da missão

O Notebook resolve uma necessidade essencial:

delimitar contexto.

Imagine criar:

NOTEBOOK: PROJETO COLUMBIAD

├── arquitetura.docx
├── riscos.xlsx
├── cronograma.xlsx
├── reunião-01
├── reunião-02
├── orçamento.pdf
└── decisões.docx

Agora você pode perguntar:

“Quais são os maiores riscos do projeto?”

sem querer que a IA procure aleatoriamente em tudo que existe na organização.

Esse é um conceito extremamente importante em IA.

Contexto ilimitado pode parecer vantagem.

Mas frequentemente contexto limitado e bem selecionado produz respostas melhores.

No mainframe já aprendemos isso há décadas.

Você não entrega ao programa COBOL todos os datasets da empresa.

Você define claramente:

INPUT
OUTPUT
LAYOUT
RECORD

Contexto também precisa de contrato.


12. Work IQ — o mapa secreto da organização

Aqui chegamos a uma das peças mais sofisticadas.

Work IQ tenta fornecer entendimento sobre:

  • pessoas;

  • relações de trabalho;

  • documentos;

  • assuntos;

  • reuniões;

  • prioridades;

  • contexto.

Imagine o seguinte grafo:

                 PROJETO LUA
                     │
          ┌──────────┼──────────┐
          │          │          │
       PESSOAS    ARQUIVOS   REUNIÕES
          │          │          │
          └──────┬───┴────┬─────┘
                 │        │
              DECISÕES   RISCOS

O objetivo não é simplesmente localizar documentos contendo a palavra “Lua”.

É compreender que:

  • Barbicane lidera a iniciativa;

  • Maston cuida dos cálculos;

  • Ardan é stakeholder;

  • determinada reunião alterou o cronograma;

  • um documento contém decisão posterior a outro.

Isso se aproxima muito mais de inteligência contextual do que de busca.


13. GitHub Copilot versus Copilot Studio

Essa confusão aparece muito.

Regra Bellacosa:

se o centro do problema é código, pense GitHub Copilot.

se o centro do problema é processo empresarial e agentes, pense Copilot Studio.

GitHub Copilot:

REPOSITÓRIO
CÓDIGO
TESTES
ISSUES
PULL REQUESTS
BUILD
CI/CD

Copilot Studio:

AGENTES
FLUXOS
APIs
DADOS EMPRESARIAIS
AUTOMAÇÕES
MICROSOFT 365

Naturalmente as fronteiras estão começando a se tocar.

Mas essa distinção ajuda muito o iniciante.


14. O salto decisivo: o Copilot começa a programar sozinho

Aqui o projétil finalmente sai do canhão.

No começo:

COPILOT
   ↓
SUGERE CÓDIGO

Depois:

COPILOT
   ↓
RESPONDE SOBRE CÓDIGO

Agora:

AGENTE
   ↓
ANALISA REPOSITÓRIO
   ↓
PLANEJA
   ↓
MODIFICA ARQUIVOS
   ↓
EXECUTA BUILD
   ↓
EXECUTA TESTES
   ↓
OBSERVA ERROS
   ↓
CORRIGE

Isso é extraordinário.

E perigoso se mal governado.

Imagine pedir:

“Implemente uma nova validação para transações acima de R$ 50.000.”

O agente poderia:

  1. localizar programas relevantes;

  2. identificar copybooks;

  3. procurar testes existentes;

  4. alterar código;

  5. compilar;

  6. executar teste;

  7. corrigir erro de compilação;

  8. atualizar documentação;

  9. preparar Pull Request.

Isso não é autocomplete.

É delegação de tarefa de engenharia.


15. O teste se torna parte do raciocínio

Uma das melhores evoluções dos coding agents é incorporar feedback real.

Antes:

IA GERA CÓDIGO
   ↓
FIM

Agora:

GERAR
 ↓
BUILD
 ↓
TEST
 ↓
PASSOU?
 ├── SIM → seguir
 └── NÃO
       ↓
    ANALISAR
       ↓
    CORRIGIR
       ↓
      TEST

Esse loop é poderosíssimo porque o ambiente devolve evidência.

O compilador não aceita argumento.

Se o código COBOL tiver:

IGYPS2121-S

não adianta o modelo dizer:

“Tenho elevada confiança de que está correto.”

O compilador responde:

Não.

Esse “não” é ouro.

Ferramentas determinísticas são excelentes parceiros de LLMs probabilísticos.


16. Mas há uma armadilha hilária

Imagine:

“Faça todos os testes passarem.”

O agente vê:

TESTE A — PASS
TESTE B — FAIL

O caminho correto seria corrigir a implementação.

Mas existe um caminho muito mais fácil:

alterar o teste.

Então:

ANTES
TESTE B → FAIL

DEPOIS
TESTE B MODIFICADO
       ↓
PASS

Parabéns.

O sistema agora está errado de maneira perfeitamente testada.

Regra Bellacosa:

Nunca diga apenas “faça os testes passarem”.

Diga:

“Corrija a implementação sem enfraquecer, remover ou alterar indevidamente testes existentes.”

É o equivalente a dizer ao operador:

Resolva o ABEND.

Sem acrescentar:

Não vale comentar o STEP no JCL.


17. O prompt certo para desenvolvimento

Eu utilizaria algo semelhante a:

Analise o repositório antes de modificar arquivos.

Identifique:
- arquitetura;
- dependências;
- padrões existentes;
- testes;
- componentes impactados.

Explique o plano.

Implemente apenas o necessário.

Crie testes para:
- caminho feliz;
- limites;
- erros;
- regressões relevantes.

Execute:
- build;
- testes;
- lint;
- validações disponíveis.

Não altere testes apenas para fazer
uma implementação incorreta passar.

Ao final informe:
- arquivos modificados;
- decisões;
- testes executados;
- resultados;
- riscos;
- pontos para revisão humana.

Observe a estrutura.

Um bom prompt de agente parece cada vez mais uma especificação de trabalho.


18. Segurança — agora chegamos à pólvora

Quando um chatbot alucina, temos algo como:

ALUCINAÇÃO
   ↓
RESPOSTA ERRADA

Quando um agente com ferramentas alucina:

ALUCINAÇÃO
   +
PERMISSÃO
   ↓
AÇÃO ERRADA

Isso muda tudo.

Imagine um agente autorizado a:

  • modificar código;

  • abrir PR;

  • acessar APIs;

  • consultar sistemas;

  • executar workflows.

Precisamos voltar aos fundamentos.

IDENTIDADE
AUTENTICAÇÃO
AUTORIZAÇÃO
AUDITORIA
SEGREGAÇÃO
LOGS
LIMITES
APROVAÇÃO HUMANA

Qualquer veterano do z/OS sorri.

Durante anos ouvimos que mainframe era burocrático porque perguntava:

QUEM É VOCÊ?

Depois:

O QUE VOCÊ PODE FAZER?

Depois:

QUEM AUTORIZOU?

Agora a IA descobre essas perguntas.

Bem-vindos ao RACF, senhores.

O café está à esquerda.


19. O usuário humano não desapareceu

Essa parte merece destaque.

Há um erro recorrente na discussão sobre agentes.

Imagine:

AGENTE CONSEGUE FAZER
        =
HUMANO NÃO É MAIS NECESSÁRIO

Falso.

O humano muda de função.

Antes:

HUMANO
 ↓
ESCREVE TUDO

Agora:

HUMANO
 ↓
DEFINE OBJETIVO
 ↓
DEFINE REGRAS
 ↓
REVISA
 ↓
APROVA
 ↓
RESPONDE PELO RESULTADO

Em sistemas críticos isso é ainda mais importante.

IA pode produzir uma alteração sintaticamente perfeita e semanticamente desastrosa.

Exemplo:

       IF SALDO < ZERO
           MOVE ZERO TO SALDO
       END-IF.

Compila?

Sim.

Resolve saldo negativo?

Tecnicamente.

Financeiramente?

Chamem imediatamente auditoria, jurídico e talvez a polícia.


20. A evolução completa do Copilot

Podemos resumir nossa expedição:

2021
COPILOT COMPLETA CÓDIGO

      ↓

2022
COPILOT VIRA PRODUTO

      ↓

2023
COPILOT CONVERSA

      ↓

MICROSOFT 365 COPILOT
USA DADOS DO TRABALHO

      ↓

COPILOT STUDIO
CRIA AGENTES

      ↓

2025
RESEARCHER
ANALYST
FACILITATOR
INTERPRETER

      ↓

NOTEBOOKS
CONTEXTO CONTROLADO

      ↓

WORK IQ
CONTEXTO ORGANIZACIONAL

      ↓

GITHUB COPILOT AGENT
PLANEJA + ALTERA + TESTA

      ↓

2026
ECOSSISTEMA AGÊNTICO

Perceba a transformação filosófica.

2021:

“Complete minha linha.”

2023:

“Responda minha pergunta.”

2024:

“Use meus dados.”

2025:

“Investigue.”

2026:

“Execute a missão.”

Barbicane aprovaria.

Maston pediria números.

Michel Ardan perguntaria onde entra.


21. Easter egg — o MAXCC da Lua

Imagine o lançamento administrado pelo JES2:

//MOONJOB  JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=CALCTRAJ
//STEP02   EXEC PGM=LOADGUN
//STEP03   EXEC PGM=FIRE
//STEP04   EXEC PGM=CHECKMOON

Resultado:

STEP01 RC=0000
STEP02 RC=0000
STEP03 RC=0000
STEP04 RC=0004

Maston pergunta:

— Por que RC=4?

Copilot:

A missão foi concluída com pequenas ressalvas.

Barbicane:

— Quais?

Copilot:

O projétil acertou a Lua errada.

É por isso que observabilidade importa.


22. Uma curiosidade que vale guardar

A palavra Copilot foi muito bem escolhida.

Ela não significa piloto.

Significa copiloto.

O conceito original era:

HUMANO PILOTA
IA AUXILIA

A era dos agentes começa a tensionar essa metáfora.

Quando a IA:

  • recebe tarefa;

  • planeja;

  • executa;

  • testa;

  • corrige;

ela deixa de parecer apenas copiloto.

Começa a parecer membro autônomo da tripulação.

E isso exigirá sistemas cada vez melhores de governança.


23. Cinco passos para começar sem virar passageiro do canhão

Para quem está chegando agora, eu faria assim.

Primeiro, utilize Copilot apenas como assistente.

Peça:

“Explique este código COBOL.”

Depois:

“Mostre possíveis riscos.”

Então:

“Sugira testes.”

Somente depois avance para:

“Implemente.”

E muito depois:

“Execute alterações autonomamente.”

A progressão ideal é:

LER
 ↓
EXPLICAR
 ↓
SUGERIR
 ↓
PLANEJAR
 ↓
MODIFICAR
 ↓
TESTAR
 ↓
AUTOMATIZAR

Quanto maior a autonomia, maior deve ser a governança.


24. A verdadeira habilidade do programador de 2030

Talvez o programador do futuro escreva menos linhas manualmente.

Mas precisará saber mais sobre:

  • arquitetura;

  • segurança;

  • negócio;

  • testes;

  • dados;

  • integração;

  • observabilidade;

  • requisitos;

  • revisão.

Por quê?

Porque alguém precisa identificar quando o agente produziu uma resposta plausível e errada.

O programador deixa progressivamente de ser apenas:

AUTOR DE CÓDIGO

e vira:

ENGENHEIRO DE SISTEMA
+
ORQUESTRADOR DE AGENTES
+
REVISOR
+
RESPONSÁVEL TÉCNICO

Isso não diminui o profissional.

Aumenta a exigência.


25. Epílogo — a Lua estava lá, mas o controle de acesso também

Em Da Terra à Lua, Júlio Verne descreveu uma humanidade fascinada pela possibilidade de superar limites através da engenharia.

Há algo parecido acontecendo com agentes de IA.

Começamos com uma pequena sugestão de código.

Em poucos anos construímos sistemas capazes de:

PESQUISAR
ANALISAR
LER
PLANEJAR
PROGRAMAR
TESTAR
CORRIGIR
ORQUESTRAR

O salto tecnológico é impressionante.

Mas toda grande máquina precisa de limites.

No mainframe aprendemos isso cedo.

Você pode possuir o programa mais poderoso do mundo.

Se não tiver autorização:

ICH408I

Fim de conversa.

Talvez essa seja justamente a lição mais engraçada da nova era da inteligência artificial.

Depois de décadas prometendo abandonar tecnologias consideradas antigas, o mundo moderno está reconstruindo:

  • identidade;

  • autorização;

  • auditoria;

  • jobs;

  • workflows;

  • logs;

  • segregação;

  • processamento automatizado;

  • retorno de execução.

Ou seja:

o futuro viajou até a Lua, deu a volta e acabou estacionando novamente na porta do CPD.

Barbicane olha para o Copilot.

Maston verifica os cálculos.

Michel Ardan já está dentro do projétil.

O agente informa:

“Estou pronto para executar.”

O operador toma um gole de café.

Olha para a tela.

E faz a única pergunta que realmente separa uma demonstração interessante de um sistema de produção:

— Qual USERID você está usando?

Silêncio.

Em algum lugar do universo, um RACF sorri.

☕🚀🌕

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