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.
- 1StranglerFigApplicationMartin Fowler, 2004
- 2Refactoring: Improving the Design of Existing Code (2nd ed.)Martin Fowler, 2018
- 3Strangler fig patternAWS Prescriptive Guidance
- 4Technology RadarThoughtworks
Leia também
Code review com IA sem baixar a régua de qualidade
Quem usa assistente de IA escreve código menos seguro e fica mais confiante de que ele é seguro. O gate precisa ficar mais rígido, não mais frouxo.
Ler o artigoA dívida técnica nova: código que você não escreveu
A dívida antiga tinha alguém que sabia por que tomou o atalho. A nova cresce em silêncio, e a descoberta acontece durante um incidente.
Ler o artigoTestes gerados por IA: cobertura não é confiança
Cobertura responde se a linha rodou, não se alguém verificou o resultado. A pergunta certa é se algum teste falha quando você quebra o comportamento.
Ler o artigo