 |
| Bellacosa Mainframe e o ibm bob chegando no cpd |
☕ Um Café no Bellacosa Mainframe
IBM Bob Entra no CPD — O Dia em que o Programador COBOL Parou de Pedir Código e Começou a Comandar Agentes
Ou: por que “eu uso IA para programar” já vale quase o mesmo que dizer “sei usar Google”, como ASK, PLAN e AGENT mudam a engenharia de software, por que um agente merece menos privilégios que um estagiário com RACF SPECIAL e como o COBOL pode ensinar uma lição ao futuro da programação
Prólogo — Bob chegou ao CPD e pediu acesso ao código
Imagine a cena.
São 22h37.
O CPD está silencioso.
O café já foi requentado duas vezes.
No canto da sala existe um programa COBOL chamado:
PAYR001
Ele tem 18 mil linhas.
Foi criado quando alguém ainda dizia:
“Internet? Isso aí não vai pegar.”
Ninguém sabe exatamente tudo o que o programa faz.
O analista que escreveu a primeira versão se aposentou.
O sujeito que conhecia metade das regras de negócio abriu uma pousada em Ubatuba.
O último programador que tentou “modernizar rapidinho” deixou três comentários no fonte:
* NAO MEXER AQUI
* NAO SEI PQ FUNCIONA
* MAS FUNCIONA
Então entra Bob.
Não o operador Bob.
Não o Bob da contabilidade.
IBM Bob, o parceiro de desenvolvimento baseado em inteligência artificial.
Bob olha para PAYR001.
O programador COBOL iniciante olha para Bob.
E comete o primeiro pecado da programação assistida por inteligência artificial:
“Bob, modernize isso.”
Nesse instante, em algum lugar do universo, um sysprog derruba uma caneca de café.
Porque o problema da IA em desenvolvimento de software nunca foi apenas:
Ela consegue escrever código?
A pergunta correta é:
Você sabe o que está autorizando a IA a fazer?
Bem-vindo à próxima etapa da programação.
1. “Eu uso IA para programar” deixou de impressionar
Há alguns anos, colocar no currículo:
Experiência com inteligência artificial aplicada ao desenvolvimento.
podia chamar atenção.
Depois vieram ChatGPT, GitHub Copilot, CodeWhisperer, Claude, Gemini, IBM Bob e uma coleção cada vez maior de ferramentas.
Hoje é comum um desenvolvedor digitar:
crie uma função
e receber uma função.
Depois:
crie os testes
e receber testes.
Depois:
documente
e receber documentação.
Isso continua sendo útil.
Mas deixou de ser extraordinário.
É parecido com escrever no currículo:
“Sei pesquisar no Google.”
Parabéns.
Em 2001 talvez fosse diferencial.
Em 2026 é parte do trabalho.
O que começa a separar profissionais é outra coisa:
o que você consegue fazer com a IA depois que ela deixa de ser uma simples máquina de completar código?
2. O iniciante costuma confundir programação com digitação de programa
Essa confusão já existia muito antes da inteligência artificial.
Veja este COBOL:
IF WS-SALDO > 0
MOVE 'ATIVO' TO WS-STATUS
ELSE
MOVE 'INATIVO' TO WS-STATUS
END-IF.
Um iniciante pode aprender essa sintaxe rapidamente.
Isso significa que ele entende o sistema?
Não.
Talvez WS-SALDO represente:
saldo contábil;
saldo disponível;
saldo bloqueado;
saldo devedor;
posição intraday;
um campo legado chamado saldo que na prática representa outra coisa.
O problema empresarial não mora na palavra MOVE.
Ele mora no significado.
Esse é um dos primeiros ensinamentos que o mainframe oferece para a era da IA:
Código é representação. Negócio é contexto.
IA ficou extraordinariamente boa na primeira parte.
A segunda continua sendo muito mais complicada.
3. O código está deixando de ser o gargalo
Durante décadas, escrever software era caro.
Você precisava transformar uma ideia em milhares de instruções.
Então nasceram linguagens de alto nível.
Depois bibliotecas.
Frameworks.
IDEs.
Stack Overflow.
Geradores.
Low-code.
E finalmente grandes modelos de linguagem.
Agora imagine que produzir código fique dez vezes mais rápido.
Excelente.
Mas surge um efeito curioso.
Antes:
REQUISITO
↓
ANÁLISE
↓
CODIFICAÇÃO ← lento
↓
REVISÃO
↓
TESTE
↓
HOMOLOGAÇÃO
↓
PRODUÇÃO
Depois da IA:
REQUISITO
↓
ANÁLISE
↓
IA
↓
████████████████████
REVISÃO
TESTES
SEGURANÇA
VALIDAÇÃO
████████████████████
↓
PRODUÇÃO
Você não eliminou necessariamente o gargalo.
Você mudou o gargalo de lugar.
A própria documentação e comunicação recente em torno do IBM Bob refletem essa mudança de foco: Bob trabalha hoje com modos específicos para perguntar, planejar e executar, além de ferramentas, subagentes, MCP e integrações além da simples geração de texto.
Quanto mais código conseguimos produzir automaticamente, mais importante passa a ser responder:
Isto está correto?
Isto deveria existir?
Isto viola alguma regra?
Isto quebra quem?
Isto pode ir para produção?
A IA acelera a construção.
Mas alguém ainda precisa saber o que merece ser construído.
4. Conheça os três estados mentais: ASK, PLAN e AGENT
Aqui aparece uma das ideias mais educativas do IBM Bob.
Os modos nativos atuais distinguem três comportamentos fundamentais:
ASK
PLAN
AGENT
Não pense nisso apenas como botões de interface.
Pense como três níveis diferentes de relacionamento entre você e um agente.
A documentação do Bob define Ask como apropriado para explicações e análise sem modificações; Plan para investigar e elaborar estratégias antes da implementação; e Agent para tarefas que envolvem modificar código, executar comandos e implementar mudanças.
Isso deveria estar pregado na parede de todo CPD:
ENTENDER
ANTES DE
PLANEJAR
PLANEJAR
ANTES DE
ALTERAR
5. ASK — “Bob, explique essa tranqueira antes que alguém mexa nela”
Imagine que você recebeu:
PAYR001
Você não sabe o que faz.
O comportamento errado seria:
Refatore esse programa.
O comportamento inteligente começa com investigação:
Analise PAYR001.
Identifique:
- arquivos utilizados;
- copybooks;
- chamadas CALL;
- tabelas Db2;
- recursos CICS;
- acessos VSAM;
- códigos de retorno;
- possíveis dependências;
- pontos que parecem representar regras de negócio.
Não modifique nenhum arquivo.
Perceba a última frase:
Não modifique nenhum arquivo.
Essa frase vale ouro.
Estamos usando IA como analista, não como cirurgião.
Ela pode responder:
PAYR001
|
+-- COPY EMPREG
|
+-- COPY TAXAS
|
+-- DB2 EMPLOYEE
|
+-- CALL TAXCALC
|
+-- VSAM FUNCION
|
+-- CICS LINK PAYR020
Agora você começou a construir um mapa.
Esse é o papel ideal do Ask.
6. Easter egg nº 1 — Sherlock Holmes deveria ter trabalhado com legado
Uma grande parte da manutenção de sistemas antigos é investigação.
Você encontra:
MOVE 17 TO WS-TIPO-CALCULO.
Por quê 17?
Ninguém sabe.
Você pesquisa o programa.
Depois o copybook.
Depois o JCL.
Depois uma tabela.
Depois encontra uma documentação de 1998.
E finalmente descobre:
Tipo 17 = cálculo especial utilizado durante fechamento de fevereiro.
Isso não é programação.
Isso é arqueologia industrial.
Bob pode ser um excelente Watson.
Mas ainda precisamos de Sherlock para perguntar:
“Por que fevereiro?”
7. PLAN — o momento mais importante ocorre antes da primeira alteração
Agora suponha que nossa missão seja mudar uma regra de juros.
Não diga:
Faça.
Peça:
Planeje a alteração necessária para modificar
a regra de juros do produto X.
Antes de qualquer implementação:
1. identifique os módulos afetados;
2. liste dependências;
3. identifique copybooks envolvidos;
4. localize testes existentes;
5. identifique possíveis impactos externos;
6. proponha uma estratégia;
7. liste riscos;
8. defina critérios de aceitação.
Bob pode retornar:
PLANO
1. Modificar CALCJURO.cbl
2. Alterar TAXAS.cpy
3. Revisar tabela DB2 TAXA_JUROS
4. Atualizar teste TC019
5. Executar regressão
6. Validar PAYR001 e PAYR020
O iniciante diz:
“Parece ótimo!”
O veterano grita do fundo do CPD:
“NÃO MEXE NO TAXAS.CPY!”
Por quê?
Porque o veterano sabe que aquele copybook é utilizado por 47 programas.
A IA talvez tenha identificado somente 13.
Ou talvez nem tenha acesso a todos os repositórios.
Esse momento é crucial.
Você responde:
Plano rejeitado parcialmente.
TAXAS.CPY é compartilhado por outros sistemas.
Não alterar o copybook.
Proponha uma solução local mantendo a interface atual.
Pronto.
A inteligência mais importante dessa interação talvez não tenha sido a inteligência artificial.
Foi o julgamento humano.
8. Eis o verdadeiro superpoder do profissional experiente
Muito se fala que IA diminuirá a importância da experiência.
Em sistemas empresariais antigos pode ocorrer justamente o contrário.
Porque um sistema legado é:
código
+
dados
+
procedimentos
+
infraestrutura
+
interfaces
+
regras empresariais
+
exceções
+
história
+
conhecimento tribal
IA pode ler muito código.
Mas talvez não saiba que:
“Esse job nunca deve rodar antes do fechamento da filial argentina.”
Talvez isso não esteja documentado.
Talvez esteja apenas na cabeça de alguém chamado Carlos.
Carlos trabalha ali desde 1994.
Todos chamam aquilo de:
REGRA DO CARLOS
Nenhum compilador conhece.
Nenhum modelo conhece.
Carlos conhece.
Esse tipo de contexto será extremamente valioso.
9. AGENT — agora Bob recebe a caixa de ferramentas
Depois que o plano foi investigado e aprovado, chegamos ao modo Agent.
Aqui as coisas ficam sérias.
Bob pode trabalhar com operações de leitura, edição, execução de comandos e ferramentas conectadas.
A relação passa de:
Humano pergunta
IA responde
para:
Humano define objetivo
↓
Agente investiga
↓
Agente modifica
↓
Agente executa
↓
Agente testa
↓
Humano revisa
Essa é uma mudança gigantesca.
Porque agora a IA não está apenas falando sobre o sistema.
Ela está fazendo coisas no sistema.
10. Programador, conheça uma palavra importante: autoridade
Considere dois agentes.
Agente A
Pode apenas ler arquivos.
Risco:
baixo
Agente B
Pode:
ler arquivos
editar arquivos
executar shell
chamar APIs
consultar serviços
abrir pull request
alterar configuração
Risco:
hmmmm...
Agora imagine:
Agente C
Pode:
acessar produção
alterar banco
ler secrets
fazer deploy
aprovar merge
O operador do mainframe desmaia.
É exatamente aqui que décadas de experiência em controle de acesso voltam a ficar modernas.
11. RACF encontra inteligência artificial
O mainframeiro olha para essa discussão e pergunta:
“Vocês descobriram autorização agora?”
🤣
No mundo z/OS aprendemos há décadas a perguntar:
QUEM É VOCÊ?
↓
O QUE VOCÊ PODE ACESSAR?
↓
PODE APENAS LER?
↓
PODE ALTERAR?
↓
PODE EXECUTAR?
↓
QUEM CONCEDEU?
↓
EXISTE LOG?
Agora substitua usuário por agente:
QUAL AGENTE?
↓
QUAIS FERRAMENTAS?
↓
QUAIS ARQUIVOS?
↓
QUAIS SERVIDORES MCP?
↓
PODE EXECUTAR COMANDOS?
↓
PODE ALTERAR REPOSITÓRIO?
↓
PODE PUBLICAR?
↓
QUEM APROVA?
O futuro da IA empresarial parece surpreendentemente parecido com uma conversa que um administrador RACF teria em 1995.
Easter egg:
Não dê
SPECIALpara Bob.
Ele é gente boa.
Mas ninguém merece SPECIAL.
12. Least privilege — trate a IA como trataria qualquer outro ator do sistema
Uma arquitetura saudável poderia permitir:
Bob pode:
[X] ler código
[X] criar branch
[X] alterar branch de trabalho
[X] executar testes
[X] gerar documentação
[X] criar Pull Request
Bob não pode:
[ ] merge direto em main
[ ] acessar senha de produção
[ ] modificar tabela produtiva
[ ] fazer deployment produtivo
[ ] desligar JES2 porque "pareceu uma boa ideia"
Esse modelo é chamado de princípio do menor privilégio.
Não dê uma permissão porque o agente pode eventualmente precisar.
Dê somente aquilo que é necessário para a tarefa atual.
13. Human-in-the-loop — existe um humano entre a ideia e o estrago
Um fluxo simples:
IA propõe
↓
HUMANO REVISA
↓
IA EXECUTA
↓
HUMANO VALIDA
Esse é um modelo conhecido como:
Human in the Loop
O ser humano participa diretamente dos checkpoints.
Depois de ganhar maturidade, certas tarefas podem usar algo semelhante a:
Human on the Loop
O agente executa atividades dentro de limites predeterminados e o humano supervisiona.
Por exemplo:
Bob:
criar teste SIM
rodar teste SIM
corrigir branch SIM
abrir PR SIM
merge em produção NÃO
Não precisamos escolher entre:
humano faz tudo
e
robô faz tudo.
Existe uma enorme região intermediária.
É ali que provavelmente estará grande parte da engenharia empresarial dos próximos anos.
14. Subagents — quando Bob monta sua própria equipe
Agora nossa história fica ainda mais interessante.
Bob pode utilizar subagents, agentes independentes que executam tarefas focadas em janelas de contexto isoladas e devolvem um resumo ao agente principal. A documentação atual distingue inclusive subagentes explore, orientados à exploração somente-leitura, e general, capazes de usar ferramentas mais amplas. O usuário aprova a criação antes da execução.
Imagine:
BOB
|
+-----------+-----------+
| | |
AGENTE AGENTE AGENTE
COBOL DB2 TESTE
| | |
PAYR001 SQL REGRESSÃO
O agente COBOL analisa dependências.
O agente Db2 investiga consultas.
O agente de testes verifica cobertura.
Todos retornam resumos.
Bob junta as peças.
Isso começa a parecer menos com:
“assistente de programação”
e mais com:
“equipe técnica virtual”.
15. Mas subagent não é Pokémon
Existe uma tentação:
Bob, crie 27 agentes.
Não.
Mais agentes não significam automaticamente resultado melhor.
Cada agente:
consome contexto;
executa ferramentas;
pode interpretar algo incorretamente;
aumenta custo;
aumenta coordenação.
O próprio Bob procura usar subagentes quando o trabalho é realmente autocontido e quando separar o contexto faz sentido, em vez de lançar agentes indiscriminadamente para qualquer leitura simples.
Regra Bellacosa:
Se uma tarefa exige dois minutos, não convoque os Vingadores.
16. MCP — Bob encontrou tomadas no CPD
Outra sigla importante:
MCP
Model Context Protocol.
De forma simplificada, MCP permite que um agente trabalhe com ferramentas e fontes externas através de uma interface padronizada.
Antes:
LLM
|
conversa
Depois:
BOB
|
MCP
+-------+-------+
| | |
Git API Sistema
| | |
Jira Docs Ferramentas
A documentação do Bob apresenta MCP justamente como mecanismo para estender o agente com ferramentas externas e integrações personalizadas.
Essa é uma mudança fundamental.
Porque um chatbot só poderia dizer:
“Você deveria abrir um ticket.”
Um agente conectado talvez possa:
abrir o ticket
A diferença entre conselho e ação é enorme.
17. Bob Shell — quando o polvo sai do editor
Em agosto de 2026, a IBM colocou o agente V2 também no Bob Shell, levando a arquitetura compartilhada do Bob para o terminal. A atualização também trouxe mudanças no Bobalytics, IDE e gerenciamento relacionado a MCP e revisão de edições.
Para um programador isso significa algo importante.
Antes:
IDE
|
assistente
Agora podemos imaginar:
TERMINAL
|
Bob Shell
|
+-- build
+-- test
+-- git
+-- scripts
+-- ferramentas
E quem trabalha com mainframe sabe uma coisa:
quando algo chega ao terminal, começa a entrar no território da automação.
18. O futuro não é prompt engineering
Durante algum tempo todo mundo falava:
PROMPT ENGINEERING
Como se a habilidade definitiva fosse descobrir a frase mágica.
Algo parecido com:
“Escreva um programa extraordinário, pense passo a passo, seja genial e não erre.”
Não.
A evolução real parece mais próxima de:
PROMPT
↓
CONTEXTO
↓
PLANO
↓
DELEGAÇÃO
↓
EXECUÇÃO
↓
VALIDAÇÃO
↓
GOVERNANÇA
↓
OBSERVABILIDADE
↓
MÉTRICA
A habilidade passa de:
saber conversar com IA
para:
saber operar IA dentro de um processo de engenharia.
19. O portfólio do iniciante também precisa mudar
Imagine dois candidatos.
Candidato 1
GitHub:
CRUD de clientes
Clone do Netflix
Lista de tarefas
Calculadora
Tudo produzido parcialmente com IA.
Legal.
Agora candidato 2 cria:
cobol-modernization-lab/
|
+-- README.md
+-- docs/
| +-- architecture.md
| +-- decisions.md
| +-- risks.md
|
+-- prompts/
| +-- analysis.md
| +-- plan.md
|
+-- src/
|
+-- tests/
|
+-- lessons-learned.md
No README:
Problema
↓
Análise inicial
↓
Plano sugerido pelo agente
↓
Plano revisado
↓
Decisões rejeitadas
↓
Implementação
↓
Testes
↓
Resultado
Quem você acha que dará mais assunto numa entrevista?
20. A melhor seção do README talvez seja: “onde Bob errou”
Sim.
Você leu corretamente.
Imagine:
## AI Recommendation Rejected
Bob sugeriu modificar COPY TAXAS.
A recomendação foi rejeitada porque o copybook
é compartilhado por múltiplas aplicações.
Decisão humana:
manter interface pública e implementar adaptação
local no programa CALCJURO.
Isso é maravilhoso.
Porque demonstra:
IA sugeriu
↓
VOCÊ ENTENDEU
↓
VOCÊ DISCORDOU
↓
VOCÊ EXPLICOU
↓
VOCÊ DECIDIU
A competência não está em aceitar a IA.
Está em saber quando não aceitar.
21. Uma entrevista técnica do futuro
Recrutador:
Você utiliza agentes de IA?
Candidato:
Sim.
Recrutador:
Conte uma decisão do agente que você rejeitou.
Silêncio.
O candidato que simplesmente gerava código morreu na praia.
Já outro responde:
O agente sugeriu alterar um contrato compartilhado. Analisei dependências, percebi risco de quebra em consumidores externos, rejeitei a solução e implementei um adapter preservando compatibilidade.
Pronto.
Temos uma conversa de engenharia.
22. O programador COBOL tem uma vantagem inesperada
COBOL ensina algo precioso:
software não existe isoladamente
Um programa está conectado a:
JCL
copybooks
VSAM
Db2
CICS
IMS
MQ
jobs
arquivos
procedimentos
controle
segurança
scheduler
processos empresariais
Por isso manutenção mainframe raramente permite a fantasia:
“Vou apenas reescrever esse módulo.”
Esse módulo talvez seja chamado às 03h17 por um job que ninguém mencionou.
Pode alimentar um arquivo que vai para outro banco.
Pode produzir uma saída utilizada por um sistema que pertence a outra diretoria.
Em sistemas corporativos:
dependência é a criatura que mora atrás da porta que ninguém abriu.
23. Passo a passo Bellacosa para usar um agente em COBOL
Vamos montar um procedimento.
Etapa 1 — Entender
Use Ask:
Explique este programa COBOL.
Mapeie:
- divisions;
- paragraphs;
- copybooks;
- CALLs;
- arquivos;
- SQL;
- CICS;
- códigos de retorno.
Não altere nada.
Etapa 2 — Mapear dependências
Pergunte:
Quais componentes externos podem ser afetados
por uma modificação neste módulo?
Não confie cegamente.
Confirme no repositório e nas ferramentas existentes.
Etapa 3 — Criar plano
Crie um plano para implementar a mudança X.
Inclua:
- arquivos afetados;
- risco;
- rollback;
- testes;
- dependências;
- critérios de sucesso.
Não implemente ainda.
Etapa 4 — Revisar manualmente
Leia tudo.
Pergunte:
Isso realmente faz sentido?
Se não entende algum item, não aprove.
Peça explicação.
Etapa 5 — Limitar escopo
Em vez de:
modernize o sistema
prefira:
altere somente o módulo CALCJURO
sem modificar interfaces públicas
nem copybooks compartilhados.
Etapa 6 — Executar
Agora sim:
Implemente o plano aprovado.
Etapa 7 — Testar
Nunca aceite:
“Parece correto.”
Use:
Compile.
Execute testes.
Analise return codes.
Compare resultados.
Em COBOL:
COMPILOU
não significa:
FUNCIONOU
e:
FUNCIONOU
não significa:
ESTÁ CORRETO
Etapa 8 — Revisar o diff
Pergunte:
O que mudou?
Por que mudou?
Quais comportamentos podem ser afetados?
Depois olhe você mesmo.
Etapa 9 — Documentar
Registre:
o que a IA sugeriu
o que foi aceito
o que foi rejeitado
por quê
quais testes foram realizados
Isso cria auditoria e aprendizado.
24. Nunca terceirize compreensão
Existe um anti-pattern perigoso:
não entendo
↓
pergunto IA
↓
IA responde
↓
continuo não entendendo
↓
mas executo mesmo assim
Isso é apenas terceirização da ignorância.
🤣
O fluxo correto:
não entendo
↓
IA explica
↓
pergunto novamente
↓
verifico
↓
entendo suficientemente
↓
decido
IA deveria diminuir sua ignorância.
Não escondê-la.
25. Curiosidade — COBOL já viveu uma revolução parecida
Nos anos 1950, programar significava trabalhar muito mais perto da máquina.
Linguagens de alto nível eram uma abstração revolucionária.
Algum programador Assembly poderia olhar COBOL e dizer:
“Agora qualquer incompetente escreve programa!”
Talvez dissesse:
“Esses jovens nem sabem registrador!”
Décadas depois acontece algo curioso.
Programadores modernos dizem:
“Com IA qualquer pessoa gera programa!”
A história gosta de rir.
Compiladores automatizaram a transformação:
linguagem humana-ish
↓
código de máquina
IA automatiza outra camada:
intenção humana
↓
representação técnica
Mas abstração nunca eliminou necessidade de engenharia.
Ela apenas permitiu construir sistemas maiores.
26. Quanto maior a abstração, maior o raio da explosão
Em Assembly, você poderia errar uma instrução.
Com COBOL, uma regra errada poderia afetar milhões de registros.
Com um pipeline automatizado, uma alteração pode chegar a centenas de servidores.
Com agentes:
UM OBJETIVO MAL DEFINIDO
↓
MÚLTIPLAS ALTERAÇÕES
↓
TESTES
↓
AUTOMAÇÃO
↓
PR
Velocidade amplifica coisas boas.
E coisas ruins.
Por isso:
AUTONOMIA ↑
=
GUARDRAILS ↑
27. Guardrail é a cerca elétrica em volta do robô
Guardrail é qualquer mecanismo que limita comportamento.
Exemplos:
não editar produção
não acessar determinados diretórios
não executar determinados comandos
não enviar dados sensíveis
não modificar secrets
não publicar automaticamente
exigir aprovação
Pense em uma locomotiva.
Ela é extremamente poderosa.
Mas só é útil porque existe trilho.
Um agente sem trilho não é uma locomotiva.
É um trem atravessando o estacionamento.
28. E finalmente chegamos às métricas
Depois que uma empresa compra IA para centenas de desenvolvedores, aparece o gerente financeiro.
Ele não pergunta:
“Bob é legal?”
Ele pergunta:
“Quanto custou?”
Depois:
“Quanto economizou?”
Depois:
“Como você sabe?”
E aqui começa a parte adulta.
Não basta medir:
linhas de código
Linhas de código são uma métrica terrível.
Você pode produzir 200 mil linhas de lixo.
Melhores indicadores incluem:
Lead Time
Cycle Time
Defect Rate
Change Failure Rate
MTTR
Test Coverage
Rework
Deployment Frequency
Tempo economizado
Custo por mudança
As versões atuais do ecossistema Bob incluem Bobalytics justamente como uma camada de visibilidade sobre uso e atividade; a atualização de agosto de 2026 adicionou novas visões para observar atividade diária e padrões de utilização.
29. Bobalytics encontra SMF no boteco
O mainframeiro vê analytics e novamente começa a rir.
Porque estamos acostumados com a pergunta:
“O que aconteceu?”
E alguém responde:
“Vamos olhar os registros.”
SMF.
RMF.
Logs.
Auditoria.
Accounting.
Histórico.
Agora o mesmo princípio chega à IA:
Quem utilizou?
Quanto utilizou?
Para quê?
Qual resultado?
Quanto custou?
Qual foi a produtividade?
No futuro talvez ninguém aceite:
“A IA ajudou bastante.”
Precisaremos dizer:
antes: 12 horas
depois: 5 horas
antes: 8 defeitos
depois: 3 defeitos
custo de IA: X
tempo preservado: Y
Aí temos ROI.
30. Cuidado com a “produtividade placebo”
Existe um fenômeno interessante.
Desenvolvedor:
“Estou produzindo 70% mais rápido!”
Pergunta:
“Como você mediu?”
Resposta:
“Senti.”
🤣
Isso não é métrica.
É horóscopo corporativo.
Talvez a IA realmente tenha melhorado produtividade.
Mas precisamos separar:
sensação de velocidade
de:
resultado empresarial
31. O futuro do profissional técnico
A escada provavelmente será algo semelhante a:
NÍVEL 1
"uso autocomplete"
NÍVEL 2
"gero código"
NÍVEL 3
"forneço contexto"
NÍVEL 4
"planejo com agente"
NÍVEL 5
"delego tarefas"
NÍVEL 6
"coordeno subagents"
NÍVEL 7
"conecto ferramentas"
NÍVEL 8
"governo permissões"
NÍVEL 9
"meço resultado"
NÍVEL 10
"assumo responsabilidade"
O último é o mais importante.
Porque quando alguma coisa der errado ninguém aceitará:
“Mas Bob fez.”
A pergunta será:
“Quem aprovou?”
32. O easter egg escondido no SYSOUT
Depois de terminar a alteração, nosso programador encontra no relatório:
IEF142I JOB PAYROLL STEP01 - STEP WAS EXECUTED
Tudo parece normal.
Mais abaixo aparece:
BOB0001I ARTIFICIAL INTELLIGENCE COMPLETED TASK
BOB0002I HUMAN REVIEW REQUIRED
E finalmente:
BOB9999I CAFE REQUIRED BEFORE PRODUCTION
Esse último ainda não existe.
Mas deveria.
33. O iniciante não deve abandonar fundamentos por causa da IA
Se você está começando em COBOL, ainda precisa aprender:
IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION
PIC
MOVE
IF
EVALUATE
PERFORM
CALL
FILE STATUS
COMP
COMP-3
COPYBOOKS
JCL
VSAM
DB2
CICS
Por quê?
Porque se Bob gerar:
MOVE WS-AMOUNT TO WS-BALANCE
você precisa entender o que aconteceu.
Se ele sugerir redefinir:
05 WS-AMOUNT PIC S9(9)V99 COMP-3.
você precisa saber por que isso pode importar.
A IA não elimina fundamentos.
Ela aumenta a penalidade de não conhecê-los.
34. A regra do mestre Jedi do mainframe
Use IA para chegar mais rápido à pergunta difícil.
Não para fugir dela.
Se você gastava três horas procurando onde determinada regra estava implementada e Bob encontra em três minutos:
fantástico.
Use as duas horas e cinquenta e sete minutos economizadas para descobrir:
“Essa regra ainda deveria existir?”
Isso é valor.
35. Programação está mudando de escrever para dirigir
Podemos representar a mudança assim:
ONTEM
Humano
↓
Código
↓
Computador
Hoje:
Humano
↓
IA
↓
Código
↓
Computador
Amanhã:
HUMANO
|
arquitetura / intenção
|
↓
AGENTE
+--------+--------+
| | |
subagent subagent subagent
| | |
código testes análise
\ | /
ferramentas
|
sistemas
O humano sobe um nível.
Mas não desaparece.
36. Talvez “programador” volte ao significado original
Existe uma ironia bonita aqui.
Programar significa essencialmente:
estabelecer uma sequência de ações para atingir um objetivo.
Durante décadas transformamos “programador” em:
pessoa que digita código.
Agentes podem fazer com que o programador volte a ser mais literalmente alguém que:
define objetivos
decompõe tarefas
estabelece restrições
coordena execução
verifica resultado
Ou seja:
talvez IA não esteja destruindo o conceito de programador.
Talvez esteja obrigando a palavra a recuperar seu significado.
37. Checklist Bellacosa antes de deixar Bob trabalhar
Antes:
[ ] Entendo o problema?
[ ] Sei qual é o resultado esperado?
[ ] Identifiquei o escopo?
[ ] Mapeei dependências?
[ ] Pedi um plano?
[ ] Revisei o plano?
[ ] Defini o que NÃO pode ser alterado?
Durante:
[ ] Estou acompanhando as alterações?
[ ] O agente está dentro do escopo?
[ ] Surgiu nova dependência?
[ ] Existem decisões que exigem humano?
Depois:
[ ] Compilou?
[ ] Testou?
[ ] Comparei comportamento?
[ ] Revisei diff?
[ ] Avaliei segurança?
[ ] Documentei decisões?
[ ] Existe rollback?
Se a resposta para metade for:
¯\_(ツ)_/¯
não vá para produção.
38. Epílogo — Bob pergunta se pode fazer deploy
Voltamos ao nosso CPD.
23h58.
PAYR001 foi analisado.
O plano foi criado.
Uma alteração perigosa em TAXAS.CPY foi rejeitada.
Bob modificou o módulo correto.
Os testes passaram.
O programador revisou o diff.
Bob então pergunta:
“Deseja fazer deployment?”
O programador olha para o relógio.
Olha para Bob.
Olha para o calendário.
É sexta-feira.
Ele responde:
NÃO.
Bob pergunta:
“Por quê?”
E o jovem programador finalmente demonstra que aprendeu a mais importante regra da computação corporativa:
“Porque eu posso ser iniciante, Bob, mas não sou maluco.”
☕
Na segunda-feira faremos a mudança.
Com aprovação.
Com backup.
Com rollback.
Com logs.
E com alguém responsável olhando.
Porque o futuro da programação não será decidido por quem consegue produzir mais código.
Será decidido por quem consegue comandar máquinas cada vez mais capazes sem entregar a elas aquilo que nunca deveria ter sido terceirizado: julgamento, responsabilidade e compreensão do negócio.
IBM Bob pode ser copiloto.
Pode ser investigador.
Pode ser planejador.
Pode ser executor.
Pode convocar subagentes.
Pode usar ferramentas.
Pode trabalhar pelo terminal.
Pode atravessar o MCP e conversar com outros sistemas.
Mas alguém ainda precisa ocupar a cadeira do comandante.
E se você está começando agora em COBOL, existe uma oportunidade extraordinária diante de você:
não aprenda apenas a escrever programas.
Aprenda a entender sistemas.
Aprenda por que aquele MOVE existe.
Aprenda quem chama aquele programa.
Aprenda o que acontece quando o job termina com RC=08.
Aprenda por que segurança existe.
Aprenda por que produção exige respeito.
Aprenda a perguntar.
Aprenda a planejar.
Aprenda a discordar da inteligência artificial.
Porque talvez a habilidade técnica mais valiosa da próxima década não seja saber dizer para um agente:
“Faça.”
Será saber olhar para o plano produzido por ele, apoiar a caneca de café sobre a mesa e responder:
“Não, Bob. Essa parte você não vai mexer.”
E explicar exatamente por quê.
☕ Bem-vindo ao Bellacosa Mainframe.
☕ E se amanhã um agente de IA pedir acesso ao seu código COBOL?
Leia o artigo completo publicado na DIO sobre IBM Bob, inteligência artificial, COBOL, mainframe e o futuro da engenharia de software.
