Por que legado é o melhor lugar para começar com IA
Empresas brasileiras rodam sobre sistemas de 10, 15, 20 anos: ERPs em PHP, aplicações Java em servidores defasados, sistemas .NET Framework presos a um Windows específico, rotinas COBOL em bancos e seguradoras. O problema comum não é o código — é o conhecimento que saiu da empresa com quem o escreveu. Ninguém sabe ao certo o que uma rotina faz, e por isso ninguém mexe.
Modelos de linguagem são muito bons exatamente nisso: ler código e explicar em português o que ele faz. É uma aplicação de baixo risco (a IA não altera nada, só descreve), de retorno imediato (documentação em horas, não meses) e que não exige treinar modelo nem comprar plataforma. Os grandes fornecedores chegaram à mesma conclusão: o Google usa o Gemini para gerar especificações a partir de COBOL na sua ferramenta de avaliação de mainframe, e a AWS reposicionou a modernização de mainframe em torno de agentes de IA.
O que funciona hoje
Quatro usos estão maduros. Documentação: gerar mapa de módulos, descrição de telas, rotinas agendadas e dependências externas a partir do código — revisado por quem conhece o sistema. Extração de regras de negócio: transformar condicionais espalhadas em uma lista legível de regras ("desconto de 5% para pedidos acima de X, exceto clientes do tipo Y"), que vira a especificação da versão nova. Geração de testes: criar casos de teste a partir do comportamento atual, que depois servem para validar a equivalência funcional do módulo modernizado. Tradução assistida: converter um módulo PHP 5 para PHP 8, ou uma rotina COBOL para Java, com o desenvolvedor revisando linha a linha.
Em todos os quatro, o padrão é o mesmo: a IA produz o rascunho, o humano valida contra o sistema real. Na JBKR isso significa rodar o teste gerado contra o sistema em produção antes de aceitar qualquer descrição.
O que ainda não funciona
Reescrever um sistema inteiro "com um botão" não funciona, e quem promete isso está vendendo o problema de 2028. Modelos erram em regras implícitas (o que o sistema faz por acidente e o negócio passou a depender), em código com dados embutidos e em integrações não documentadas. Migrações automáticas de linguagem produzem código que compila e se comporta diferente — e a diferença aparece na virada do mês, no fechamento fiscal, no cliente que reclama.
Também não funciona sem governança: colar o código-fonte do cliente em um chat público viola contratos e a LGPD. Use APIs com contrato empresarial que não retêm dados para treinamento, ou modelos privados na infraestrutura do cliente. A JBKR publica esses compromissos na página de IA responsável.
Como a JBKR usa IA no diagnóstico de legado
O diagnóstico de duas semanas da JBKR tem quatro etapas, e a IA entra em três. Inventário: leitura assistida do código, banco e servidor para mapear módulos, rotinas e integrações. Riscos: classificação por urgência (versões sem suporte, backups inexistentes, dependência de uma pessoa) — aqui a IA ajuda a listar, o humano decide o que é grave. Documentação: rascunho gerado por modelo, revisado e testado contra o comportamento real. Roteiro: opções de modernização (no lugar, rehost, replatform, refactor) com estimativas — sem IA, porque estimativa é experiência.
O relatório é entregue por escrito e fica com o cliente, mesmo que a próxima etapa seja feita por outra equipe. Em geral, o resultado é que a empresa descobre que precisa modernizar dois ou três módulos, não o sistema inteiro — e que o resto só precisa de atualização de versão e backup.
O caso do COBOL no Brasil
Bancos, seguradoras e órgãos públicos brasileiros ainda dependem de rotinas COBOL, e o problema é demográfico: os profissionais que as escreveram estão se aposentando, e os fornecedores do mercado apontam a saída dessa geração como o maior risco da década. O fundador da JBKR começou a carreira em dois anos de mainframe IBM no HSBC (z/OS, COBOL, JCL, CICS, DB2) e reconhece o padrão: a documentação existe na cabeça de duas pessoas.
IA muda a economia desse problema: uma rotina COBOL de 3 mil linhas pode ter uma explicação legível e um conjunto de casos de teste em um dia de trabalho assistido, em vez de semanas de leitura. Não substitui o especialista — permite que um especialista cubra dez vezes mais código. Para projetos de grande porte, a JBKR aloca especialistas sob demanda com coordenação técnica do fundador.
Por onde começar
Escolha o sistema que mais dá medo de mexer e peça um diagnóstico — não uma migração. Em duas semanas você terá documentação, riscos e um roteiro escrito, por um custo que cabe no Plano Eventual. Depois decida, com informação, se moderniza por partes, migra para a nuvem ou só atualiza e protege.
Na JBKR o diagnóstico inicial de 30 minutos é gratuito e o relatório de duas semanas é seu. A promessa é a mesma há 20 anos: entender antes de mexer, e não parar a operação.
