O Melhor Retorno sobre o Investimento em IA Agora é Corrigir o Código Antigo, Não Escrever Código Novo

Cada demonstração de produto de IA que assisto começa do mesmo jeito: uma caixa de prompt vazia, um pedido em inglês simples e um aplicativo funcionando após alguns minutos. É um truque de festa genuinamente impressionante. Também é, eu diria, a coisa menos interessante que está acontecendo na IA empresarial no momento.

O trabalho mais consequente está acontecendo em um lugar muito menos glamoroso: dentro de bases de código de quinze anos que ninguém quer tocar, escritas por engenheiros que deixaram a empresa há uma década, executando lógica de negócios que ninguém entendeu completamente há anos. A maior parte da cobertura de IA obtém isso ao contrário. O código legado não é dívida técnica. É inteligência de negócios acumulada: décadas de decisões, codificadas como software, com as pessoas que tomaram essas decisões há muito tempo.

O desenvolvimento de campo verde obtém os slots de keynote. O código antigo obtém o dinheiro, relutantemente, e geralmente sem a compreensão necessária para gastá-lo bem.

A Real Escassez Não São Desenvolvedores, É Memória

Este não é um problema isolado. Um estudo da Pegasystems de 2025, realizado pela firma de pesquisa Savanta em mais de 500 tomadores de decisão de TI em todo o mundo, estima que a empresa média global desperdiça mais de 370 milhões de dólares por ano devido à sua incapacidade de modernizar eficientemente os sistemas legados, com quase 134 milhões de dólares disso relacionados a projetos de transformação lentos e intensivos em recursos.

Recentemente trabalhamos com uma empresa de distribuição de baterias que executava mais de quinze aplicações legadas, o tipo de dispersão que se acumula ao longo de vinte anos de fusões, integrações pontuais e engenheiros resolvendo o problema de hoje sem muito pensamento para o amanhã. Enterrado naquele código estavam regras de preços, limites de estoque e restrições de distribuição que representavam anos de decisões institucionais, escritas em lugar nenhum, exceto na lógica que ninguém havia totalmente mapeado.

É tentador chamar isso de um problema de talento: contratar mais desenvolvedores, migrar mais rápido. Mas você não pode contratar seu caminho para fora do fato de que a pessoa que entendia por que um módulo funcionava de uma certa maneira deixou a empresa em 2014. A maioria das empresas sofre de uma escassez de memória, não de uma escassez de talento. E até recentemente, não havia uma maneira real de resolver isso em escala. Você ou pagava a um punhado de engenheiros seniores para segurar o conhecimento institucional em suas cabeças indefinidamente, ou você o perdia no dia em que eles deixavam a empresa.

O Que a IA Realmente Muda

Nós não apontamos uma ferramenta de geração de código para a base de código antiga e dissemos para reescrever tudo; isso é mais ou menos como você apaga silenciosamente a lógica de negócios que você não sabia que existia. Em vez disso, usamos agentes de IA para fazer o trabalho de base não glamoroso primeiro: traçar como as quinze aplicações ou mais se conectam entre si, surfacear as decisões incorporadas na lógica que nunca foram escritas em outro lugar e segurar esse contexto como algo que a organização poderia consultar, e não algo que vive apenas na cabeça de um engenheiro. Isso coincide com o que outros fornecedores de IA estão documentando publicamente agora: a orientação da Anthropic sobre modernização de sistemas COBOL com Claude Code descreve a mesma sequência, automatizando as fases de exploração e análise primeiro, em vez de pular diretamente para a reescrita.

Os agentes não foram avaliados por quanto código geraram. Eles foram avaliados por quanto conhecimento institucional poderiam surfacear e preservar. Engenheiros então trabalharam ao lado deles na migração real e geração de testes, verificando a interpretação dos agentes da lógica de negócios contra como o sistema se comportava em produção, e não confiando nisso por fé. Um sinal útil que observamos: a explicação do agente de uma regra correspondia a um padrão que poderíamos verificar independentemente nos logs de produção, ou era um palpite plausível? A lacuna entre esses dois é exatamente onde os projetos de modernização de legado geralmente dão errado.

A estimativa original para o projeto era de oito meses e meio. Ele foi concluído em quatro, uma redução de 53%. Mas o resultado mais duradouro não foi o cronograma. O conhecimento institucional que costumava evaporar toda vez que um engenheiro deixava a empresa se tornou algo que a organização realmente poderia reter.

Os engenheiros de software passaram décadas escrevendo software. A próxima década pode ser gasta escavando-o, com a IA atuando menos como autor e mais como arqueólogo, reconstruindo cuidadosamente o raciocínio enterrado no código que sobreviveu às pessoas que o escreveram.

Um Quadro Grosso para Fazer Isso Sem Quebrar Coisas

Os projetos que dão certo parecem seguir mais ou menos a mesma sequência, seja o sistema um motor de preços ou um pipeline de reclamações:

Descobrir: mapear como os sistemas realmente se conectam, e não como o diagrama de arquitetura de 2016 diz que se conectam.

Entender: ter o agente surfacear a lógica de negócios e as suposições por trás dela, em linguagem simples que um especialista em domínio possa verificar.

Verificar: verificar essa interpretação contra o comportamento real de produção, e não apenas contra os comentários do próprio código.

Transformar: migrar ou reconstruir apenas uma vez que as três primeiras etapas sejam válidas, com humanos donos do sinal de aprovação.

Pular direto para Transformar, e você não está modernizando. Você está apostando com lógica que você ainda não entende.

Por Que Isso Importa Além das Equipes de Engenharia

A memória institucional não apenas se deteriora silenciosamente quando um engenheiro sênior se aposenta. Ela se torna uma responsabilidade aguda nos momentos exatos em que um negócio pode menos se dar ao luxo: durante uma aquisição, quando um novo proprietário precisa entender o que realmente comprou; durante uma migração de ERP, quando a lógica antiga precisa ser traduzida para um novo sistema corretamente pela primeira vez; durante uma auditoria de conformidade ou resposta a incidentes, quando alguém precisa explicar por que o sistema se comportou de uma certa maneira, sob prazo, para um regulador que não aceitará “a pessoa que o construiu deixou em 2014” como resposta.

Tratado dessa forma, a modernização de legado para de ser um item de linha de engenharia e começa a parecer uma questão de resiliência organizacional, o que significa que não é apenas os CTOs que devem se importar. É os CIOs que pesam o que acontece quando o pessoal técnico-chave se torna, as equipes de M&A que tentam precificar o que estão realmente adquirindo, e os conselhos que pensam sobre quanto do conhecimento operacional da empresa existe em lugar nenhum, exceto no código que ninguém lê atualmente.

A Reserva Que Importa

Nada disso funciona sem supervisão. A versão mais arriscada dessa abordagem é aquela em que a interpretação de um agente da lógica de negócios antiga é confiável sem verificação, porque os sistemas legados são exatamente o lugar onde uma suposição confiante, mas errada, da IA custa mais. A autonomia total no seu novo microserviço é uma aposta razoável. A autonomia total no motor de preços que ninguém tocou desde 2011 não é. O valor é que a IA torna possível se tornar, mais uma vez, os engenheiros que entendem o negócio, em um sistema que ninguém atualmente entende. Ela não os substitui.

Onde Eu Acho Que Isso Vai em Seguida

Por vinte anos, as empresas trataram o software legado como algo a escapar: um centro de custo para financiar relutantemente e modernizar o mais rápido possível. Eu acho que a IA está prestes a revelar que muito daquele código era, na verdade, um dos repositórios de conhecimento mais valiosos que o negócio já construiu. Ele apenas precisava de algo capaz de lê-lo. Pesquisadores já estão documentando o outro lado desse loop: uma revisão da literatura multivocal de 2026 sobre desenvolvimento assistido por LLM descobre que a busca atual por velocidade acelerada por IA está criando “dívida de integração rápida”, código enviado mais rápido do que pode ser entendido. A modernização de legado é apenas a conta final vindo devido, uma geração mais cedo.

Eu estaria curioso para saber se outros líderes de engenharia e tecnologia estão vendo a mesma mudança: o retorno sobre o investimento em IA está aparecendo mais no que você está construindo, ou no que você finalmente consegue entender e preservar? E para qualquer um que tenha tentado executar agentes de IA contra um sistema genuinamente antigo e não documentado, onde a compreensão do agente se manteve sob verificação, e onde ela silenciosamente se desfez?