Engenharia reversa com IA: a regra antes de migrar

O maior erro numa migração é começar pelo código novo sem compreender o antigo. A IA permite investigar sistemas complexos, mas exige perguntas precisas e verificação.

Escrevi ontem que o maior problema de um sistema legado não é a linguagem — é o conhecimento empresarial escondido no código, em procedures, em eventos de tela que ninguém relê há dez anos. Se esse conhecimento é o patrimônio, a pergunta que segue é óbvia: como extrair e documentar esse patrimônio antes de escrever a primeira linha do sistema novo? É aqui que a engenharia reversa com IA entra — não como mágica, mas como método.

TL;DR

Migrar sem conhecer o sistema atual é escrever na sorte — e a IA não vai descobrir esse conhecimento sozinha.

• Despejar o repositório inteiro no prompt não funciona: a janela de contexto acaba, a atenção se dispersa e o modelo devolve resposta genérica escrita com cara de verdade.
• Análise estática é o raio-X: grafos de chamada, módulos por acoplamento, código morto, SQL embutido e duplicação antes de qualquer pergunta.
• Inventário explícito de módulos, fluxos, integrações e regras de negócio: detectar é automático, confirmar o significado é trabalho de quem conhece o negócio.
• Engenharia de contexto substitui o despejo: indexação símbolo → arquivo → linha, recuperação seletiva e investigação incremental em sessões curtas.
• Documentar arquitetura, contratos, regras e decisões em Markdown versionado transforma descoberta em ativo auditável — hipótese sem arquivo e linha não entra.
• Toda afirmação da IA é verificada contra o código: alucinação em migração vira bug em produção, e o mapa final revela as unidades migráveis.

~ 9 min de leitura · 1498 palavras

🎧 Resumo em áudio (~3 min) — pt-BR-FranciscaNeural

O despejo no prompt não funciona — e o motivo é estrutural

O primeiro impulso de todo mundo é o mesmo: zipar o projeto, colar no modelo disponível e perguntar “onde estão as regras de negócio?”. Eu já tentei. O resultado é sempre uma versão mais eloquente do mesmo problema.

A razão é estrutural. Um ERP com duas décadas de vida tem milhões de linhas, centenas de telas e um número que ninguém sabe ao certo de procedures no banco. Mesmo os modelos de contexto longos de hoje não recebem isso de forma útil: a janela acaba, o custo explode, e o mecanismo de atenção do modelo se dispersa entre arquivos que não têm nada a ver com a pergunta. O modelo então preenche as lacunas com o padrão mais provável — e o padrão mais provável de uma codebase desconhecida é genérico, não é o seu negócio.

O código que ninguém consegue manter é pior que o legado — e o risco aqui é o mesmo: uma IA que respondeu com confiança sobre um sistema que ela nunca investigou produz exatamente esse tipo de código. A resposta errada escrita com segurança é pior do que o silêncio, porque entra no repositório com cara de verdade.

Investigação de sistema é um processo, não uma pergunta. A IA é boa nisso — desde que receba um método.

Análise estática: o raio-X antes de qualquer pergunta

Antes de conversar com a IA sobre o sistema, é preciso medir o sistema. Análise estática é isso: extrair fatos do código sem executar nada.

O que sai de um primeiro raio-X, em qualquer stack — Delphi, .NET Framework, Java, Visual Basic:

• Ponto de entrada e grafos de chamada: quem chama o quê, de onde o sistema realmente começa a rodar.
• Módulos por acoplamento: os arquivos que todo mundo importa (e que, portanto, carregam as regras centrais).
• Código morto: funções sem chamador, telas que nenhum menu abre — o sistema tem camadas de esqueleto que só o grafo revela.
• SQL embutido e acesso a dados: onde o sistema toca o banco, e quais tabelas concentram escrita.
• Duplicação: a mesma regra escrita três vezes em três lugares é a candidata número um a divergir em produção.

Nessa etapa a IA trabalha como processador de padrões: ela varre mil arquivos procurando estruturas — chamadas, dependências, padrões suspeitos — muito mais rápido do que qualquer humano. Mas o output dela é material de investigação, não conclusão. A análise estática aponta onde olhar; decidir o que aquilo significa continua sendo trabalho de quem conhece o negócio.

Inventário: módulos, fluxos, integrações e regras

Com o raio-X na mão, o segundo passo é transformar conhecimento disperso em inventário explicitado. O sistema legado é um acúmulo de coisas em execução — módulos, telas, procedures, jobs agendados, integrações, relatórios — e quase nenhuma dessas coisas tem registro central.

O inventário que funciona tem, para cada elemento: nome, onde vive (arquivo, banco, agendador), o que faz em uma frase, quem consome, nível de conhecimento (documentado, deduzido, desconhecido). É uma tabela, não um ensaio.

Fluxos merecem o mesmo tratamento: o caminho do pedido desde a tela de venda até o estoque, o financeiro e o NF-e. Integrações então — cada importação de arquivo, cada webservice, cada e-mail automático disparado por rotina é um contrato informal que precisa ficar registrado antes que alguém quebre sem saber.

Regras de negócio formam a terceira camada: aquele desconto limitado por região, o cliente com saldo vencido que não recebe prazo, o cálculo de comissão com exceção para determinada filial. Elas moram em eventos de tela, procedures e pontos de verificação — e são justamente o que nenhuma análise de código etiqueta sozinha.

Aqui a IA muda de papel: ela ajuda a encontrar candidatos a regra (validações, condicionais, cálculos com constantes mágicas), mas o inventário de regra de negócio só fica pronto quando alguém do negócio confirma o significado. Detectar é automático; significar é humano.

Engenharia de contexto: indexar, recuperar, investigar em sessões

O método que substitui o despejo é a engenharia de contexto: organizar o acesso do modelo ao código sob demanda, em fatias certas, no momento certo.

Três componentes:

1. Indexação. Símbolo → arquivo → linha. Cada função, tabela e procedure mapeada num índice que a IA pode consultar em vez de “saber de cor”. Ferramentas modernas de codificação já fazem boa parte disso; num sistema proprietário, construir o índice é hora investida — e rende em todas as sessões seguintes
2. Recuperação. Dada uma pergunta (“onde o prazo de pagamento é calculado?”), o índice recupera os arquivos relevantes e somente eles entram no contexto. O modelo trabalha com 50 linhas pertinentes em vez de 200 mil irrelevantes
3. Investigação incremental. Sessões curtas com objetivo único: entender um módulo, traçar um fluxo, listar os efeitos de uma alteração. O resultado de cada sessão é registrado e alimenta a próxima. O conhecimento cresce como um mapa, não como uma resposta gigante.

O detalhe que decide tudo é o tipo de pergunta. “O que esse sistema faz?” é pergunta ruim. “Liste os pontos onde a tabela de preço é consultada e o que cada um valida” é pergunta boa: verificável, com escopo, com resposta que pode ser conferida no código. A IA não precisa conhecer previamente o sistema; nós precisamos estruturar a investigação e reconhecer o que ainda não sabemos.

Numa base proprietária, com regra de cliente dentro, esse trabalho roda inteiro em infraestrutura local — índice, recuperação e modelo. Vale reforçar em tempos de agente com acesso ao repositório inteiro: o ganho de produtividade convive com o controle de onde os dados passam.

Documentar em Markdown versionado — o ativo que fica

Investigação sem registro é trabalho que expira. O destino natural desse trabalho é documentação viva, e o formato que sobrevive a duas décadas de ferramentas é o mais simples possível: Markdown versionado junto do código.

Quatro documentos sustentam uma migração:

• Arquitetura atual — módulos, camadas, dependências entre eles, pontos de entrada.
• Contratos — integrações, schemas trocados, endpoints, formatos de arquivo, o que cada parte espera da outra.
• Regras de negócio — o inventário da etapa anterior, com referência do arquivo e da linha onde cada regra foi encontrada.
• Decisões — por que uma regra é assim, quem confirmou, quando. Uma linha por decisão é o suficiente.

Versionado é a palavra-chave: quando a documentação vive no repositório, ela entra no pull request, é revisada no mesmo fluxo do código e não vira pasta morta num compartilhamento. Quando alguém altera uma regra, altera a linha da documentação no mesmo commit — ou o reviewer pergunta por quê.

E é essa documentação que impede a alucinação de virar arquitetura. Toda afirmação da IA sobre o sistema carrega uma referência: arquivo, linha, procedure. Se o modelo afirma que “o desconto é validado no fechamento do pedido”, a documentação aponta o arquivo e a linha onde isso acontece. Sem referência, é hipótese — e hipótese não entra na documentação, entra na lista de verificação. O modelo pode errar; o sistema de registro não deixa o erro passar despercebido.

O resultado prático: no lugar de “o sistema novo vai replicar o atual, esperamos que os desenvolvedores lembrem de tudo”, a migração parte de um mapa auditável. Módulos que estão compreendidos e isolados viram unidades migráveis. Módulos acoplados ao resto esperam a próxima rodada. E a priorização deixa de ser palpite — vira leitura de grafo, risco e volume de regras.

De que adianta ter IA se o sistema continua desconhecido

O ponto que sustenta este texto: a IA não precisa conhecer previamente o sistema — é o papel dela investigar o que não conhece, com método. O que não pode acontecer é ignorar o que ainda não sabemos. Reconhecer a fronteira entre o que foi verificado e o que é hipótese é a competência que separa quem usa engenharia reversa com IA para investigar de quem usa IA para improvisar.

Depois que o mapa existe — módulos, fluxos, contratos, regras, decisões — a conversa sobre o código novo muda de natureza. Não é “reescrever essas telas em Angular e torcer”; é “migrar a unidade X, cujo comportamento está documentado e tem testes de caracterização”. O maior erro de uma migração é começar pelo código novo; o segundo maior é achar que compreender o antigo é opcional.

A ponte natural para a próxima etapa: com o sistema atual compreendido e documentado, como escolher a arquitetura para a qual vamos migrar? Esse é o próximo artigo.

Leitura relacionada

• O maior problema de um sistema legado não é a linguagem — o artigo anterior desta série: o risco real do legado é o conhecimento que ninguém mais sabe explicar.
• IA na modernização de sistemas legados — o mapa conceitual de onde a IA ajuda (e onde ela não pode substituir decisão).
• Banco de dados: arqueologia na empresa — quando o histórico do banco é o único registro vivo das regras do negócio.