Modernizando sistemas legados com agentes de IA

O sistema que ninguém quer tocar

Quase toda empresa com mais de dez anos tem um sistema sobre o qual só se fala em voz baixa. Ele funciona. Registra pagamentos, calcula prêmios, controla estoque — há quinze, vinte, às vezes trinta anos. E ninguém mais o entende por completo. Os autores se aposentaram há tempos ou foram para outras empresas. A documentação ou nunca foi escrita, ou descreve uma versão que não existe mais desde 2011. Testes? Alguns, nas bordas, para as partes inofensivas. O núcleo — os milhões de linhas de COBOL, o Java inchado dos primórdios do J2EE, o monólito PHP que cresceu junto com o negócio como um recife de coral — é uma caixa-preta que faz o que deve, desde que ninguém encoste nela.

Todo mundo sabe que esse sistema é um risco. Ele barra funcionalidades novas, acorrenta a empresa a uma tecnologia moribunda, exige especialistas que já quase não se encontram. E, mesmo assim, ano após ano, ele não é modernizado. Não por inércia, mas por uma conta perfeitamente racional: modernizar sempre saiu mais caro do que a dor de conviver com o velho.

E essa conta estava certa. Quem quer substituir um sistema legado precisa antes entender o que ele faz — não por alto, mas com exatidão, até o último caso especial que algum atendente pediu por telefone doze anos atrás e que desde então vive quietinho no código. Reconstruir esse entendimento, sem testes, sem documentação, sem os autores originais, era uma escavação arqueológica que levava meses e ainda assim ficava cheia de lacunas. Toda migração era, portanto, uma aposta: você reescreve o que só entende pela metade e torce para que a outra metade não fosse justamente aquela de que dependia metade do negócio.

O que mudou na conta

É exatamente aqui que entram os agentes de IA — e não no lugar onde a propaganda os coloca. O valor não está em um modelo escrever código novo rápido. O valor está em ele conseguir ler e explicar código antigo em larga escala.

Essa é a capacidade em que a modernização clássica sempre naufragava. Um agente consegue vasculhar 400 mil linhas de uma linguagem desconhecida e, em horas, escrever o que uma equipe de humanos levaria semanas para juntar a duras penas: quais módulos chamam quais? Onde é calculada aquela fórmula de prêmio, e em quais sete pontos ela é invocada? Qual tabela do banco é peso morto e qual é o coração do sistema? O que aquela rotina de lote de 900 linhas de fato faz, aquela que ninguém abre desde 2014?

Concretamente, a IA desloca quatro blocos de custo que tornavam a migração inviável:

• Entender bases de código grandes. Um agente lê e resume, mapeia dependências, rastreia o fluxo de dados. Meses de arqueologia viram dias — e o resultado é mais completo, porque nenhum humano teria paciência para seguir cada caminho morto.
• Os testes que faltam. E esse é o verdadeiro trunfo: um agente consegue gerar um arcabouço de testes em torno de código sem testes, fixando o comportamento atual — antes de uma única linha ser migrada. Justamente a rede de segurança que faltava.
• Traduzir idiomas de código. Mapear construções COBOL em padrões Java, transformar uma estrutura PHP procedural em algo testável — o trabalho braçal, entediante e propenso a erros que desgasta humanos e produz descuidos.
• Mapear dependências. O que depende do quê? Um agente encontra os acoplamentos implícitos que nenhum diagrama jamais registrou.

Ou seja, a economia realmente mudou. Migrações que três anos atrás não passariam numa análise de custo-benefício hoje são algo a que se consegue atribuir números. Isso não é pouca coisa — é o deslocamento que descongela uma classe inteira de projetos paralisados.

A ordem certa

Só que "viável" não é "automático". O erro mais caro que se pode cometer agora é tirar a conclusão errada dessa nova economia — a saber, mandar o agente simplesmente reescrever tudo. Quem faz isso não aprendeu a lição de trinta anos de reescritas fracassadas; apenas a acelerou.

A ordem que funciona é a mesma que Michael Feathers descreveu vinte anos atrás em Working Effectively with Legacy Code — a IA não muda o método, só reduz o custo de cada passo:

1. Caracterizar. Primeiro você amarra uma rede de segurança. Não escreve testes que provem que o código está correto — escreve testes de caracterização que capturam o que ele de fato faz, manias e tudo. O bug que está no sistema desde 2015, aquele de que três processos a jusante hoje dependem, deixa de ser bug; vira comportamento que você precisa preservar. É exatamente aqui que a IA vale ouro: ela gera esse arcabouço em torno de código sem testes num ritmo que torna o exercício praticável, para começo de conversa.
2. Entender. Com o agente, você desvenda o que o sistema faz e por quê. Não para admirá-lo, mas para reconstruir a intenção por trás do código, que não está escrita em lugar nenhum.
3. Migrar de forma incremental. Você troca um pedaço — um módulo, um endpoint, uma rotina de lote — pela nova implementação. Pequeno o suficiente para que um humano consiga revisar a mudança por completo.
4. Verificar. A rede de segurança do passo 1 diz na hora se o pedaço novo se comporta exatamente como o velho. Se divergir, ou a divergência foi intencional — ou você acabou de achar um defeito antes que ele chegasse à produção.

O ponto central: os testes vêm primeiro, não o código novo. Sem a rede, toda migração vira a velha aposta de novo, só que com um modelo ao volante que produz seus erros com a mesma confiança dos acertos. Com a rede, a aposta vira um processo controlado e reversível.

Strangler Fig, agora com agentes

Existe um padrão inventado exatamente para esse tipo de reconstrução, muito antes da IA: a strangler fig (figueira estranguladora), batizada em homenagem à trepadeira que cresce lentamente sobre uma árvore até substituir por completo a estrutura dela, enquanto a árvore fica de pé o tempo todo. Você constrói o novo em volta do velho, redireciona o tráfego pedaço por pedaço, e só desliga o velho quando nenhum caminho passa mais por ele. Sem data de virada em que tudo troca de uma vez. Sem aquele fim de semana em que metade da equipe reza.

Os agentes são o que finalmente torna esse padrão praticável. A fraqueza clássica da strangler fig era a fachada — o trabalho de entendimento na fronteira entre o velho e o novo, mapear cada chamada que precisa ser interceptada e redirecionada. É justamente esse trabalho que um agente acelera: ele encontra as costuras, explica o que acontece dos dois lados, gera os testes de caracterização para o próximo pedaço que você vai extrair. A figueira cresce mais rápido. Mas ela cresce — galho por galho, cada um aprovado por um humano —, não cai do céu como árvore pronta.

O novo legado que ninguém leu

E aqui espreita a armadilha capaz de inverter todo o exercício. Ela é sedutora, porque parece progresso.

Um agente consegue traduzir um monólito COBOL para Java e produzir código que compila, roda e parece plausível. Dezenas de milhares de linhas, bem formatadas, com nomes convencionais. É tentador registrar isso como pronto. Mas se nenhum humano jamais leu e entendeu esse código, você não resolveu o problema original — você o reproduziu. Trocou uma caixa-preta que ninguém entende por uma nova caixa-preta que ninguém entende. Só que a antiga tem trinta anos de campo de batalha, e a nova não. Você zerou a idade do legado e sacrificou a única propriedade que o tornava valioso: a de que ele comprovadamente funciona.

Esse é o tipo mais caro de dívida técnica — não o código que parece ruim, mas o código que ninguém nunca teve na cabeça. Um monólito traduzido por máquina que a equipe só conhece de rolar a tela é pior que o original, porque perdeu a confiabilidade do original e manteve a impenetrabilidade. A tradução não é o objetivo. O entendimento humano do outro lado é o objetivo — a tradução é apenas a ferramenta para chegar até lá.

Quando é melhor não mexer

Agora o outro lado, o honesto, porque aqui a nova economia induz a duas falácias.

A primeira: que a IA finalmente torna seguro o rewrite big-bang. Não torna. A tentação de simplesmente deixar o modelo reescrever tudo e pular toda a trabalhosa dança incremental é precisamente o clássico desastre de reescrita — só que alcançado mais rápido. O motivo pelo qual rewrites big-bang fracassam às pencas nunca foi a velocidade de digitação. Era que você nunca captura por completo o comportamento antigo, nunca testa por completo o novo contra a realidade, e no dia da virada descobre uma verdade que deveria ter conhecido meses antes. Um agente que cospe 200 mil linhas em uma semana não encolhe esse problema — amplia, porque agora ainda mais código não verificado troca de uma vez. Velocidade sem a rede não é solução; é o mesmo abismo com uma corrida de impulso mais longa.

A segunda falácia é mais sutil: a de que tudo que pode ser migrado deve ser. Não deve. Alguns legados são melhores deixados em paz. Um sistema estável, funcionando, avesso a mudanças — a rotina de lote que roda o fechamento noturno sem reclamar há doze anos, o módulo que ninguém mais toca porque simplesmente funciona — não é um problema à espera de solução. É um problema resolvido. Modernizá-lo só porque é velho troca um sistema comprovado pelo risco de um novo, sem que ninguém tire proveito da troca. O gatilho honesto para uma migração nunca é a idade sozinha, e sim a dor: o sistema barra concretamente uma funcionalidade, escancara brechas de segurança, acorrenta você a uma plataforma que está de fato desaparecendo. Na ausência da dor, ficar parado é a estratégia superior.

As duas falácias desembocam no mesmo ponto. A economia da modernização melhorou — mas, por causa disso, a disciplina passou a contar mais, não menos. Incremental, e não de uma tacada só. Respaldada por testes, e não na esperança. Verificada por humanos, e não carimbada por máquina. A IA reduz drasticamente o custo de cada um desses passos. Ela não lhe dá licença para pular nenhum.

Conclusão

Por décadas, modernizar sistemas legados esteve preso atrás de um único e brutal fator de custo: ninguém podia se dar ao luxo de entender código antigo a fundo o bastante para substituí-lo com segurança. Os agentes de IA dissolvem exatamente esse fator. Eles leem em larga escala, explicam, esticam a rede de segurança de testes que antes faltava. Uma classe inteira de projetos que parecia congelada para sempre de repente virou algo a que se consegue atribuir números.

Mas o deslocamento é no custo, não no método. A ordem certa continua a mesma de antes da IA — fixar o que o sistema faz com testes de caracterização, entender o que está por trás, migrar pedaço por pedaço, verificar contra a rede. Trocar essa ordem por "deixa o modelo reescrever tudo" não constrói um sistema moderno; constrói um legado mais novo, sem testes, que ninguém leu.

É exatamente assim que abordamos o legado na NH Labs. Usamos agentes para entender bases de código que nenhum humano ainda tem na cabeça, e para gerar os testes que faltam antes de mover uma única linha. Depois migramos de forma incremental, em pedaços que um humano consegue revisar e assumir a responsabilidade — nunca como um rewrite big-bang às cegas. O que sai do outro lado não é um monólito traduzido por máquina que ninguém entende, mas um sistema que uma equipe de fato domina. É essa a diferença inteira entre um sistema modernizado e um novo legado que apenas parece mais jovem.