Sistema legado com IA: o que é e como modernizar

Quinto dia útil do mês. O contador pediu o relatório de faturamento por cliente, e o sistema da empresa não tira esse relatório. A pessoa do financeiro exporta tudo para uma planilha, junta com outra exportação e acerta à mão. Leva a manhã inteira.

O sistema foi feito sob medida por um programador que hoje ninguém consegue achar. Ele funciona, e é justamente por isso que ninguém mexe: a tela de faturamento faz alguma conta por trás que ninguém sabe explicar, e o medo é quebrar o que ainda dá certo. O nome que o fornecedor ou o time de TI dá para isso é sistema legado.

O que é sistema legado

Sistema legado é o sistema antigo que a empresa continua usando todo dia porque a operação depende dele: é lá que estão os dados dos clientes, os pedidos e as regras do negócio. Ele é difícil de mudar, de integrar e de manter, e trocar parece arriscado. Modernizar com inteligência artificial quer dizer usar a IA para ler esse sistema por dentro e trocá-lo aos poucos, sem parar a operação.

"Antigo" aqui tem pouco a ver com a idade. Michael Feathers, no livro Working Effectively with Legacy Code, de 2004, chama de código legado o código sem testes, aquele em que ninguém consegue mudar uma linha e ter certeza do que acontece. Por essa régua, um sistema de três anos pode ser legado.

Em empresa pequena e média, os exemplos de sistemas legados costumam ser estes:

• O sistema sob medida de um programador que saiu, sem documentação, com o código num computador que ninguém sabe onde está.
• O ERP antigo instalado no servidor do escritório, numa versão que o fornecedor não atualiza mais.
• A planilha que virou sistema, cheia de macros, abas e fórmulas que só uma pessoa entende.
• O banco em Access ou o programa em Delphi, que roda num computador só e não conversa com mais nada.

Em empresa grande, o exemplo clássico é o sistema em COBOL que ainda processa as transações do banco. O problema é o mesmo em escala diferente.

Quando o sistema legado começa a custar caro

O sistema legado quase nunca para de funcionar de um dia para o outro. Ele vai cobrando aos poucos, em coisas que não aparecem numa conta só:

• O relatório que o sistema não tira, montado na planilha toda semana.
• A informação digitada duas vezes, porque o sistema não fala com o banco, com a nota fiscal ou com o WhatsApp.
• A mudança que ninguém faz, porque a última vez que alguém mexeu o faturamento saiu errado por um mês.
• A pessoa que não pode tirar férias, porque só ela sabe contornar o erro da tela de pedidos.

Esse jeito de trabalhar em volta do sistema é o processo legado, e costuma custar mais que o sistema em si. Se você quer enxergar onde ele está, o mapeamento de processos mostra o caminho de cada tarefa e onde ela sai do sistema e cai na mão de alguém.

Tem um ponto que pesa a favor do sistema velho: ele é a única documentação que existe da regra do negócio. Quando o desconto do cliente antigo é calculado de um jeito diferente, essa regra está escrita no código, e em nenhum outro lugar.

Modernizar, integrar ou reescrever o sistema legado

A modernização de sistemas legados costuma seguir um destes caminhos, e cada um compra uma coisa diferente:

• Integrar sem trocar: o sistema velho continua igual e ganha uma ponte para conversar com o resto (o banco, a loja, o WhatsApp). Resolve a digitação dupla e deixa a regra antiga onde está.
• Trocar por um sistema pronto: quando o que o sistema faz é comum (financeiro, estoque, nota fiscal), um software de mercado pode cobrir. A regra da casa precisa caber nele.
• Reescrever tudo de uma vez: construir o sistema novo do zero, ao lado, e virar a chave num dia marcado.
• Trocar por partes: um módulo novo por vez, com o sistema velho rodando até o novo dar conta.

Reescrever tudo parece o caminho mais limpo, e é o que mais atrasa. Em 2000, Joel Spolsky contou o caso da Netscape, que decidiu reescrever o navegador do zero. Quando ele escreveu o texto, a última versão grande tinha saído quase três anos antes, e a versão 5.0 nunca existiu. O argumento dele vale para qualquer empresa: quando você joga o código fora, joga junto todo o conhecimento que estava nele.

A troca por partes tem nome e desenho. Martin Fowler descreve o padrão strangler fig num texto revisto em 2024: a figueira estranguladora nasce num galho de outra árvore, cresce em volta dela até criar raiz própria e, no fim, se sustenta sozinha. No sistema, cada módulo novo assume uma parte do trabalho do velho. Fowler escreve que, como cada pedaço é pequeno, o risco de colocar o software novo em uso é menor, e o valor chega antes.

Trocar por partes custa mais integração no meio do caminho, porque o novo e o velho precisam conversar enquanto convivem. Em troca, a equipe começa a usar o primeiro módulo novo cedo, sem esperar o fim de um projeto inteiro.

Como modernizar um sistema legado com IA

A parte mais lenta de modernizar sempre foi entender o que o sistema velho faz, e é aqui que a IA mais ajuda. Um agente de código como o Claude Code ou o Codex lê o repositório inteiro e explica em português o que acontece quando um pedido é cancelado, onde o desconto é calculado e quais tabelas cada tela altera.

Na prática, a IA entra assim:

• Ler o código e escrever a regra em português. Peça uma explicação por tela ou por rotina, nunca do sistema inteiro de uma vez. A saída é um documento da empresa, com as regras do negócio que estavam só no código.
• Montar os casos de teste com dado real. Pegue as notas, os pedidos e os fechamentos do mês passado e peça que a IA liste o que o sistema velho devolveu para cada um. Esses pares de entrada e saída viram a régua do sistema novo.
• Escrever o módulo novo a partir da regra escrita. Com a regra no papel e os casos de teste prontos, a IA acelera a construção, porque sabe o que precisa dar certo.

Se o código ficou com o programador que saiu, ainda dá para começar. Telas, relatórios exportados e o próprio banco de dados contam bastante da regra, e o ChatGPT, o Claude ou o Gemini leem esse material. Para recuperar o código, o texto sobre contratar programador explica de quem ele é pela lei.

A resposta da IA sobre um código que ninguém documentou é uma hipótese. Ela lê o que está escrito e às vezes erra o motivo. Por isso a regra escrita passa por alguém da operação antes de virar sistema novo.

Quem confere a troca continua sendo decisão sua

A IA lê, sugere e escreve o código. As decisões ficam com a empresa:

• Qual regra fica. Quando a IA encontra um cálculo estranho no código, alguém da operação diz se é regra do negócio ou erro antigo que todo mundo contornava. Esse julgamento não sai do código.
• Se a saída bate. Antes de desligar a parte velha, a mesma entrada passa pelos dois sistemas, e uma pessoa que conhece o trabalho compara o resultado: o mesmo valor, o mesmo cliente, o mesmo prazo. Diferença encontrada vira decisão, nunca ajuste silencioso.
• Quando desligar. O módulo velho sai do ar quando quem usa diz que o novo dá conta do mês inteiro, inclusive do fechamento.

Também é decisão sua se vale modernizar. Às vezes reescrever é a escolha certa, quando o sistema é pequeno, a regra é simples e a tecnologia não tem mais conserto. E às vezes o melhor é só integrar e deixar o velho quieto mais uns anos. A IA ajuda a enxergar o sistema, e a escolha do que trocar continua com quem toca a operação.

Por onde começar: o primeiro módulo

No método que eu uso, o protocolo antivibe, o primeiro passo é mapear o terreno: olhar como o sistema é usado hoje, por quem e onde o trabalho sai dele e vai para a planilha. Só depois escolho o primeiro módulo. Ele costuma ser a parte que mais dói e menos depende do resto, como o relatório que ninguém consegue tirar ou o cadastro que é digitado duas vezes.

Para começar a modernização na empresa, precisa estar pronto:

• Acesso ao sistema velho, de preferência ao código e ao banco de dados; sem o código, as telas e as exportações.
• Uma pessoa da operação que conhece a regra, com algumas horas por semana para conferir o que a IA escreveu.
• Exemplos reais de um mês, com o resultado que o sistema velho deu, para comparar.
• Quem decide quando desligar cada parte velha.

O primeiro módulo segue a lógica do produto mínimo viável: a menor versão que alguém da operação usa de verdade, enquanto o resto continua no sistema antigo. Quanto custa cada etapa depende do tamanho do módulo, e o texto sobre quanto custa criar um aplicativo mostra o que pesa no preço. Se a dúvida é quem contratar, comparei os modelos no texto sobre o que é software house.

No Colaboratório, eu monto essa troca por partes para empresas que dependem de um sistema que ninguém quer mexer. Reescrever tudo de uma vez é o projeto que mais atrasa. Dá para trocar por partes: o sistema velho continua rodando enquanto o primeiro módulo novo entra em uso, e cada sprint troca mais um pedaço. A IA ajuda a ler o código e a regra que ninguém documentou. É esse trabalho, sprint a sprint, que eu faço.

Se o relatório do quinto dia útil ainda sai da planilha, escrevi uma página sobre como eu começo um projeto de software sob medida, separando o que precisa ser construído do que dá para usar pronto. Se quiser olhar o seu sistema legado antes de decidir o que trocar, entre em contato.