Sistema antigo sem código-fonte: a IA leu a regra, até o centavo

Pense numa distribuidora cujo sistema de cobrança roda há mais de uma década. O fornecedor não existe mais, o código-fonte se perdeu, e ninguém na empresa sabe dizer a regra exata de multa, juros e desconto. O problema aparece quando alguém decide reescrevê-lo: se a versão nova cobrar um centavo diferente, os boletos deixam de bater com o histórico e a conciliação vira dor de cabeça. A X-Apps, empresa de software que escreve este blog, reproduziu essa situação em laboratório, com um programa feito para o teste, para ver até onde a IA chega. Ela leu a regra inteira do programa fechado, inclusive o detalhe que muda um centavo, e uma bateria de testes contra o original conferiu a leitura.

A IA já consegue abrir um programa desses e ler o que ele faz, mas também inventa, e quem aprova a reescrita precisa saber se o que ela descreveu é a regra de verdade ou um palpite bem escrito.

É um problema comum. No GPSi, o aplicativo de inspeções das equipes de campo do Grupo GPS, a X-Apps construiu a versão iOS partindo de um app Android sem código-fonte e sem documentação. Lá a técnica foi outra, sem a ferramenta deste teste: a equipe gravou cada conversa do aplicativo Android com o servidor, função por função, e dessa gravação saiu a especificação, que ficou com o cliente.

O teste: REA (Reverse Engineer Anything) diante de um programa fechado

O REA é uma ferramenta de código aberto que dá à IA instrumentos para abrir programas e entrega cada conclusão com a evidência por trás dela. O texto de outubro sobre a ferramenta traz a apresentação e a parte legal: antes de abrir programa de terceiro, confira na licença se a engenharia reversa é permitida.

O programa examinado foi escrito para o experimento. Imita o módulo de cobrança de um sistema de gestão antigo e calcula quanto cobrar de um boleto pago em atraso ou antecipado. O teste foi cego, isto é, quem investigava não conhecia a resposta: uma IA escreveu o programa com uma regra escolhida por ela, cheia de peculiaridades do tipo que derruba migração, e lacrou o código e o gabarito numa pasta. Outra IA, o Claude Code operando o REA, recebeu o que um usuário saberia: entram valor, vencimento, data do pagamento e categoria do cliente, e sai o valor a cobrar. Do programa, recebeu só o arquivo pronto, feito em .NET, plataforma comum em sistemas de gestão para Windows.

A pergunta foi fechada: qual é exatamente a regra que calcula o valor a cobrar de um título pago em atraso ou antecipado?

1. Lacrar o código e o gabarito longe de quem investiga.
2. Ler o programa sem executá-lo.
3. Supor, separando o que o programa mostra do que é hipótese.
4. Testar a reescrita contra o programa original, caso a caso.
5. Conferir o gabarito só no fim.

O que saiu da leitura em dois minutos

Sem executar o programa, o REA listou em segundos todas as funções do arquivo com as instruções de baixo nível de cada uma, as que o computador executa. Programa reescrito em linguagem legível ele não devolve: quem remontou o cálculo a partir das instruções foi a IA, e a leitura inteira, até a especificação escrita, levou cerca de dois minutos. O quadro é para quem quer ver a evidência; a frase depois dele diz o que mostra. É a saída da ferramenta para o cálculo dos juros, condensada para caber na tela:

Cobranca.Tit::CalcJ
IL_0000 ldarg.0
IL_0001 call   System.Decimal::op_Explicit r8(System.Decimal)
IL_0006 conv.r8
IL_0007 ldsfld Cobranca.Tit::fatD : r8
IL_000c mul
IL_000d ldarg.1
IL_000e conv.r8
IL_000f mul
IL_0010 ldc.r8 100
IL_0019 mul
IL_001a call   System.Math::Floor r8(r8)
IL_001f ldc.r8 100
IL_0028 div

Em língua comum, os juros são calculados num tipo de número aproximado e depois cortados no centavo, sem arredondar. A IA anotou ali mesmo a consequência: em parte dos títulos, esse corte cobra um centavo a menos que a conta exata.

A IA marcou cada afirmação como confirmada pelo código ou como hipótese, quando dependia da plataforma, como o arredondamento padrão. A regra recuperada:

1. Vencimento no fim de semana passa para segunda para decidir se houve atraso, mas os juros contam do vencimento original.
2. Cada categoria de cliente tem uma carência, e a C não tem nenhuma; passou dela, cobra tudo desde o vencimento.
3. A multa manda o meio centavo para o número par, o chamado arredondamento bancário; o desconto manda o meio centavo para cima.
4. Juros simples e diários, sobre o valor do título para o cliente A e sobre valor mais multa para B e C.
5. Multa e juros somados têm um teto, uma porcentagem do valor.
6. Título pequeno paga um acréscimo fixo no lugar de multa e juros.
7. Pagamento antecipado ganha desconto em duas faixas, conforme a categoria, e a C nunca tem.

A especificação, o documento que descreve a regra para quem vai reescrever, traz os valores. Um resumo dela, seguido de casos rodados no programa original:

Carência (dias após o vencimento ajustado):  A = 3 | B = 1 | C = 0
Multa: 2% do valor, meio centavo para o par
Juros: 0,033% ao dia, simples, desde o vencimento original
       base: A = valor | B e C = valor + multa
       conta em número aproximado, cortada no centavo
Teto de multa + juros: 20% do valor
Título abaixo de 30,00: acréscimo fixo de 2,50
Desconto por antecipação: 10 dias ou mais A = 3%, B = 2%
                          5 a 9 dias      A = 1,5%, B = 1%

valor     vencimento  pagamento   cat.  cobrado
1000.00   2026-03-10  2026-03-13  A     1000.00   carência
1000.00   2026-03-10  2026-03-25  A     1024.95   multa e juros
1000.00   2026-03-10  2026-03-25  B     1025.04   juros sobre a multa
1000.00   2026-03-14  2026-03-17  C     1021.00   vencimento no sábado
29.99     2026-03-10  2026-03-20  C     32.49     título pequeno
850.50    2026-03-20  2026-03-10  B     833.49    pagamento antecipado
10000.00  2024-03-04  2024-06-13  A     10533.29  o centavo dos juros

Onde a leitura parou e o teste assumiu

O passo seguinte foi usar o programa original como juiz. A IA reescreveu a regra só a partir da especificação e montou uma bateria de testes, que roda o programa antigo e a reescrita com as mesmas entradas e compara as respostas.

A primeira rodada teve 4.270 casos, parte escolhida para cair nos limites da regra, parte sorteada. Bateram de primeira todos menos 24, e nesses o erro era da reescrita, que quebrava com valores absurdamente grandes. A leitura tinha deixado esse canto como dúvida em aberto, e em parte deles o programa original também aborta, sem devolver valor. Nenhuma hipótese sobre a regra de negócio caiu. Na segunda rodada, com a reescrita corrigida e mais casos, não sobrou divergência nenhuma.

O último caso do quadro, um título alto pago com meses de atraso, tem juros de R$ 333,30 pela conta exata. O sistema antigo cobra R$ 333,29, porque faz a conta em número aproximado e corta no centavo. A leitura já tinha descrito esse comportamento, e a reescrita nasceu reproduzindo-o. O teste fez duas coisas que a leitura não faz: provou, caso a caso, que a reescrita devolve o mesmo valor do sistema antigo, e mediu o custo de "consertar" a conta. Trocada a conta aproximada pela exata, a bateria final acusou divergência em 97 casos. Num sistema real, seriam boletos que deixam de bater com o histórico.

Só no fim o gabarito foi aberto, e todas as peculiaridades escondidas no programa estavam na especificação.

O que este teste não prova

O programa é pequeno e foi escrito para o teste; um sistema real tem regras que dependem de banco de dados, feriado e cadastro. O .NET guarda nomes de funções, ainda que abreviados, e instruções mais fáceis de ler, o que o torna o cenário favorável; programa em C ou Delphi, ou embaralhado de propósito, dá muito mais trabalho. Os poucos minutos do experimento não valem como prazo de projeto. Foi uma execução só, sem comparar custo com trabalho manual. As instruções extraídas foram enviadas ao provedor do modelo de IA, porque o REA roda no computador local e a IA não; com programa de terceiro, isso pesa.

E se o sistema antigo roda na nuvem, acessado pelo navegador? Aí a ferramenta observa só o lado de cá: a página, os programas que o navegador baixa e as conversas dele com o servidor. A versão 6.9.0, publicada em 12 de novembro, acrescentou a comparação entre os endereços que esses programas chamam e o tráfego gravado, e o inventário do documento que descreve a conexão com outros sistemas, quando a empresa tem esse arquivo. O código que roda no servidor do fornecedor continua fora de alcance, e das regras aplicadas lá dentro só se vê o resultado que volta.

O que fica para quem vai modernizar

O que sai de um trabalho desses é um documento com a regra passo a passo, a evidência de cada item e casos de aceitação com a saída real do sistema antigo. Os casos viram os testes do sistema novo. Para os primeiros passos, há o texto sobre o que fazer quando o fornecedor some e o sistema continua no ar.

Uma parte a empresa faz sozinha, antes de contratar alguém. Escolha uma regra crítica, de preferência a que mexe com dinheiro, e junte casos reais de entrada e saída do sistema antigo, como boletos já pagos com valor, vencimento, data do pagamento e valor cobrado. Guarde esse material como gabarito antes de qualquer reescrita.

A IA lê a regra em minutos; quem prova que a regra está certa é o teste contra o sistema antigo.

Fontes: repositório morluto/rea, README e notas da versão 6.9.0 de 12/11/2026, consultados em 14/11/2026. Experimento da X-Apps de 14/11/2026: programa de teste em .NET 8, REA 6.9.0 operado pelo Claude Code, bateria de 4.270 casos contra o programa original.