ADR: AWS Transform e Agentes de IA vs Fábrica Tradicional de Modernização

Programas de modernização de larga escala falham com frequência previsível por razões bem documentadas: escopo que cresce silenciosamente, regressões descobertas tarde demais, perda de conhecimento tácito dos sistemas originais e fadiga de equipe em projetos de múltiplos anos. A fábrica tradicional, times de engenharia dedicados reescrevendo ou refatorando código manualmente, oferece controle granular e ownership claro, mas escala mal: o custo cresce linearmente com o volume de código, e a qualidade é fortemente dependente da senioridade e consistência dos times.

AWS Transform representa uma aposta diferente. O serviço orquestra agentes de IA especializados por domínio: um agente para upgrade de .NET Framework para .NET 8, outro para análise e conversão de COBOL, outro para planejamento de migração de VMs VMware para EC2, e um agente de propósito geral para código customizado. Cada agente opera em um pipeline que inclui análise estática, geração de código transformado, geração de testes e produção de relatórios de mudança rastreáveis. O modelo não elimina o engenheiro, ele desloca o trabalho de escrever transformações para revisar e validar transformações.

A força central que torna essa decisão não trivial é a assimetria de risco. Em sistemas financeiros ou industriais críticos, uma regressão não detectada em código transformado por IA pode ter consequências que superam em muito qualquer economia de custo. O time de arquitetura precisa responder honestamente: o agente de IA produz código que passa nos testes existentes ou código que é genuinamente correto? Essas são perguntas diferentes, e a resposta depende diretamente da qualidade da cobertura de testes do portfólio legado, que, na maioria dos casos reais, é baixa.

Um aspecto frequentemente subestimado em discussões sobre modernização assistida por IA é o que chamo de problema de ownership difuso. Quando um engenheiro sênior reescreve um módulo COBOL em Java ou C#, ele carrega a responsabilidade intelectual daquele código. Ele entende as decisões, pode explicá-las em uma revisão de segurança e pode ser responsabilizado. Quando um agente de IA gera o equivalente, quem é o owner? O time que executou o Transform? O arquiteto que aprovou o relatório? A AWS?

Essa pergunta não é filosófica, ela tem consequências práticas em auditoria SOX, em revisões de penetração e em incidentes de produção. Um programa de modernização responsável precisa definir explicitamente que o código gerado por IA é de propriedade e responsabilidade do time de engenharia que o revisou e aprovou. Isso exige que o processo de revisão seja genuíno, não um rubber-stamp de relatórios de 500 páginas gerados automaticamente.

AWS Transform produz relatórios de transformação detalhados e diffs de código rastreáveis. Isso é um ativo real de governança: cada mudança tem proveniência, cada decisão de transformação é documentada. O desafio operacional é construir um processo de revisão que seja proporcional ao risco de cada módulo transformado. Módulos de cálculo financeiro precisam de revisão humana profunda; utilitários de logging podem ser aprovados com revisão superficial e testes automatizados. Essa triagem de risco é trabalho de arquitetura, não de IA.

AWS Transform opera analisando código-fonte. Em sistemas financeiros e industriais, esse código frequentemente contém, ou referencia, segredos, strings de conexão hardcoded, lógica de negócio proprietária e, em casos patológicos, dados de produção embutidos em scripts de teste. Antes de executar qualquer agente de modernização, o programa precisa de uma fase de sanitização de código que identifique e remova ou substitua esses elementos.

O modelo de segurança do AWS Transform usa isolamento por conta e por execução, o código do cliente não é usado para treinar modelos, e o processamento ocorre dentro do perímetro AWS do cliente. Isso é materialmente diferente de enviar código para uma API pública de LLM sem controles. Ainda assim, a equipe de segurança precisa revisar: quais dados são transmitidos durante a análise? Quais permissões IAM são necessárias? O Transform precisa de acesso a repositórios de código, esse acesso deve ser temporário, com escopo mínimo e auditado via CloudTrail.

Um padrão que recomendo é executar o Transform em uma conta AWS isolada (uma 'sandbox de modernização') com conectividade controlada ao repositório de código, sem acesso a ambientes de produção. Os artefatos gerados, código transformado, relatórios, planos de migração, são exportados para revisão em um pipeline CI/CD separado antes de qualquer merge. Esse isolamento não é paranoia: é o mesmo princípio de least privilege que aplicamos a qualquer pipeline de CI/CD que toca código de produção.