# Modernizando software legado com IA: entender, mudar, verificar - Author: FMKTech Team - Published: 2025-11-09 - Reading time: 5 min - Tags: Software Legado, Engenharia de Contexto, Programação com IA - URL: https://www.fmktech.com.br/pt-BR/blog/ai-coding-brownfield-projects.md (HTML: https://www.fmktech.com.br/pt-BR/blog/ai-coding-brownfield-projects) Um roteiro para evoluir sistemas existentes: mapear regras de negócio, fornecer contexto útil aos agentes e substituir uma parte de cada vez sem perder o controle. --- *Revisado em 4 de setembro de 2026. Este guia reúne nossos artigos sobre desenvolvimento em sistemas existentes e engenharia de contexto.* Substituir software legado caro não é, principalmente, um problema de gerar código. O trabalho difícil é descobrir de quais comportamentos a operação depende, decidir o que deve mudar e transferir usuários e dados sem quebrar esses comportamentos. Agentes de programação podem ajudar na investigação e na implementação. Ainda precisam de evidências sobre o sistema atual e de uma definição clara de sucesso. Uma interface nova e bonita não basta se a exportação de fechamento do mês deixar de bater. ## Comece pelo que trava a operação Não comece com “reescrever o aplicativo”. Escolha um atrito concreto: uma tela de despacho que não acompanha a distribuição de rotas, aprovações feitas por fora do sistema ou relatórios montados copiando dados entre ferramentas. Registre o que deve melhorar e o que precisa continuar verdadeiro. Por exemplo: > Substituir a planilha de distribuição manual por uma tela de despacho. Preservar os identificadores dos pedidos, impedir atribuições duplicadas e manter a exportação atual funcionando durante a implantação. É um exemplo de escopo, não um caso de cliente. Seu valor é permitir que alguém da operação e alguém da engenharia reconheçam se a entrega cumpriu o combinado. Às vezes, a resposta é uma integração pequena. Às vezes, um módulo sob medida ao lado do sistema antigo. A substituição completa deve decorrer das restrições, não apenas da frustração com a interface atual. ## Investigue o caminho que a mudança realmente afeta Peça ao agente para acompanhar um caso real pelo sistema antes de propor alterações. Por onde entra a solicitação? Quem valida? Onde o estado é gravado? Quem o consulta depois? A investigação deve produzir: - Pontos de entrada, arquivos relevantes e a revisão analisada. - Regras de negócio encontradas no código, nos testes e nas explicações da operação. - Consumidores, como tarefas agendadas, relatórios e integrações externas. - Dúvidas conhecidas, separadas do comportamento confirmado. - Comandos que reproduzem o comportamento atual e executam suas verificações. Evidência do repositório e conhecimento da operação se complementam. O código mostra o que acontece hoje; sozinho, não revela quais comportamentos acidentais o negócio quer preservar. ## Engenharia de contexto é um briefing útil, não um despejo do repositório Forneça ao agente de implementação o menor conjunto útil de fatos verificados: objetivo, restrições, referências de arquivos, formatos de interfaces e exemplos de aceitação. Deixe que ele consulte código adicional quando necessário. Em trabalhos longos, preserve decisões e dúvidas em uma passagem de contexto concisa. Retire logs repetidos e caminhos abandonados, mas mantenha os motivos das restrições importantes. A Anthropic descreve consulta sob demanda, compactação e notas estruturadas como técnicas de gestão de contexto; também alerta que uma compressão agressiva pode perder informações importantes. Não existe uma porcentagem universal de ocupação da janela a partir da qual todo modelo deixa de raciocinar bem. [Leia a discussão sobre engenharia de contexto](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). Para o exemplo de despacho, uma passagem de contexto útil poderia dizer: ```text Objetivo: atribuir um pedido sem usar a planilha. Preservar: IDs dos pedidos e formato atual da exportação. Evidência: arquivos relevantes, nomes de testes e commit analisado. Dúvida: é permitido reatribuir depois da exportação? Aceitação: dois operadores não podem atribuir o mesmo pedido em duplicidade. Parar: consultar o responsável antes de mudar a regra de reatribuição. ``` Repare na dúvida. Um bom briefing não disfarça informação ausente como decisão de projeto. ## Faça uma mudança pequena e observável Escolha uma fatia que inclua o comportamento, não só uma camada de código. No despacho, isso pode significar selecionar um pedido elegível, atribuí-lo, persistir o resultado e mostrar a confirmação ao operador. Registre o comportamento atual em um teste de regressão onde a compatibilidade precisa ser mantida. Acrescente um teste de aceitação separado para a mudança desejada. Revise essas expectativas com quem responde pelo processo; reproduzir um defeito antigo em um teste não o transforma em requisito. Se houver agentes em paralelo, defina responsáveis pelos arquivos e interfaces compartilhadas. Arquivos separados reduzem conflitos de edição, mas não evitam divergências de interpretação. Reserve uma etapa de integração que exercite o caminho completo. ## Trate a migração como trabalho próprio Uma substituição costuma exigir um período de convivência. Defina qual sistema é a fonte oficial de cada registro e como as alterações passam de um para o outro. Antes de mover usuários ou dados reais, responda: 1. Como preservar os identificadores e os relacionamentos existentes? 2. Como apontar registros ausentes, duplicados ou incompatíveis? 3. Qual comparação demonstrará que a migração foi concluída? 4. Uma execução parcial pode ser repetida sem duplicar trabalho? 5. Se houver retorno ao sistema anterior, o que acontece com os registros criados no novo? “Restaurar o backup” não é um plano completo de retorno se isso descartar trabalho realizado depois da troca. Teste a recuperação com dados representativos antes de depender dela. ## Verifique mais do que a compilação Execute as verificações reais do repositório e o processo alterado. Inclua limites de permissão, envios duplicados, falhas de dependências e os relatórios ou tarefas afetados pela mudança. Depois, peça a alguém da operação para concluir a tarefa. A pessoa consegue identificar o estado atual? Corrigir um erro? Tratar uma exceção? Correção técnica e utilidade operacional exigem verificações diferentes. Compare o resultado com a situação anterior: tempo total, correções, falhas de repasse, esforço de suporte e custo de operação. Mais código gerado não é um resultado de negócio. A vantagem competitiva vem de um sistema que apoia sua forma de trabalhar e consegue evoluir com ela. A IA pode ajudar a construí-lo; não elimina a responsabilidade de entendê-lo. [Converse conosco sobre o processo legado que está travando sua operação](/pt-BR#contact). --- ## Onde procurar depois - [Índice do blog](https://www.fmktech.com.br/pt-BR/blog.md) - [Homepage](https://www.fmktech.com.br/pt-BR.md) - [llms.txt](https://www.fmktech.com.br/llms.txt)