Resumo Técnico: SCARFBENCH

Declaração do Problema

O Java Empresarial permanece uma força dominante na infraestrutura de software, com muitas aplicações sobrevivendo além de suas suposições arquitetônicas originais. Embora a modernização seja frequentemente impulsionada por pressões de descontinuação e objetivos não funcionais, como redução de sobrecarga de memória e melhoria da elasticidade na nuvem, migrar essas aplicações entre frameworks (especificamente entre Spring, Jakarta EE e Quarkus) é uma empreitada complexa e propensa a riscos.

As atuais benchmarks de engenharia de software avaliam principalmente a correção de bugs, implementação de funcionalidades ou atualizações de versão de linguagem dentro de uma pilha de frameworks fixa. Elas falham amplamente em medir o refatoramento de aplicações entre frameworks, uma tarefa que exige mais do que a substituição local de APIs. Uma migração bem-sucedida demanda mudanças coordenadas em configurações de build, injeção de dependência, persistência, tratamento de requisições e implantação para preservar o comportamento da aplicação. As benchmarks existentes frequentemente assumem que preservar o modelo de programação subjacente é suficiente, uma suposição que não se sustenta ao migrar entre frameworks com modelos de execução e idiossincrasias divergentes.

Metodologia: SCARFBENCH

Os autores introduzem o SCARFBENCH (Benchmark de Refatoramento de Aplicação Autocontido), um benchmark projetado para avaliar a capacidade de agentes de Modelos de Linguagem (LLM) realizarem migrações entre frameworks que preservam o comportamento.

Construção do Benchmark

• Escopo: O benchmark compreende 34 famílias de aplicações implementadas em três frameworks: Spring Boot, Jakarta EE e Quarkus.
• Estrutura: Divide-se em dois níveis:
  1. Nível Focado: 29 aplicações autocontidas que isolam camadas arquitetônicas específicas (Injeção de Dependência, Persistência, Apresentação, Infraestrutura, Domínio de Negócio) ancoradas em Solicitações de Especificação Java (JSRs).
  2. Nível de Aplicação Completa: 5 sistemas de código aberto maiores e realistas que combinam essas camadas, testando o acoplamento entre camadas e fluxos de trabalho ponta a ponta.
• Variantes: Essas aplicações geram 102 variantes específicas de framework (aproximadamente 151 mil linhas de código Java pareado em 1.946 arquivos de origem e teste).
• Tarefas: O benchmark define 204 tarefas de migração direcionadas (por exemplo, Spring $\to$ Jakarta, Jakarta $\to$ Quarkus). Cada tarefa exige que um agente sintetize uma implementação de destino que preserve o comportamento da origem.
• Verdade Terrena: Desenvolvedores Java especialistas implementaram manualmente as três variantes de framework para cada família de aplicações, garantindo que existam implementações behavioralmente equivalentes para validação.

Protocolo de Avaliação

• Agentes: Cinco agentes de codificação de última geração foram avaliados: Claude Code (Opus 4.6), Gemini CLI (Gemini-3.1 Pro), Codex (GPT-5.4), Opencode (GLM-5.1) e Qwen CLI (Qwen3.5-397B-A17B).
• Orquestrador de Execução: Um orquestrador containerizado avalia os candidatos em três etapas sequenciais:
  1. Compilação: O candidato deve construir com sucesso.
  2. Implantação: A aplicação deve iniciar dentro de um tempo de execução containerizado e emitir sinais de prontidão.
  3. Testes Comportamentais: O candidato deve passar por uma suíte de 1.331 testes comportamentais escritos por especialistas.
• Oráculo: A correção é determinada por um oráculo comportamental neutro em relação ao framework. Em vez de testes unitários (que exigiriam migração eles próprios), o oráculo utiliza especificações Gherkin concretizadas em scripts Playwright/pytest. Esses testes verificam equivalência observável externamente (rotas HTTP, payloads de resposta, fluxos de UI e alterações de estado persistente).
• Métricas: O sucesso é medido por pass@1 em temperatura 0, exigindo que o candidato compile, implante e passe em 100% dos testes comportamentais.

Principais Contribuições

1. Conjunto de Dados SCARFBENCH: Um corpus curado de 34 famílias de aplicações gerando 102 variantes e 204 tarefas de migração direcionadas, verificado por 1.331 testes comportamentais escritos por especialistas em um ambiente containerizado.
2. Avaliação Empírica: Uma avaliação abrangente de cinco agentes de codificação de fronteira, revelando lacunas significativas nas capacidades atuais para transformações em nível de sistema.
3. Taxonomia de Falhas: Uma classificação de 13 categorias recorrentes de falhas abrangendo etapas de build, implantação e teste, derivada da adjudicação por especialistas de traços falhos.

Resultados Experimentais

A avaliação revela que a migração entre frameworks que preserva o comportamento permanece um desafio significativo para os agentes atuais:

• Taxas de Sucesso Baixas: O agente mais forte (Claude Code com Opus 4.6) alcançou apenas 15,3% de aprovação agregada de testes em migrações de camadas focadas e 12,2% em aplicações completas. Em todas as 204 tarefas direcionadas, apenas uma migração produzida por agente passou em sua suíte completa de testes.
• Build/Implantação vs. Comportamento: Há uma desconexão nítida entre o sucesso superficial e a correção comportamental. Os agentes frequentemente produzem código que compila e implanta, mas falha nos testes comportamentais. Por exemplo, em migrações de aplicação completa, o sucesso de compilação pode atingir 87%, enquanto o sucesso comportamental cai para 12%.
• Dificuldade Assimétrica: A dificuldade da migração depende altamente do framework de destino:
  • Spring $\leftrightarrow$ Quarkus: O par mais tratável.
  • Alvos Jakarta EE: Os mais difíceis. Apenas 2% das migrações com destino ao Jakarta EE passam nos testes comportamentais, com 57% falhando na porta de compilação.
• Engenharia de Prompt: A "prompting baseada em habilidades" (modularizando orientações) melhorou as taxas de compilação e implantação, particularmente para tarefas focadas, mas não fechou significativamente a lacuna na correção comportamental para aplicações completas.

Análise de Falhas

A análise de tarefas falhas identificou que os erros se estendem além da tradução em nível de origem. Modos de falha comuns incluem:

• Etapa de Build: Problemas de resolução de dependências, referências de módulos desatualizadas e incompatibilidades na estrutura do projeto.
• Etapa de Implantação: Incompatibilidades de recursos/artefatos (por exemplo, empacotamento WAR vs. JAR), configuração incorreta do tempo de execução (por exemplo, incompatibilidades de porta) e fiação de dependências quebrada.
• Etapa de Teste: Endpoints ausentes, conteúdo de resposta incorreto e problemas de conectividade de infraestrutura.
  Os autores observam que as migrações com destino ao Jakarta falham desproporcionalmente na porta de compilação, sugerindo uma divergência entre as idiossincrasias de framework aprendidas e as convenções de empacotamento/configuração de servidor do Jakarta.

Significado e Alegações

O artigo afirma que, embora os agentes atuais possam traduzir com confiabilidade APIs de framework em nível de origem, eles lutam para re-expressar o comportamento da aplicação através do modelo de execução do framework de destino. Os resultados sugerem que o progresso em benchmarks em nível de repositório (como correção de bugs ou atualizações de versão) não se transfere limpa para transformações em nível de sistema que exigem execução em um tempo de execução de destino.

Os autores posicionam o SCARFBENCH como um passo necessário para avaliar as capacidades "agênticas" dos LLMs em cenários empresariais realistas, destacando que a verdadeira modernização exige mais do que substituição sintética; demanda uma compreensão profunda do acoplamento arquitetônico, semântica de configuração e preservação comportamental. O benchmark, o orquestrador e os traços dos agentes são liberados para facilitar pesquisas futuras sobre modernização automatizada de software.