Como adotar IA em sistemas legados com segurança

Uma alteração pequena em sistema legado pode parecer simples até tocar uma regra implícita, uma integração antiga ou uma exceção que a operação ainda usa. Antes de acionar a IA, a pergunta central é: qual comportamento crítico precisa permanecer igual enquanto a mudança é feita?

Em código legado, o risco costuma estar nas regras implícitas, nos efeitos colaterais e nas integrações antigas. Por isso, a IA deve entrar em alterações delimitadas, com teste observável e revisão humana proporcional ao risco.

O risco da IA no legado não é escrever código novo

Um sistema legado raramente é apenas um sistema antigo. Ele costuma ser um conjunto de decisões acumuladas, atalhos tolerados, regras de negócio que sobreviveram a várias gestões e integrações que ninguém quer tocar sem necessidade.

Quando uma equipe usa IA nesse ambiente, o problema não é só a possibilidade de a ferramenta sugerir código incorreto. Esse risco existe, mas é visível. O perigo mais difícil é outro: a IA pode produzir uma alteração aparentemente limpa, coerente e bem estruturada que muda um comportamento que a operação dependia que permanecesse igual.

Em sistemas novos, a equipe geralmente tem mais liberdade para redesenhar. Em sistemas legados, liberdade demais é parte do problema. Uma melhoria local pode alterar a ordem de execução de uma rotina, mudar a forma de tratar erro, modificar arredondamentos, remover uma exceção antiga ou afetar uma integração que nunca foi bem documentada.

A liderança técnica precisa tratar IA em sistemas legados como intervenção controlada, não como modernização aberta. A pergunta prática é: que pedaço do comportamento será alterado, que pedaço precisa sobreviver e como a equipe vai saber a diferença?

Esse cuidado não é uma defesa romântica do legado. É uma forma de reduzir ambiguidade antes de aumentar velocidade. Gerar código é fácil demais para ser o centro da decisão. Preservar comportamento crítico é o que separa uma alteração assistida de uma aposta.

Mapeie o comportamento que deve sobreviver à mudança

Antes de pedir ajuda à IA, a equipe precisa transformar conhecimento tácito em descrição operacional. Não precisa escrever uma documentação perfeita do sistema inteiro. Precisa nomear o comportamento que não pode mudar naquela tarefa.

Um bom recorte descreve, no mínimo:

quais entradas disparam o fluxo afetado;
quais saídas precisam permanecer compatíveis;
quais exceções conhecidas fazem parte do comportamento atual;
quais efeitos colaterais são esperados, como gravação, envio, bloqueio ou notificação;
quais integrações dependem desse comportamento;
quais casos não devem ser modernizados junto com a alteração.

Essa descrição funciona como uma pequena fronteira de comportamento para a tarefa. Não é burocracia. É o material que impede a IA, o revisor e o próprio desenvolvedor de confundirem correção com redesenho.

Imagine um sistema legado de faturamento interno em uma empresa fictícia. A equipe precisa alterar o cálculo de desconto para uma categoria de pedido corporativo. O pedido ruim para a IA seria: “refatore o módulo de descontos e corrija o cálculo”. Esse comando abre espaço para reorganizar lógica, mudar nomes, limpar condicionais e tocar regras vizinhas.

Um pedido melhor começa menor: “alterar apenas a regra de desconto para pedidos corporativos acima de determinado valor, preservando arredondamento, impostos, mensagens de erro e integração com emissão de nota”. O exemplo é fictício, mas o critério é concreto. Se a equipe não consegue dizer o que deve permanecer igual, a tarefa ainda não está pronta para ser assistida por IA.

O legado cobra caro quando a mudança certa acontece no lugar errado.

Escolha uma alteração pequena, independente e testável

A adoção de IA em sistemas legados deve favorecer mudanças pequenas, independentes e testáveis. O DORA recomenda trabalhar em unidades pequenas para obter retorno mais cedo e revisar hipóteses antes. A mesma orientação alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA.

Esse ponto é especialmente relevante no legado. Uma mudança grande pode parecer produtiva porque concentra várias melhorias em uma única entrega. Na prática, ela aumenta a área de incerteza. Quando algo quebra, a equipe não sabe se a causa está na correção, na refatoração, na limpeza, na troca de dependência ou na reorganização do fluxo.

Uma alteração delimitada tem fronteira clara. Ela diz onde a IA pode mexer e onde não deve mexer. Pode envolver um arquivo, uma função, um método, uma regra ou um fluxo específico. O tamanho exato depende do sistema, mas o critério de revisão é simples: se a equipe não consegue revisar a alteração em uma leitura focada e testar o comportamento preservado, o escopo está grande demais.

Há sinais de que a tarefa virou refatoração ampla disfarçada:

o pedido mistura correção, melhoria estética e modernização;
a IA precisa inferir regra de negócio a partir de código obscuro;
a alteração toca áreas que não participam diretamente do comportamento descrito;
a justificativa para mudar arquivos vizinhos é apenas “aproveitar que estamos aqui”;
a revisão depende de confiança geral na ferramenta, não de evidência específica.

Isso não significa que refatoração seja proibida. Significa que ela deve ser outra decisão, com outro escopo e outro nível de evidência. No legado, cada intervenção precisa deixar claro onde começa, onde termina e que comportamento deve preservar.

Dê contexto suficiente à IA, mas não entregue o sistema inteiro

A qualidade da resposta da IA depende do contexto selecionado, dentro dos limites da janela disponível. A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico dentro de uma janela limitada.

No sistema legado, isso deve ser traduzido de forma prática: forneça o contexto que reduz ambiguidade sem convidar a IA a redesenhar áreas vizinhas.

Um bom contexto para a IA inclui:

trecho de código diretamente afetado;
regra de negócio que será alterada;
comportamento que deve permanecer igual;
exemplos de entrada e saída;
restrições de compatibilidade;
padrões locais que devem ser preservados;
definição clara do que não faz parte da tarefa.

O contexto ruim é amplo e vago: “analise este módulo e melhore possíveis problemas”. Em sistema legado, esse tipo de pedido costuma transformar uma mudança de comportamento em uma caça a oportunidades. A IA pode sugerir uma estrutura mais elegante, mas elegância não é critério suficiente quando a operação depende de compatibilidade.

Também é útil diferenciar contexto de autoridade. Dar mais arquivos à IA não significa delegar a decisão. A ferramenta pode ajudar a localizar dependências, propor alteração mínima, explicar trechos obscuros e sugerir testes. A autorização para mudar continua sendo humana, especialmente quando há impacto em operação, atendimento, dados ou integrações.

Antes de ampliar o uso de IA, a organização precisa entender seu ponto de partida, seus riscos e sua capacidade de revisar mudanças. No legado, a pergunta fica mais estreita: temos contexto suficiente para esta alteração específica?

Use testes como cerca, não como formalidade final

Testes automatizados não garantem que todo comportamento crítico foi preservado. Mas, quando bem escolhidos, funcionam como cerca. Eles delimitam o que não deve sair do lugar enquanto a equipe altera uma parte do sistema.

Em sistemas legados, nem sempre há uma suíte de testes confiável. Isso não deve levar a duas respostas extremas: bloquear qualquer uso de IA ou aceitar qualquer sugestão porque “não havia testes mesmo”. Entre esses extremos, a equipe pode criar testes que registrem o comportamento atual de trechos sensíveis, mesmo quando esse comportamento não é ideal.

Esse tipo de teste não afirma que a regra é bonita ou correta em termos absolutos. Ele apenas torna observável aquilo que a operação já espera.

No exemplo fictício do cálculo de desconto, a equipe poderia registrar casos de pedidos corporativos com combinações conhecidas de valor, categoria, arredondamento, imposto e mensagem de erro. A hipótese a medir não é “a IA melhorou o módulo”. A hipótese é mais precisa: “a nova regra foi aplicada sem alterar os casos preservados”.

A integração contínua também ajuda quando existe. O DORA descreve integração contínua como integração frequente ao código principal, acompanhada de construção e testes automatizados. A mesma fonte afirma que corrigir uma construção quebrada deve ter prioridade sobre novas mudanças.

Aplicado ao legado, o ponto é direto: se a mudança assistida por IA quebra a construção ou invalida um teste de comportamento preservado, a equipe não deve empilhar novos prompts por tentativa. Deve parar, entender a causa e decidir se o escopo precisa diminuir.

Teste não é cerimônia de encerramento. É parte da fronteira que torna a alteração aceitável.

Revise a saída da IA pelo que ela preservou, não só pelo que resolveu

A revisão humana em sistemas legados não pode olhar apenas se a nova regra foi implementada. Precisa olhar o que a IA preservou.

A documentação do GitHub sobre uso responsável de agentes com Copilot descreve recursos com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas. Esse princípio vale mesmo quando a equipe não usa um agente autônomo. Quanto maior a capacidade da ferramenta de alterar código, maior precisa ser a clareza sobre quem revisa, o que revisa e com qual critério.

Em uma revisão de legado assistida por IA, o revisor deve procurar efeitos colaterais específicos:

mudança em assinatura de função ou método;
alteração de ordem de execução;
mudança em tratamento de erro;
modificação de persistência;
alteração em permissões ou validações;
mudança silenciosa em integração externa;
remoção de exceções aparentemente estranhas, mas usadas pela operação;
padronização de código que muda compatibilidade.

O revisor também deve comparar a saída com a fronteira autorizada. Se a IA tocou áreas não previstas, isso não deve ser aceito apenas porque o código ficou mais limpo. A pergunta é: essa mudança adicional era necessária para preservar o comportamento e implementar o ajuste? Se a resposta for incerta, a alteração deve voltar para recorte.

Aqui há uma armadilha comum. Testes passando podem reduzir ansiedade, mas não eliminam julgamento. Se os testes cobrem só o caso feliz, uma mudança em exceção, integração ou mensagem pode escapar. Por isso, a revisão precisa combinar evidência automatizada com leitura orientada por risco.

Uma liderança pode ter um plano amplo de adoção de IA, mas cada mudança no legado deve responder a uma pergunta menor: esta alteração específica tem revisor capaz de avaliar o comportamento preservado?

Sem esse revisor, a IA apenas antecipa uma decisão que ninguém assumiu.

Critérios mínimos para autorizar IA em um sistema legado

Antes de liberar uma alteração assistida por IA em código legado, a equipe pode usar critérios mínimos. Eles não substituem arquitetura, teste ou revisão. Ajudam a decidir se a tarefa está madura o suficiente para receber assistência.

Comportamento crítico nomeado

A equipe consegue dizer qual comportamento não pode mudar?

Passa quando há descrição objetiva de entrada, saída, regra, exceção ou efeito esperado. Falha quando a justificativa é apenas “isso sempre funcionou assim” ou “o usuário perceberia se quebrasse”.

Fronteira da alteração explícita

A tarefa diz onde a IA pode mexer e onde não deve mexer?

Passa quando arquivos, funções, módulos ou fluxos afetados estão delimitados. Falha quando o pedido mistura correção, refatoração, melhoria estética e modernização.

Evidência antes da mudança

Existe alguma forma de observar o comportamento atual?

Passa quando há teste existente, teste que registra comportamento atual, exemplo reproduzível, log confiável ou comparação manual documentada. Falha quando a equipe só saberá se quebrou depois que alguém reclamar.

Contexto selecionado para a IA

O pedido inclui a informação necessária sem abrir espaço para redesenho indevido?

Passa quando a IA recebe regra, restrições, trecho relevante, padrão local e definição de pronto. Falha quando o pedido é genérico, como “melhore este módulo” ou “corrija possíveis problemas”.

Revisão humana proporcional ao risco

Quem revisa entende o comportamento preservado e o ponto alterado?

Passa quando a revisão verifica solução, efeitos colaterais e compatibilidade com o fluxo existente. Falha quando a revisão olha apenas estilo de código ou aceita a saída porque os testes passaram.

Plano de interrupção

A equipe sabe quando parar a alteração assistida por IA?

Passa quando há gatilhos para reduzir escopo, investigar manualmente ou dividir a tarefa. Falha quando a IA continua recebendo prompts até produzir algo que pareça plausível.

Critério de parada: quando não usar IA nessa alteração

Há situações em que a melhor decisão técnica é não usar IA naquele momento.

A equipe deve parar ou reduzir escopo quando:

o comportamento crítico não pode ser descrito;
não há forma razoável de observar o comportamento atual;
a regra de negócio depende de conhecimento que ninguém consegue validar;
a alteração exige mexer em muitos fluxos sem fronteira clara;
há forte dependência de efeitos colaterais não documentados;
não existe revisor capaz de avaliar a mudança;
a pressão do prazo está misturando correção, modernização e limpeza no mesmo lote.

Nesses casos, o próximo passo não é insistir em prompts melhores. É investigar, criar evidência mínima, dividir a tarefa ou adiar o uso da IA até que a fronteira exista.

O critério de autorização é desconfortável, mas direto: use IA em sistemas legados apenas quando a alteração tiver comportamento preservado, fronteira explícita, evidência antes e depois, contexto selecionado e revisão humana capaz. Se qualquer uma dessas peças faltar, reduza o escopo antes de ampliar o uso.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.