Vale a pena reescrever o sistema legado da empresa com IA? Em outubro de 2026, a pergunta ganhou um número concreto. Um desenvolvedor publicou a reescrita de um compilador inteiro, feita por IA em cerca de duas semanas, por pouco mais de US$ 24 mil. Antes disso, outra tentativa no mesmo projeto tinha gastado mais de US$ 400 mil sem chegar ao fim. A diferença entre as duas contas interessa a qualquer empresa que depende de um sistema legado, ou seja, de um programa antigo que ninguém ousa trocar. O motivo pelo qual deu para confiar no resultado interessa ainda mais.
O caso que mudou a conta do sistema legado
O projeto se chama ts-rust e está aberto no GitHub. Ele traduz para outra linguagem de programação o compilador que a Microsoft mantém para o TypeScript, uma das linguagens mais usadas no mundo. O autor afirma que modelos de IA escreveram tudo e que ele nunca leu uma linha do código.
Vale explicar o tamanho da tarefa. Um compilador é o programa que converte o que o programador escreve em algo que a máquina executa. Um erro nele contamina tudo o que passa por ali, por isso costuma estar entre os softwares mais testados que existem.
A primeira tentativa rodou por meses, escreveu mais de 1,3 milhão de linhas e travou em cerca de 84% de compatibilidade com o original. Em seguida, a segunda recomeçou do zero, com outro modelo. Em dez horas havia uma versão inicial funcionando e, em duas semanas, o trabalho estava publicado. O custo informado foi de US$ 24.047.
Dois recados saem daí. Em primeiro lugar, escrever código deixou de ser a parte cara de um projeto de software. Em segundo lugar, o preço varia muito conforme a ferramenta e o método. A primeira rodada custou mais de dezesseis vezes o valor da segunda e, ainda assim, não terminou.
Por que deu para confiar: 181.711 testes herdados
Como alguém publica um programa que nunca leu? A resposta está em um número menos comentado. O compilador original tinha 181.711 testes automáticos e, segundo o autor, a versão nova passa em todos.
Um teste automático é uma pergunta com gabarito. Ele entrega uma entrada ao programa e confere se a saída é a esperada. Assim, com mais de cem mil deles, a IA tinha uma régua para medir cada tentativa, e o autor tinha como saber se o resultado prestava. Em outras palavras, o projeto já sabia com exatidão o que o programa deveria fazer.
Essa régua não veio de graça. Aqueles testes resultam de anos de trabalho de uma equipe grande, que anotou cada caso estranho que encontrou. Quando a IA chegou, portanto, o conhecimento já estava organizado em um formato que uma máquina consegue conferir sozinha.
Esse é o ponto que a leitura apressada do caso ignora. A IA escreveu rápido porque alguém, ao longo de anos, tinha escrito o gabarito.
O que o sistema legado da sua empresa não tem
Agora olhe para o sistema legado da sua empresa. Pode ser o programa de faturamento que roda desde 2008, ou o controle de produção feito por um fornecedor que fechou as portas. Quantos testes ele tem? Na maioria das empresas, nenhum.
Em geral, as regras vivem em outro lugar. Estão na cabeça de quem opera, em uma planilha paralela, em um ajuste de 2015 que ninguém documentou. Parte delas nem está no código, porque o time aprendeu a contornar o programa na mão.
Por isso a etapa cara mudou de lugar. Em fevereiro de 2026, a Anthropic publicou um material sobre modernização de programas antigos de bancos e governos. O texto resume o problema em uma frase: entender o código antigo custava mais do que reescrevê-lo. A escrita ficou barata. O entendimento, no entanto, continua exigindo gente que conhece o negócio.
O tamanho do passivo também pesa. Em pesquisa da McKinsey de 2020, diretores de tecnologia de grandes empresas estimaram a dívida técnica entre 20% e 40% do valor de todo o parque tecnológico. Além disso, de 10% a 20% do orçamento de novos produtos ia para remendar o que já existia.
Os limites que o próprio caso admite
Convém ler as letras miúdas. O autor chama o trabalho de versão inicial e avisa que ela ainda não substitui o original em todo projeto. Funções de apoio ao editor ficaram de fora, e há diferenças conhecidas em alguns cenários.
Um compilador, além disso, é um caso favorável. Ele recebe texto e devolve texto, sem base de clientes, sem integração bancária, sem nota fiscal. Um sistema legado de empresa, por outro lado, conversa com outros programas, guarda anos de histórico e não pode parar no fechamento do mês.
Existe ainda a questão de quem responde. Publicar código que ninguém leu é uma escolha aceitável em um projeto aberto e experimental. No faturamento de uma empresa, porém, o risco tem outro tamanho.
Como reescrever um sistema legado com IA sem apostar a operação
O caminho que funciona inverte a ordem intuitiva. Primeiro se constrói o gabarito. Depois se reescreve.
Extraia as regras antes de mexer. A IA lê o código antigo, mapeia o que depende do quê e descreve em português o que cada parte faz. Quem conhece a operação revisa essa descrição, porque o código só mostra o comportamento de hoje. O comportamento correto, só a operação conhece.
Transforme o comportamento atual em testes. Registre entradas e saídas reais do programa antigo e exija que o novo devolva as mesmas respostas. Assim a empresa cria a régua que o caso do compilador já tinha pronta.
Rode os dois lado a lado. Durante um período, a versão nova processa os mesmos dados que a antiga, sem valer. Cada diferença vira uma decisão: é erro da versão nova ou um defeito antigo que vale corrigir?
Comece por uma parte de fronteira clara. Um módulo de relatórios ou de cadastro, por exemplo, ensina o método com risco baixo. O coração financeiro fica para quando o time já confia na régua.
Decida o que não vai junto. Todo sistema legado carrega relatórios que ninguém abre e regras criadas para clientes que já saíram. A reescrita é a chance de deixar isso para trás, desde que alguém da operação confirme o descarte. Como resultado, o programa novo fica menor e mais barato de manter.
Onde entra um departamento de IA
Esse trabalho tem mais de mapeamento do que de programação. Na AI Infinity Global Company, o método começa por examinar a operação e visualizar o processo como ele acontece de fato. Atalhos e exceções entram no mapa. Só então vem a etapa de desenvolver.
O time que a Infinity instala dentro do cliente reúne engenheiro de software, arquiteto de integrações e profissional de qualidade. Este último é quem cuida dos testes. Além disso, o código, a documentação e os agentes criados pertencem ao cliente. Desse modo, o programa novo já nasce com o que faltava ao antigo: regras escritas e um gabarito para conferir cada mudança.
Quer saber se o seu sistema legado é candidato a uma reescrita? A conversa começa pelo mapa do processo. A linguagem de programação se escolhe depois.
Perguntas frequentes
O sistema legado não tem teste nem documentação. A IA consegue extrair as regras do código?
Consegue boa parte. Ela lê o código, aponta dependências e descreve os fluxos em linguagem comum, inclusive em linguagens que quase ninguém mais domina. O limite, porém, é que ela descreve o comportamento atual. Um defeito antigo aparece na descrição como se fosse regra, e as regras que vivem em planilhas ou no hábito do time nem aparecem. Por isso a extração precisa da revisão de quem opera o processo todos os dias. Sem essa etapa, a empresa corre o risco de copiar para o programa novo os erros do antigo.
Como saber se o programa novo faz exatamente o que o sistema legado fazia?
Com duas provas combinadas. A primeira são testes montados a partir de entradas e saídas reais do programa antigo. A segunda é a execução em paralelo, em que os dois processam os mesmos dados por semanas e uma rotina automática compara as saídas. Vale definir antes qual diferença é aceitável. Arredondamento de centavo pode passar, enquanto divergência em imposto precisa de explicação caso a caso. Quando as duas provas fecham, a troca deixa de depender da confiança em quem programou.
É melhor reescrever tudo de uma vez ou migrar por partes?
Por partes, na grande maioria dos casos. Mesmo o projeto que ficou pronto em duas semanas deixou funções de fora e lista problemas conhecidos. Trocar o sistema legado inteiro em uma única virada concentra todo o risco em um fim de semana. Migrar por módulos, em contrapartida, permite manter a versão antiga como rede de proteção enquanto cada parte nova prova que funciona. O custo é conviver por alguns meses com duas versões, o que exige disciplina na passagem de dados entre elas.
Quem responde pelo código que ninguém da equipe leu?
A empresa que o colocou em produção. A IA não assina contrato, e o fornecedor do modelo não conhece o seu processo. Portanto, vale exigir três coisas de qualquer projeto. A primeira são testes que funcionem como contrato do que o programa deve fazer. A segunda é revisão humana nas partes que mexem com dinheiro, dados pessoais e segurança. A terceira é documentação entregue junto com o código, para que outra equipe consiga assumir a manutenção.
Se reescrever ficou barato, ainda faz sentido comprar um sistema pronto?
Depende do processo. Para o que é igual em toda empresa, como folha de pagamento e contabilidade, o pacote pronto continua vantajoso porque alguém mantém as regras atualizadas. Já para o processo que diferencia o negócio, o cálculo mudou. Construir sob medida passou a caber no orçamento de uma empresa média. Ainda assim, a conta precisa incluir quem vai manter o programa depois que ele estiver pronto, já que todo software novo vira um sistema legado um dia.
