 |
| Bellacosa Mainframe criando automacao de documentos com o ibm bob |
☕ Um Café no Bellacosa Mainframe
IBM Bob + Docling for watsonx: Quando a Inteligência Artificial Aprende a Trabalhar Como um Analista Mainframe
Da Especificação ao Código, dos Documentos ao Conhecimento — O Futuro da Engenharia de Software Também Está Chegando ao COBOL
"Um bom programador escreve código. Um excelente programador entende o problema antes de escrever a primeira linha. O IBM Bob faz exatamente isso."
Introdução
Durante décadas, nós, profissionais de Mainframe, aprendemos uma verdade que continua absolutamente válida.
Codificar nunca foi a parte mais difícil de um projeto.
O verdadeiro desafio sempre esteve em entender o problema.
Quem trabalhou em bancos, seguradoras, empresas aéreas ou grandes indústrias conhece essa realidade.
Antes de abrir o ISPF e digitar o primeiro:
IDENTIFICATION DIVISION.
havia semanas — às vezes meses — dedicados a:
levantamento de requisitos;
entrevistas com usuários;
documentação funcional;
especificação técnica;
desenho de fluxo;
modelagem de arquivos;
validação com analistas;
revisão de arquitetura.
Somente depois disso alguém começava a escrever COBOL.
Curiosamente, durante muitos anos a Inteligência Artificial fez exatamente o contrário.
Ela recebia um prompt como:
"Crie um sistema de vendas."
E imediatamente começava a gerar milhares de linhas de código.
Parecia impressionante.
Mas para quem viveu projetos corporativos, havia um problema evidente:
Ninguém desenvolve software sério dessa forma.
Foi exatamente essa percepção que levou a IBM a criar uma abordagem muito mais madura, demonstrada no tutorial "Extract structured data from messy documents with Docling for IBM watsonx and IBM Bob".
Mais do que apresentar uma ferramenta, o tutorial mostra uma mudança de paradigma na engenharia de software.
O desenvolvimento tradicional
Vamos imaginar um projeto COBOL.
O usuário diz:
"Precisamos importar Ordens de Compra."
Parece simples.
Mas imediatamente surgem dezenas de perguntas.
Qual o layout?
Quantos fornecedores existem?
Existe autenticação?
Há processamento paralelo?
Como tratar arquivos inválidos?
Qual o limite diário?
Como exportar os resultados?
Essas perguntas não são feitas pelo compilador.
São feitas pelo analista.
Durante décadas essa foi exatamente a função do Analista de Sistemas.
Antes do programador existir, existe o entendimento do negócio.
O velho erro da IA
Grande parte dos copilots atuais funciona assim:
Usuário
↓
Prompt
↓
Código
Isso funciona para pequenos exemplos.
Mas em sistemas corporativos surgem problemas.
Por exemplo:
"Crie um sistema de compras."
Qual banco?
Qual autenticação?
Quais APIs?
Qual arquitetura?
Como tratar erros?
Onde salvar?
Como testar?
Como implantar?
Sem essas respostas, o código pode até funcionar, mas dificilmente será um sistema robusto.
A proposta do IBM Bob
O IBM Bob muda completamente essa lógica.
O fluxo passa a ser:
Ideia
↓
Requisitos
↓
Especificação Técnica
↓
Arquitetura
↓
Implementação
↓
Testes
↓
Correções
↓
Aplicação
Perceba a diferença.
O código deixa de ser o primeiro passo.
Ele passa a ser uma consequência.
Essa abordagem é chamada de Spec-Driven Development (SDD).
O que é Spec-Driven Development?
Imagine construir um prédio.
Ninguém começa levantando paredes.
Primeiro vêm:
levantamento do terreno;
projeto arquitetônico;
projeto elétrico;
projeto hidráulico;
cálculos estruturais.
Somente depois aparece o concreto.
Na engenharia de software deveria ser igual.
O documento de especificação passa a ser o "projeto da construção".
É exatamente isso que Bob produz automaticamente.
O papel do Docling
Outro protagonista do tutorial é o Docling for watsonx.
À primeira vista pode parecer apenas uma biblioteca para ler PDFs.
Mas isso seria reduzir demais sua importância.
O Docling faz algo muito mais sofisticado.
Ele transforma documentos desestruturados em dados compreensíveis para IA.
Imagine uma Ordem de Compra.
Visualmente ela possui:
logotipo;
cabeçalho;
fornecedor;
data;
tabela;
rodapé;
observações.
Para um ser humano isso é trivial.
Para um computador tradicional tudo isso é apenas texto espalhado.
O Docling reconstrói a estrutura lógica do documento.
Ele entende:
títulos;
subtítulos;
listas;
tabelas;
colunas;
imagens;
relações hierárquicas.
Isso muda completamente o jogo.
PDF não é banco de dados
Esse talvez seja o conceito mais importante para um programador COBOL entender.
Durante anos trabalhamos com:
VSAM
DB2
IMS
Sequential Files
Todos possuem estrutura.
Um PDF não.
Ele é praticamente uma fotografia.
Extrair informação dele sempre foi difícil.
Bibliotecas antigas conseguiam apenas:
Texto
Texto
Texto
Texto
As tabelas desapareciam.
As colunas eram misturadas.
Os totais se perdiam.
O Docling preserva a estrutura.
Isso faz toda diferença.
O exemplo do tutorial
O exemplo utilizado é bastante interessante.
O usuário deseja um sistema capaz de:
receber vários PDFs;
identificar Ordens de Compra;
extrair fornecedores;
consolidar produtos;
calcular totais;
exportar CSV.
Nada extraordinário.
Mas observe como Bob trabalha.
Primeiro ele cria um documento chamado:
requirements-intent.md
Esse documento representa apenas a intenção.
Não existe código.
A IA faz perguntas
Em seguida Bob começa a agir como um Analista de Sistemas.
Ele pergunta:
Existe autenticação?
O processamento será paralelo?
Quantos PDFs?
Como tratar falhas?
É exatamente o tipo de pergunta que um analista humano faria.
Essa talvez seja a parte mais impressionante do tutorial.
A IA deixa de ser um "digitador automático".
Ela passa a participar do entendimento do problema.
A especificação técnica
Depois das respostas surge automaticamente:
TECHNICAL_SPEC.md
Esse documento contém:
visão geral;
arquitetura;
APIs;
diretórios;
modelos;
diagramas Mermaid;
componentes.
Quem trabalhou com metodologias tradicionais certamente lembrou imediatamente dos antigos documentos de Análise Estruturada.
A diferença é que agora eles são produzidos automaticamente.
A arquitetura
O sistema criado segue uma arquitetura bastante limpa.
Carbon Design
↓
Flask
↓
Upload
↓
Docling
↓
Markdown
↓
Parser
↓
Analytics
↓
CSV
Observe que cada componente possui responsabilidade única.
Esse princípio é chamado de Separation of Concerns.
É exatamente o mesmo conceito utilizado em aplicações CICS modernas.
O Carbon Design
Outro elemento importante é o Carbon Design System.
Programadores COBOL normalmente não trabalham com interfaces gráficas.
Mas vale entender sua importância.
O Carbon é para aplicações Web aquilo que o ISPF foi para o z/OS.
Um conjunto padronizado de componentes.
Botões.
Menus.
Formulários.
Tabelas.
Ícones.
Tudo consistente.
Isso reduz muito o esforço de desenvolvimento.
O Parser
Após o Docling converter o PDF em Markdown estruturado entra em ação o Parser.
Sua função lembra muito um programa COBOL Batch.
Entrada:
Markdown
Saída:
Objetos estruturados
Ele identifica:
fornecedor;
data;
produto;
quantidade;
preço;
total.
Ou seja, transforma texto em registros.
É praticamente um ETL.
O módulo Analytics
Depois do Parser vem o Analytics.
Aqui os dados passam a ser consolidados.
Por fornecedor.
Por produto.
Por ordem de compra.
Por valor.
Isso lembra bastante programas COBOL responsáveis por gerar relatórios financeiros.
A diferença é que agora os dados vieram de documentos PDF.
O momento mais interessante
Durante os testes algo falha.
Um teste unitário acusa erro.
O parser não tratava corretamente valores:
None
O que Bob faz?
Não pergunta ao usuário.
Não pede ajuda.
Ele:
localiza o erro;
altera apenas o trecho necessário;
executa novamente os testes.
Todos passam.
Esse comportamento lembra muito práticas modernas de DevOps.
Testes primeiro, confiança depois
Durante muitos anos ouvi uma frase:
"Meu programa compilou."
No mundo atual isso significa muito pouco.
O importante é:
Os testes passaram?
No tutorial vemos:
testes unitários;
testes de integração;
validação completa.
Esse é exatamente o fluxo esperado em engenharia moderna.
O resultado final
A aplicação permite:
✔ Upload de múltiplos PDFs
✔ Processamento automático
✔ Extração inteligente
✔ Consolidação
✔ Dashboard
✔ Exportação CSV
Tudo produzido praticamente a partir de documentação.
O que isso significa para um Programador COBOL?
Talvez você esteja pensando:
"Isso serve apenas para aplicações Web."
Na verdade, não.
Imagine adaptar exatamente esse fluxo para o Mainframe.
Recebemos diariamente:
SYSOUT
JES2
SMF
RMF
Dumps
Relatórios RACF
Catálogos
Logs IMS
Logs CICS
JCLs
Listings COBOL
EXPLAIN PLAN do Db2
Documentação técnica
Procedimentos operacionais
Todos esses documentos poderiam ser processados pelo Docling.
Depois enviados ao Granite.
Depois consultados via RAG.
Imagine perguntar:
"Mostre todos os programas COBOL que utilizam o arquivo CLIENTES e fazem EXEC CICS XCTL."
Ou então:
"Quais jobs executam depois do fechamento do movimento financeiro?"
Ou ainda:
"Explique este ABEND S0C7 utilizando os padrões encontrados em incidentes anteriores."
Essa é exatamente a direção para onde a engenharia de software está caminhando.
Uma analogia com o Batch
Podemos comparar todo esse fluxo com um Job Batch.
INPUT
↓
Validação
↓
Transformação
↓
Classificação
↓
Consolidação
↓
Relatório
↓
OUTPUT
A diferença é que agora o INPUT é um PDF.
E parte do processamento é realizada por modelos de IA.
O futuro do Analista de Sistemas
Durante muito tempo acreditou-se que IA substituiria programadores.
Na prática, o que observamos é diferente.
Ela está assumindo tarefas repetitivas:
documentação;
geração de código;
testes;
revisão;
correção.
Mas continua dependendo do conhecimento humano para:
entender regras de negócio;
validar arquitetura;
decidir prioridades;
compreender impactos.
Ou seja, o papel do analista se torna ainda mais estratégico.
Lições para quem está começando em COBOL
Se você é um Programador COBOL Júnior, talvez pense que precisa aprender apenas sintaxe.
Não.
A sintaxe muda.
Os princípios permanecem.
Aprenda:
análise de requisitos;
modelagem;
documentação;
arquitetura;
testes;
versionamento;
integração;
observabilidade.
Esses conhecimentos continuarão valiosos independentemente da linguagem utilizada.
Conclusão
O tutorial da IBM demonstra algo muito maior do que uma nova ferramenta.
Ele mostra que a Inteligência Artificial está amadurecendo.
Em vez de simplesmente gerar código, ela começa a participar de todo o ciclo de desenvolvimento:
entende o problema;
faz perguntas;
escreve especificações;
projeta arquitetura;
implementa;
testa;
corrige;
valida.
Para nós, profissionais de Mainframe, essa evolução é particularmente interessante.
Durante décadas aprendemos que um bom sistema nasce de uma boa especificação, de uma arquitetura sólida e de testes rigorosos. O IBM Bob resgata exatamente essa disciplina, agora potencializada pela IA. O Docling, por sua vez, amplia a capacidade de transformar documentos corporativos em informação estruturada, aproximando o universo dos PDFs, contratos, relatórios e ordens de compra das aplicações inteligentes baseadas em IA.
No fim das contas, a maior lição não é tecnológica, mas metodológica: o futuro pertence aos profissionais que sabem compreender o negócio antes de escrever código. Linguagens, frameworks e ferramentas continuarão evoluindo, mas a capacidade de analisar problemas, projetar soluções e garantir qualidade continuará sendo o verdadeiro diferencial de um engenheiro de software — seja ele programando em COBOL no IBM Z, em Python na nuvem ou utilizando agentes inteligentes como o IBM Bob.
