Bellacosa Mainframe e o passo a passo ao MS Copilot

☕ Um Café no Bellacosa Mainframe

Padawan COBOL e o Copilot — Um Guia Passo a Passo para Sair do “O Que Esse Código Faz?” até “Crie, Teste e Explique a Alteração”

Ou: como usar o GitHub Copilot sem transformar o Jedi iniciante em operador de copiar-e-colar — e por que a primeira regra da Força é simples: o Copilot sugere, mas quem responde pelo código é você

Se você está começando em COBOL e ouviu falar de Copilot, é fácil imaginar duas coisas extremas.

A primeira:

“Agora não preciso mais aprender COBOL.”

A segunda:

“Se eu usar IA, nunca vou aprender de verdade.”

As duas estão erradas.

O melhor uso do Copilot para um iniciante é como instrutor auxiliar, navegador de código, explicador de sintaxe, gerador de exemplos e parceiro de testes.

Ele pode acelerar seu aprendizado.

Mas também pode acelerar seus erros.

A diferença está no método.

Então, para um Padawan COBOL, vamos seguir uma progressão segura:

ENTENDER
   ↓
EXPLICAR
   ↓
PERGUNTAR
   ↓
SUGERIR
   ↓
ALTERAR
   ↓
TESTAR
   ↓
REVISAR

Não comece pela última etapa.

Começar diretamente com:

“Faça tudo para mim”

é aproximadamente o equivalente a entregar um sabre de luz para alguém que acabou de descobrir qual lado segura.

Vamos por partes.

---

1. Primeiro passo — entenda qual Copilot você realmente quer usar

Quando falamos em programação, o produto mais relevante é o GitHub Copilot.

Ele é diferente do Microsoft 365 Copilot.

Pense assim:

Microsoft 365 Copilot
→ Word
→ Excel
→ Outlook
→ Teams
→ documentos
→ reuniões
→ trabalho corporativo

GitHub Copilot
→ código
→ IDE
→ repositório
→ testes
→ desenvolvimento

Para aprender COBOL, você provavelmente estará mais interessado no GitHub Copilot integrado a um editor ou IDE.

Exemplos comuns:

VS Code
Visual Studio
JetBrains
GitHub

No universo COBOL moderno, o VS Code é especialmente relevante quando você trabalha com extensões como:

IBM Z Open Editor
Zowe Explorer
Enterprise Developer Tools

Dependendo da sua empresa e ambiente.

---

2. Segundo passo — instale e autentique o GitHub Copilot

No VS Code, o fluxo típico é simples.

Abra:

Extensions

Procure por:

GitHub Copilot

Instale.

Depois autentique sua conta GitHub.

O editor normalmente solicitará login.

Depois disso, o Copilot pode funcionar em duas formas principais:

INLINE COMPLETION

e:

CHAT

Inline Completion significa:

você começa a escrever e ele sugere continuação.

Chat significa:

você pergunta algo diretamente.

Para aprender COBOL, recomendo começar mais pelo Chat do que pelo autocomplete.

Por quê?

Porque o Chat obriga você a formular perguntas.

E fazer boas perguntas é uma das melhores formas de aprender.

---

3. Terceiro passo — comece usando o Copilot como professor

Pegue um programa COBOL simples.

Exemplo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-NOME PIC X(20).

       PROCEDURE DIVISION.

           MOVE 'PADAWAN COBOL' TO WS-NOME

           DISPLAY 'OLA ' WS-NOME

           STOP RUN.

Agora, em vez de pedir:

“Melhore isso.”

pergunte:

“Explique este programa linha por linha para alguém que está começando em COBOL.”

Excelente.

Depois:

“Qual é a função da IDENTIFICATION DIVISION?”

Depois:

“Por que WS-NOME usa PIC X(20)?”

Depois:

“O que aconteceria se eu usasse PIC 9(20)?”

Esse tipo de pergunta transforma Copilot em ferramenta de aprendizagem.

---

4. Quarto passo — aprenda COBOL por comparação

Uma técnica excelente é pedir comparações.

Por exemplo:

“Compare PIC X(10), PIC 9(10) e PIC S9(7)V99.”

O Copilot pode explicar:

PIC X(10)
→ texto

PIC 9(10)
→ número inteiro

PIC S9(7)V99
→ número com sinal e duas casas decimais implícitas

Depois peça exemplos.

“Mostre um exemplo de MOVE válido e inválido para cada um.”

Essa abordagem é muito mais poderosa do que decorar sintaxe.

---

5. Quinto passo — use o Copilot para entender código legado

Agora entramos no verdadeiro planeta COBOL.

Código legado.

Você recebe algo como:

       IF WS-STATUS = 'A'
           PERFORM 3000-PROCESSA
       ELSE
           MOVE 12 TO WS-RETURN-CODE
           PERFORM 9000-ERRO
       END-IF

Um iniciante pode olhar e pensar:

“O que exatamente está acontecendo aqui?”

Pergunte:

“Explique o fluxo deste trecho COBOL em linguagem simples.”

Depois:

“Quais condições levam ao PERFORM 9000-ERRO?”

Depois:

“Quais campos eu deveria investigar antes de alterar este código?”

Isso é ótimo.

Você está usando IA como navegador de fluxo.

---

6. Sexto passo — nunca pergunte só “o que isso faz?”

A melhor pergunta é:

“O que isso faz, quais premissas assume e o que pode dar errado?”

Essa diferença é enorme.

Compare:

Pergunta pobre:
"O que este código faz?"

Pergunta melhor:
"O que este código faz,
quais entradas ele espera,
quais saídas produz,
quais condições de erro existem,
e quais riscos aparecem se eu alterá-lo?"

Isso força uma análise mais completa.

---

7. Sétimo passo — peça ao Copilot para criar um mapa do programa

Para programas maiores, peça:

“Crie um mapa lógico deste programa COBOL.”

Exemplo esperado:

MAIN
 |
 +-- 1000-INICIALIZA
 |
 +-- 2000-LE-ARQUIVO
 |
 +-- 3000-PROCESSA
 |
 +-- 4000-GRAVA-SAIDA
 |
 +-- 9000-FINALIZA

Depois pergunte:

“Qual parágrafo controla o loop principal?”

Ou:

“Qual parágrafo pode alterar WS-RETURN-CODE?”

Isso ajuda muito a compreender programas antigos.

---

8. Oitavo passo — use o Copilot para aprender FILE SECTION

COBOL e arquivos são inseparáveis.

Exemplo:

       FILE SECTION.

       FD ARQ-CLIENTE.

       01 REG-CLIENTE.
          05 CLI-ID      PIC 9(8).
          05 CLI-NOME    PIC X(30).
          05 CLI-SALDO   PIC S9(7)V99.

Pergunte:

“Explique a diferença entre FD, 01 e 05.”

Depois:

“Mostre como este registro ficaria em bytes.”

Depois:

“Quantos bytes esse registro ocupa?”

Depois:

“Explique o que significa V em PIC S9(7)V99.”

Esse tipo de aprendizado é extremamente eficiente.

---

9. Nono passo — peça exemplos pequenos

Uma regra essencial para aprender com IA:

não peça um sistema inteiro.

Peça pequenos exemplos.

Ruim:

“Crie um sistema bancário COBOL.”

Bom:

“Crie um exemplo COBOL que leia um saldo, aplique uma taxa e exiba o resultado.”

Depois evolua.

PASSO 1
DISPLAY simples

PASSO 2
IF

PASSO 3
PERFORM

PASSO 4
arquivo

PASSO 5
subprograma

PASSO 6
DB2

PASSO 7
CICS

Aprendizado incremental é muito melhor.

---

10. Décimo passo — use Copilot para aprender PERFORM

PERFORM costuma confundir iniciantes.

Pergunte:

“Explique PERFORM como se eu conhecesse loops em Java ou Python.”

Depois peça exemplos:

       PERFORM 1000-PROCESSA

Depois:

       PERFORM 1000-PROCESSA
           UNTIL WS-FIM = 'S'

Depois:

       PERFORM VARYING WS-I FROM 1 BY 1
           UNTIL WS-I > 10

Compare.

Esse é um ótimo uso do Copilot.

---

11. Décimo primeiro passo — use IA para entender mensagens de compilação

Essa é uma das melhores aplicações para um Padawan.

Imagine receber:

IGYPS2121-S

Em vez de entrar em pânico, pergunte:

“Explique esta mensagem de compilação COBOL e mostre causas prováveis.”

Mas envie contexto.

Não diga apenas:

“Erro IGYPS2121-S.”

Diga:

“Estou compilando este trecho COBOL e recebi IGYPS2121-S nesta linha. Explique a provável causa sem inventar.”

Melhor ainda:

“Mostre três hipóteses e diga como validar cada uma.”

Isso transforma a resposta em troubleshooting.

---

12. Décimo segundo passo — Copilot não substitui o compilador

Aqui está uma regra gravada em pedra.

Copilot pode dizer:

“Esse código parece correto.”

O compilador diz:

ERROR

Quem ganha?

O compilador.

Sempre.

Por quê?

Porque Copilot trabalha com probabilidade.

O compilador trabalha com gramática e regras formais.

Então:

COPILOT
→ hipótese

COMPILADOR
→ evidência

Não confunda os dois.

---

13. Décimo terceiro passo — peça ao Copilot para gerar testes

Quando você já entende o código, pergunte:

“Quais cenários de teste devo criar?”

Exemplo:

       IF WS-SALDO < ZERO
           MOVE 'E001' TO WS-ERRO
       END-IF

Peça:

“Crie cenários de teste para este IF.”

Resposta esperada:

Caso 1
SALDO = 100
Resultado esperado: sem erro

Caso 2
SALDO = 0
Resultado esperado: sem erro

Caso 3
SALDO = -1
Resultado esperado: E001

Caso 4
SALDO = valor mínimo permitido
Resultado esperado: validar limite

Isso ensina uma habilidade importantíssima:

pensar em bordas.

---

14. Décimo quarto passo — peça testes antes da implementação

Essa técnica é excelente.

Antes de pedir código, diga:

“Antes de implementar, liste os testes que definem o comportamento correto.”

Isso força você e o Copilot a concordarem sobre o problema primeiro.

Fluxo ideal:

REQUISITO
   ↓
TESTES
   ↓
IMPLEMENTAÇÃO
   ↓
EXECUÇÃO
   ↓
REVISÃO

Muito melhor que:

"Código aí qualquer coisa."

---

15. Décimo quinto passo — use Copilot para revisar seu código

Depois que você escrever alguma coisa, pergunte:

“Revise este código sem reescrevê-lo.”

Isso é importante.

Porque se você disser:

“Melhore”

o Copilot pode mudar tudo.

Peça:

“Aponte erros, riscos e melhorias, mas não altere o código ainda.”

Primeiro diagnóstico.

Depois intervenção.

---

16. Décimo sexto passo — peça explicação antes da correção

Essa é uma regra maravilhosa para iniciantes.

Em vez de:

“Corrija meu programa.”

diga:

“Explique primeiro por que está errado. Depois mostre a menor correção possível.”

Assim você aprende.

Exemplo:

       MOVE 'ABC' TO WS-NUMERO

Pergunte:

“Por que isso é problemático se WS-NUMERO for PIC 9(3)?”

Depois peça correção.

Isso evita o comportamento:

CTRL+C
CTRL+V
Ctrl+Esperança

---

17. Décimo sétimo passo — aprenda SQL embutido com ajuda do Copilot

Quando entrar em COBOL + Db2, use IA como tutor.

Exemplo:

       EXEC SQL
           SELECT NOME
             INTO :WS-NOME
             FROM CLIENTE
            WHERE ID = :WS-ID
       END-EXEC.

Pergunte:

“Explique o papel das host variables.”

Depois:

“O que significa SQLCODE +100?”

Depois:

“Qual diferença entre erro de compilação COBOL e erro SQL?”

Depois:

“O que o precompiler faz?”

Isso ajuda muito a montar o mapa mental.

---

18. Décimo oitavo passo — use Copilot para explicar JCL

Padawan COBOL rapidamente encontra JCL.

Exemplo:

//JOB01    JOB ...
//STEP01   EXEC PGM=MEUPGM
//STEPLIB  DD DSN=...
//SYSOUT   DD SYSOUT=*
//ARQENT   DD DSN=...

Pergunte:

“Explique cada DD e sua relação com o programa COBOL.”

Depois:

“Qual arquivo COBOL corresponde a ARQENT?”

Isso conecta:

COBOL
ASSIGN
SELECT
FD
JCL
DD
DATASET

Esse casamento é essencial.

---

19. Décimo nono passo — use Copilot para estudar CICS sem medo

Quando chegar em CICS, não peça:

“Explique CICS.”

É amplo demais.

Pergunte:

“Explique esta instrução EXEC CICS READ.”

Depois:

“O que é RESP?”

Depois:

“Qual diferença entre LINK e XCTL?”

Depois:

“Explique COMMAREA.”

Copilot funciona melhor quando você quebra o monstro em pedaços.

---

20. Vigésimo passo — aprenda a formular prompts técnicos

Aqui está um modelo de prompt excelente.

Contexto:
Sou iniciante em COBOL.

Objetivo:
Quero entender este trecho.

Faça:
1. explique linha por linha;
2. identifique variáveis relevantes;
3. descreva o fluxo;
4. mostre possíveis erros;
5. dê um exemplo de entrada e saída;
6. não altere o código ainda.

Essa estrutura é simples e poderosa.

---

21. Um prompt Bellacosa para estudar código legado

Use:

Analise este programa COBOL como um instrutor. Primeiro descreva sua finalidade provável. Depois identifique divisions, sections, paragraphs, arquivos, copybooks, chamadas externas e variáveis importantes. Crie um mapa do fluxo principal. Explique os pontos difíceis para um iniciante. Não modifique nada. Se alguma conclusão não puder ser confirmada pelo código disponível, diga explicitamente que é uma hipótese.

Essa última frase é ouro:

“diga explicitamente que é uma hipótese.”

Porque IA adora completar lacunas.

---

22. Um prompt para debugging

Use:

Estou recebendo este erro ao compilar ou executar. Analise o código e a mensagem. Liste as causas possíveis em ordem de probabilidade. Para cada causa, mostre como validar. Não sugira alterações antes de explicar a causa.

Excelente para aprender investigação.

---

23. Um prompt para criar alteração

Quando estiver mais confiante:

Analise primeiro o impacto desta alteração. Identifique campos, paragraphs, copybooks, arquivos, SQL, chamadas externas e testes potencialmente afetados. Proponha a menor mudança possível. Explique antes de gerar o código.

Isso evita alterações espalhafatosas.

---

24. Um prompt para testes

Crie uma matriz de testes para esta regra COBOL. Inclua caminho feliz, zero, valores limites, dados inválidos, erros de arquivo, condições não encontradas e regressões possíveis. Para cada teste, informe entrada, condição e resultado esperado.

Muito útil.

---

25. Um prompt para revisão

Revise este código COBOL como um revisor sênior. Não reescreva ainda. Identifique problemas de lógica, legibilidade, tratamento de erro, risco de truncamento, tipos incompatíveis, uso de campos, loops e possíveis impactos de negócio.

Agora você começa a utilizar Copilot como mentor técnico.

---

26. O perigo do autocomplete automático

Inline suggestion é útil.

Mas para iniciantes pode virar armadilha.

Você digita:

       IF WS-STATUS =

Copilot sugere:

       IF WS-STATUS = 'A'
           PERFORM PROCESSA-ATIVO
       END-IF

Parece perfeito.

Mas de onde veio 'A'?

Talvez no seu sistema:

A = BLOQUEADO

e:

L = LIBERADO

O Copilot pode gerar código sintaticamente elegante e semanticamente errado.

Regra:

nunca aceite uma regra de negócio só porque parece plausível.

---

27. O truque Jedi: pergunte “como você sabe?”

Depois de uma resposta, pergunte:

“Que parte do código sustenta essa conclusão?”

Ou:

“Isso está explícito no código ou você inferiu?”

Esse é um truque excelente.

Ele obriga a separar:

FATO

de:

INFERÊNCIA

---

28. Nunca passe segredos

Não cole no Copilot:

senhas
tokens
chaves
credenciais
dados de clientes
dados regulados
informações sensíveis

Especialmente em ambiente empresarial, siga as políticas da organização.

O Padawan precisa dominar o sabre.

Mas também precisa saber onde não balançá-lo.

---

29. Não use Copilot para driblar revisão

Outro erro:

“Se a IA escreveu, deve estar certo.”

Não.

O correto é:

IA GERA
   ↓
VOCÊ REVISA
   ↓
COMPILA
   ↓
TESTA
   ↓
REVISA RESULTADO

Nunca:

IA GERA
   ↓
PRODUÇÃO

Essa linha deveria produzir um alarme equivalente a:

ICH408I

---

30. Um laboratório simples para começar

Crie um programa pequeno:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SALDO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-SALDO PIC S9(5)V99 VALUE 100.00.
       01 WS-STATUS PIC X(10).

       PROCEDURE DIVISION.

           IF WS-SALDO < ZERO
               MOVE 'NEGATIVO' TO WS-STATUS
           ELSE
               MOVE 'OK' TO WS-STATUS
           END-IF

           DISPLAY WS-STATUS

           STOP RUN.

Agora siga esta sequência:

1. Peça explicação linha por linha.

2. Pergunte o que significa S9(5)V99.

3. Pergunte por que ZERO funciona.

4. Peça três testes.

5. Altere WS-SALDO manualmente.

6. Execute.

7. Compare o resultado com a previsão.

8. Peça uma melhoria.

9. Entenda a melhoria.

10. Só depois aceite a mudança.

Esse laboratório ensina COBOL e ensina a usar IA ao mesmo tempo.

---

31. Exercício Jedi 2 — arquivo sequencial

Depois faça um programa com:

INPUT
CLIENTE
SALDO
STATUS

Peça ao Copilot:

“Ajude-me a criar o layout, mas explique cada PIC.”

Depois:

“Ajude-me a montar SELECT, FD, OPEN, READ e CLOSE.”

Mas não peça tudo de uma vez.

Construa passo a passo.

Assim você aprende a ligação:

ENVIRONMENT DIVISION
        ↓
SELECT
        ↓
FILE SECTION
        ↓
FD
        ↓
READ
        ↓
JCL DD

---

32. Exercício Jedi 3 — Db2

Crie uma consulta simples.

Pergunte:

“Como transformar este SELECT em SQL embutido COBOL?”

Depois:

“Onde entra SQLCA?”

Depois:

“Como tratar SQLCODE +100?”

Depois:

“Como tratar SQLCODE negativo?”

Você estará usando Copilot não apenas para escrever.

Estará usando para construir conhecimento conectado.

---

33. Quando usar Agent Mode?

Somente depois de dominar bem o básico.

Agent Mode pode trabalhar em várias etapas.

Exemplo:

“Adicione validação de saldo negativo e crie testes.”

O agente pode:

analisar arquivos
 ↓
editar
 ↓
executar build
 ↓
rodar testes
 ↓
corrigir

Isso é poderoso.

Para iniciante, também é perigoso.

Porque várias mudanças podem acontecer sem você entender.

Use inicialmente em projetos pequenos e controlados.

---

34. Antes de usar agente, peça plano

Regra:

Planeje antes de executar.

Prompt:

“Não faça alterações ainda. Primeiro analise o repositório e mostre o plano.”

Leia o plano.

Pergunte:

“Por que precisa alterar esse arquivo?”

Depois autorize.

Esse comportamento aproxima você de engenharia profissional.

---

35. Quando o Copilot errar, comemore um pouco

Sim.

Errar pode ensinar muito.

Se ele sugerir:

       MOVE WS-TEXTO TO WS-NUMERO

e der erro, investigue.

Pergunte:

“Por que sua sugestão anterior falhou?”

Você aprende:

tipos
PIC
conversão
truncamento
data exceptions

Uma IA perfeita seria um professor pior.

Os erros criam oportunidades de debugging.

---

36. O Padawan precisa aprender a desconfiar

Uma boa relação com Copilot não é confiança absoluta.

É confiança calibrada.

Use esta escala:

EXPLICAÇÃO CONCEITUAL
→ confiança moderada

SINTAXE
→ validar

REGRA DE NEGÓCIO
→ validar fortemente

SEGURANÇA
→ validar fortemente

PRODUÇÃO
→ revisão obrigatória

Quanto maior o impacto, menor deve ser sua disposição em aceitar algo sem evidência.

---

37. Uma rotina diária de 30 minutos

Para aprender COBOL com Copilot:

10 min
Leia código sozinho.

5 min
Anote o que você acha que acontece.

5 min
Pergunte ao Copilot.

5 min
Compare as explicações.

5 min
Execute ou teste.

O ponto mais importante:

tente entender antes de perguntar.

Se você pergunta primeiro, seu cérebro pode entrar em modo espectador.

---

38. A regra dos três “porquês”

Para qualquer resposta importante, pergunte:

Por quê?

Como você sabe?

Como eu posso validar?

Essa tríade vale ouro.

Exemplo:

Copilot:

“Esse campo pode sofrer truncamento.”

Você:

“Por quê?”

Depois:

“Como você sabe?”

Depois:

“Como posso demonstrar isso com um teste?”

Pronto.

Você transformou uma resposta em aprendizado.

---

39. Copilot como mestre, não como muleta

Use Copilot para:

EXPLICAR
COMPARAR
SUGERIR
TESTAR
REVISAR
INVESTIGAR

Evite depender dele para:

PENSAR POR VOCÊ
VALIDAR NEGÓCIO POR VOCÊ
DECIDIR PRODUÇÃO POR VOCÊ

Essa distinção será cada vez mais importante.

---

40. O caminho do Padawan

Eu resumiria o treinamento assim:

NÍVEL 1
"Explique."

NÍVEL 2
"Dê exemplo."

NÍVEL 3
"Compare."

NÍVEL 4
"Encontre o erro."

NÍVEL 5
"Sugira uma solução."

NÍVEL 6
"Crie testes."

NÍVEL 7
"Faça a alteração."

NÍVEL 8
"Execute o ciclo."

NÍVEL 9
"Revise o agente."

NÍVEL 10
"Governança."

Não pule do nível 1 para o 8.

---

Epílogo — o Padawan, o Copilot e o velho terminal verde

Imagine um jovem programador sentado diante de um terminal.

À esquerda:

COBOL

À direita:

COPILOT

O iniciante pergunta:

“Você pode fazer isso por mim?”

O velho mestre no fundo do CPD responde:

“Pode.”

O Padawan sorri.

Então o mestre completa:

“Mas primeiro descubra por que ele fez.”

Essa é a diferença entre alguém que usa IA e alguém que aprende engenharia usando IA.

O Copilot pode completar uma linha.

Pode explicar um programa.

Pode sugerir uma função.

Pode criar testes.

Pode encontrar erros.

Pode, cada vez mais, alterar projetos inteiros.

Mas há uma habilidade que continua sendo sua:

entender o sistema pelo qual você é responsável.

No mundo COBOL, onde uma linha aparentemente inocente pode tocar folha de pagamento, cobrança, estoque, seguro, cartão, governo ou conta bancária, isso não é filosofia.

É requisito operacional.

Então use o Copilot.

Use muito.

Pergunte.

Experimente.

Quebre código de laboratório.

Compile.

Teste.

Discorde dele.

Peça explicações.

E quando ele disser:

“A alteração está pronta.”

faça como qualquer Jedi do mainframe faria.

Olhe para o código.

Olhe para os testes.

Olhe para o retorno.

Tome um gole de café.

E pergunte:

“Pronto segundo quem?”

☕⚔️💻

 

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.

☕🚀🌕