Pular para o conteúdo principal
Voltar para o blog
Engenharia
4 min de leitura

Modernizar legado com IA como arqueóloga

Aquela condição estranha no cálculo de frete resolve um caso real que ninguém documentou. Descobrir isso é o custo dominante do projeto.

Todo sistema legado que ainda roda tem uma coisa em comum: ele funciona. Pode ser feio, pode ser caro de manter, pode assustar quem chega, mas alguém depende dele todo dia. É por isso que modernização é um problema de risco antes de ser um problema de código.

O gargalo é entender, não escrever

Quem já participou de um projeto de modernização sabe que a parte lenta não é digitar o código novo. É descobrir por que o código velho faz o que faz.

Aquela condição estranha no cálculo de frete provavelmente resolve um caso real que ninguém documentou. O campo que parece morto alimenta um relatório que alguém da diretoria abre uma vez por trimestre. A regra que contradiz a especificação foi escrita depois de um incidente.

Esse é o custo dominante, e é exatamente onde a IA muda a economia do trabalho.

IA como arqueóloga

O uso de IA que melhor paga em legado não é gerar o sistema novo. É reconstruir o entendimento do sistema antigo.

Quatro tarefas funcionam bem hoje:

  • Explicar um trecho denso em linguagem natural, o que dá um ponto de partida para quem nunca viu aquele módulo.
  • Mapear dependências e apontar quem chama o quê, inclusive em linguagens que o time atual não domina.
  • Extrair regras de negócio candidatas de código procedural longo, produzindo uma lista para o especialista de domínio confirmar ou negar.
  • Gerar testes de caracterização, que descrevem o comportamento atual em vez do desejado.

O último item é o mais subestimado. Teste de caracterização é o que transforma refatoração arriscada em refatoração verificável, e escrevê-los à mão para um módulo grande é tedioso o bastante para o time sempre adiar.

Onde ela erra e você paga caro

O modo de falha característico é a explicação plausível e errada. A IA lê a estrutura do código e produz uma narrativa coerente que pode ignorar o motivo histórico real.

Ela também não vê o que não está no repositório: o procedimento no banco, o job agendado no servidor, a integração que só existe num arquivo de configuração, o acordo verbal com o time de operações.

Por isso a regra prática é: use a saída da IA como hipótese, nunca como documentação. Toda regra extraída precisa de confirmação de alguém do domínio ou de um teste que a exercite contra o sistema em execução.

A figueira estranguladora continua sendo o padrão

Martin Fowler descreveu o padrão da figueira estranguladora a partir de uma imagem literal: a planta cresce em torno da árvore hospedeira até substituí-la, sem nunca derrubá-la de uma vez.

Aplicado a software, significa colocar uma camada de roteamento na frente do sistema antigo e mover funcionalidade para o novo em fatias, uma de cada vez, com a possibilidade de voltar atrás em cada fatia. A AWS publica um guia prescritivo do mesmo padrão com detalhes de implementação para quem precisa de um caminho concreto.

A IA não substitui esse padrão, ela o acelera. Ajuda a decidir qual fatia tem menos acoplamento, a gerar o código de adaptação entre os dois mundos e a manter as duas versões em paridade durante a transição.

Reescrita completa continua sendo má ideia

A tentação é óbvia. Se a IA escreve código rápido, por que não reescrever tudo?

Porque o que torna a reescrita completa perigosa nunca foi a velocidade de digitação. É a perda de conhecimento acumulado em anos de correções, o congelamento de funcionalidade durante a transição e a incapacidade de validar equivalência num salto grande.

O Technology Radar da Thoughtworks vem registrando essa ressalva em relação à geração de código em larga escala: volume alto sem revisão proporcional cria um sistema novo que ninguém entende, o que é o mesmo problema do legado, só que sem os anos de estabilidade.

Refatoração ainda é a disciplina que segura o resultado

O catálogo de refatorações de Martin Fowler descreve movimentos pequenos com comportamento preservado, cada um verificável.

Esse tamanho de passo não é preciosismo. Ele existe porque erro em passo pequeno é encontrado em minutos, e erro em passo grande é encontrado em produção. Com IA a tentação é aumentar o passo, já que gerar quinhentas linhas custa o mesmo que gerar cinquenta. O custo aparece na revisão e no incidente, não na geração.

O que isso significa para o seu time

Comece pela arqueologia, não pela reescrita. Escolha o módulo que mais assusta e use IA para produzir um documento de entendimento mais uma suíte de testes de caracterização. Valide ambos com quem conhece o domínio.

Depois escolha uma fatia pequena e estrangule, com roteamento na frente e rollback disponível.

Se ao final de três meses o time entende o legado melhor do que entendia e substituiu duas fatias sem incidente, a modernização está indo bem. Se substituiu dez e ninguém sabe explicar as regras, o problema só mudou de lugar.

Referências

As fontes usadas neste texto, para você conferir e ir mais fundo.

  1. 1StranglerFigApplicationMartin Fowler, 2004
  2. 2Refactoring: Improving the Design of Existing Code (2nd ed.)Martin Fowler, 2018
  3. 3Strangler fig patternAWS Prescriptive Guidance
  4. 4Technology RadarThoughtworks