Modernização com IA: equivalência vale mais que menos linhas de código

A Akka avaliou portabilidade de software com IA em 65 projetos open source; a primeira rodada levou 99,3 horas e consumiu 9,41 bilhões de tokens.[8] A empresa relatou melhoria em tamanho de código ou desempenho em 57 casos, mas essa rodada implementou até 10% da superfície de cada projeto; somente dez projetos foram selecionados depois para implementação completa.[8] O denominador muda a leitura: explorar partes de muitos sistemas não é concluir a substituição integral deles.

O que muda para quem desenvolve

O fluxo passou por descoberta, especificação, portabilidade, benchmark e melhoria, com análise de código, schemas e comportamento em execução.[8] Especificações verificáveis e comportamento tipado ajudaram nas primeiras implementações, mas permaneceram lacunas de contexto em decisões que atravessam componentes.[8]

Minha leitura é usar a especificação como um contrato testável, não como um texto que o agente produz e depois declara atendido. Para uma modernização, proponho explicitar entradas, saídas, erros, efeitos persistentes e regras que precisam sobreviver à troca de implementação. O número de linhas removidas deveria ser consequência, não critério principal de aceite.

O estudo também mostra um trade-off de execução: Sonnet levou em média 61 minutos por portabilidade, contra 120 minutos do Opus, enquanto Opus consumiu cerca de 40% menos tokens.[8] Níveis maiores de esforço aumentaram consumo sem melhorar eficiência de forma consistente.[8] Tempo, tokens e custo de validação precisam ser medidos separadamente.

Como aplicar

Escolha um componente com fronteiras claras, como uma transformação de dados ou uma regra de cálculo de domínio. Documente exemplos reais autorizados e casos de borda antes de gerar a nova implementação. Registre também o que fica expressamente fora do piloto.

Execute a implementação antiga e a candidata sobre as mesmas entradas. Compare resultados, erros e efeitos, incluindo repetição da mesma operação quando a idempotência for exigida. Reutilize testes existentes, mas acrescente casos que explorem falhas de serialização, limites de entrada e comportamento entre componentes.

Para desempenho, fixe a carga, o ambiente e o procedimento de medição. Separe inicialização de execução sustentada e mantenha um caminho de retorno para a versão anterior. Registre tempo humano de revisão, correções e investigação, além do consumo do modelo. Uma portabilidade barata de gerar pode ser cara de validar.

No estudo, a validação incluiu auditorias de serialização, segurança, tratamento de erros, dados pessoais, idempotência e fronteiras arquiteturais; novas falhas exigiram barreiras adicionais e elevaram o custo.[8] Use esse conjunto como inspiração para seus critérios, não como evidência de que outro projeto passou pelas mesmas verificações.

Cuidados e limites

A aceleração de 143.333 vezes reportada para Dify comparava cargas diferentes, enquanto Netflix Metaflow ficou aproximadamente cem vezes mais lento.[8] Esses extremos não sustentam uma regra geral sobre ganhos de modernização.

As hipóteses de que modelos menores seguem melhor as restrições ou de que menos código decorre de diferenças de linguagem e eliminação de código morto não foram resolvidas pelo estudo.[8] O aceite deveria depender de comportamento preservado na mesma carga e de limites explicitados. Menos código com semântica diferente não é simplificação; é outro sistema.

Fonte

[8] Fonte: InfoQ