De COBOL para Java com IA: Convertendo o CMS Hospice Pricer

No artigo anterior Análise e Documentação do Código Cobol com IA, descrevi como utilizei o modelo Anthropic Claude Opus 4.6 para analisar e documentar o código COBOL do CMS Hospice Pricer — um sistema do governo norte-americano que calcula pagamentos de assistência a pacientes terminais. A documentação gerada em aproximadamente 4 horas cobriu regras de negócio, casos de teste e a arquitetura dos programas HOSDR210 e HOSPR210.

O passo seguinte foi natural: será que o mesmo modelo consegue converter esse código COBOL em uma API Java funcional? Este artigo descreve esse experimento.

O ponto de partida

O CMS Hospice Pricer é composto por: HOSDR210 — Driver responsável pelo lookup de provedor e wage index geográfico. HOSPR210 — Motor de cálculo de pagamentos com 6.555 linhas de COBOL, cobrindo 24 anos fiscais (FY1998–FY2021). HOSPRATE — Copybook com as taxas de pagamento. CBSA2021 — Dados de wage index com aproximadamente 7.478 registros.

A interface original é uma estrutura binária de 315 bytes (BILL-315-DATA) trocada entre os módulos via chamada COBOL. O processamento é batch, executado em mainframe com JCL.

A meta era transformar tudo isso em uma API REST moderna, mantendo a paridade com as regras de negócio originais.

A abordagem: tlc-spec-driven

Utilizei o skill tlc-spec-driven do Tech Leads Club, um framework de planejamento adaptativo com quatro fases: Specify, Design, Tasks e Execute. O processo gerou 36 tarefas atômicas distribuídas em 8 fases de desenvolvimento, todas executadas pelo Claude Opus 4.6 dentro do VS Code com o GitHub Copilot Agent.

As fases foram: Fase 1 — Scaffold: estrutura Maven, modelos de domínio e códigos de retorno. Fase 2 — Taxas: RateProvider carregando 27 arquivos YAML com as taxas de cada ano fiscal. Fase 3 — Dados de referência: parsers e repositórios em memória para CBSA, MSA e Provider. Fase 4 — Motor de pricing: calculadoras e 4 estratégias de ano fiscal. Fase 5 — API: validação, roteador de ano fiscal, driver e controller REST. Fase 6 — Regressão: dados de paridade, baseline e testes comparativos. Fase 7 — Testes unitários: calculadoras, split RHC, SIA, estratégias e parsers. Fase 8 — Final: cobertura JaCoCo e testes end-to-end.

Todas as 36 tarefas foram concluídas com sucesso.

A API Java resultante foi construída com Java 21 e Spring Boot 3.3.4, expondo um único endpoint: POST /api/v1/hospice/price

Em vez da estrutura binária de 315 bytes do COBOL, a API recebe e retorna JSON. Os dados de entrada incluem: ano fiscal, código de receita, dados do provedor, número de unidades, indicadores de qualidade (QIP) e campos relacionados ao SIA (pagamento adicional para os últimos 7 dias de vida).

A arquitetura interna espelha a lógica COBOL: O ValidationService valida os dados de entrada da mesma forma que o COBOL rejeita registros inválidos. O FiscalYearRouter seleciona a estratégia de cálculo baseada no ano fiscal — assim como a cascata de condições IF no COBOL. O PaymentCalculator, RhcSplitCalculator e SiaCalculator implementam as mesmas fórmulas do HOSPR210. Os 27 arquivos YAML de taxas substituem o copybook HOSPRATE. Os repositórios em memória para CBSA, MSA e Provider substituem os arquivos flat do mainframe. Todo o arredondamento usa BigDecimal com HALF_UP e 2 casas decimais, seguindo o comportamento do COBOL ROUNDED.

Na validação a paridade entre o COBOL e o Java foi validada com 231 testes: 45 testes de integração cobrindo os mesmos casos de teste executados no programa COBOL. 40 testes de regressão comparando resultados diretamente com a saída do RATEFILE COBOL. 10 testes de controller (end-to-end via MockMvc). 136 testes unitários para as calculadoras e componentes internos.

O build Java (mvn verify) passa com 100% dos testes e atinge cobertura JaCoCo acima de 85% nos pacotes de pricing e service.

Os 45 casos de teste (TC01–TC41, com variantes) cobrem: Os 4 tipos de cuidado: RHC, CHC, IRC e GIC. A redução por qualidade (QIP). O add-on SIA para os últimos 7 dias de vida. A regra do split RHC dos primeiros 60 dias de benefício. As transições históricas de formato CHC (unidades em horas vs. incrementos de 15 minutos). Anos fiscais de FY1999 até FY2021. Todos os códigos de retorno: 00, 10, 20, 30, 73, 74, 75 e 77.

O que é diferente entre COBOL e Java

Existem diferenças importantes entre as duas implementações que precisam ser compreendidas: Interface de entrada e saída: o COBOL opera com registros binários de tamanho fixo (315 bytes). O Java usa JSON. Os campos têm os mesmos significados, mas os nomes e o formato são diferentes. Roteamento de código de receita: o COBOL roteia os revenue codes por posição fixa no registro (REV1 na posição 1, REV2 na posição 2, etc.). O Java roteia por tipo de código, independente da posição. Isso gera diferenças em alguns casos de teste onde o código está fora da posição esperada — ambas as implementações estão corretas dentro de seus próprios modelos. Wage index: nos testes unitários Java, o wage index é fixado em 1.0 para isolar o cálculo da fórmula. O COBOL usa o wage index real do CBSAFILE. Por isso, os valores absolutos calculados diferem entre as duas saídas, mas a fórmula subjacente é a mesma. Paridade confirmada: para os 10 casos em que foi possível decodificar o RATEFILE binário do COBOL e comparar diretamente, a lógica de cálculo é equivalente. As diferenças numéricas se explicam pelo wage index utilizado em cada ambiente de teste.

Construído no padrão AS-IS

Uma decisão deliberada deste experimento foi construir o Java no padrão AS-IS do COBOL. Isso significa que todas as funcionalidades do programa original foram reproduzidas, incluindo comportamentos que poderiam ser considerados questionáveis em um sistema moderno.

Por exemplo: a validação de unidades aceita até 999 e rejeita acima de 1.000 com RTC=10 — exatamente como o COBOL. O roteamento de ano fiscal usa a mesma lógica de cascata com revisões de meio de ano em datas específicas (janeiro de 2007, abril de 2001, janeiro de 2016). As taxas de pagamento antigas, codificadas diretamente no fonte COBOL para FY2014 e FY2015, foram mantidas como constantes na mesma posição da arquitetura Java.

Qualquer simplificação ou melhoria das regras de negócio foi intencionalmente deixada de fora. O objetivo era validar a paridade, não modernizar as regras.

Pontos ainda em aberto

A paridade foi confirmada formalmente para 10 casos com decodificação completa do RATEFILE binário. Para os demais 35 casos, os testes Java passam, mas não há um baseline COBOL estruturado que possa ser comparado automaticamente.

Adicionalmente, as taxas de FY2020 usadas em alguns testes de regressão estão incorretas (divergem do copybook HOSPRATE). A API REST em si usa os valores corretos dos arquivos YAML — o problema está apenas nos dados inline de alguns testes unitários. E os YAMLs de FY2016 a FY2019 ainda não foram auditados linha a linha contra o HOSPRATE original.

Esses pontos não invalidam o experimento, mas seriam obrigatórios em um contexto de produção.

O que este experimento demonstra

Em termos técnicos, o Claude Opus 4.6 foi capaz de: Compreender a lógica de um programa COBOL de 6.555 linhas com 24 anos de evolução histórica. Decompor a implementação em tarefas atômicas rastreáveis. Gerar código Java funcional que reproduz o comportamento do COBOL. Criar uma suíte de testes com 231 casos cobrindo os principais cenários.

O processo completo de conversão — da documentação inicial à API testada — levou aproximadamente 4 horas de trabalho com sessões no VS Code usando o GitHub Copilot Agent.

Isto não é código pronto para produção!

Este experimento é um bom ponto de partida para estudar como a conversão de COBOL para Java pode ser conduzida com o apoio de IA. Mas é importante ser claro: o resultado não está pronto para produção.

Para uma conversão real, continua sendo necessário um time multidisciplinar composto por analistas COBOL experientes (para validar o comportamento do sistema original e identificar casos extremos), desenvolvedores Java sênior (para revisar o código gerado e aplicar as melhores práticas da plataforma), e analistas de negócio (para avaliar quais regras devem ser modernizadas, quais comportamentos são bugs históricos que precisam ser corrigidos, e quais foram intencionais).

A IA acelera o trabalho, mas não substitui o julgamento humano sobre o que o sistema deve — e não deve — fazer.

Conclusão

A conversão do CMS Hospice Pricer de COBOL para uma API Java com Spring Boot usando o Claude Opus 4.6 foi bem-sucedida como experimento técnico. A API recebe JSON, aplica as mesmas regras de negócio do COBOL original e retorna os resultados calculados. Os 231 testes passam e a cobertura de código está acima do threshold estabelecido.

A combinação do modelo Opus 4.6 com o framework tlc-spec-driven do Tech Leads Club produziu um resultado estruturado, rastreável e testado — muito diferente de uma conversão ad-hoc.

Se você trabalha com sistemas legados em COBOL e está avaliando caminhos de modernização, este experimento mostra que a IA já é uma ferramenta real de apoio nesse processo. Não substitui o time, mas muda substancialmente a escala e a velocidade do que é possível fazer.

O código-fonte utilizado (CMS.gov) é de domínio público. Para sistemas com dados confidenciais, não envie código para APIs externas sem autorização e sem adotar medidas de anonimização.

O código está disponível no Github.