Resumo Técnico: SWE-Together

Declaração do Problema

Os benchmarks atuais para agentes de codificação, como a família SWE-Bench e o Terminal-Bench, baseiam-se predominantemente em protocolos estáticos de turno único. Nestas configurações, um agente recebe uma descrição completa da tarefa antecipadamente e é avaliado exclusivamente pela correção de sua submissão de código final. Esta abordagem falha em refletir a realidade do auxílio à engenharia de software, que é inerentemente interativa e de múltiplos turnos. Em fluxos de trabalho do mundo real, os usuários revelam a intenção incrementalmente, esclarecem solicitações ambíguas, refinam requisitos e fornecem feedback corretivo ao longo de vários turnos.

Os benchmarks existentes sofrem de dois descompassos primários com a prática:

1. Design de Tarefa: Eles tratam as tarefas como instruções fixas, ignorando que a informação relevante para a tarefa é frequentemente distribuída através de múltiplos turnos e que as solicitações iniciais são frequentemente incompletas.
2. Métricas de Avaliação: Focam exclusivamente no sucesso da tarefa final, falhando em capturar o custo de interação. Dois agentes podem alcançar o mesmo score final, mas um pode ter sucesso a partir de uma solicitação vaga enquanto o outro requer especificações detalhadas extensas e feedback corretivo repetido.

Além disso, construir um benchmark que preserve a interação realista do usuário enquanto garante a verificabilidade é desafiador. Logs de conversas brutos frequentemente carecem de estados de repositório reproduzíveis, objetivos identificáveis ou resultados observáveis. Adicionalmente, simplesmente reproduzir os turnos originais do usuário para um novo agente é falho porque os turnos subsequentes do usuário devem ser condicionados à trajetória do novo agente para evitar o desvio de interação (interaction drift), mas devem permanecer ancorados à intenção do usuário original.

Metodologia

Para abordar esses desafios, os autores introduzem o SWE-Together, um benchmark composto por 109 tarefas de nível de repositório reconstruídas a partir de sessões reais de interação usuário-agente de codificação. A metodologia consiste em três componentes principais:

1. Pipeline de Construção de Sessão-para-Tarefa

Os autores selecionam 109 tarefas de 11.260 sessões registradas provenientes de quatro conjuntos de dados ascendentes: DataClaw, Pi-staging, Hyperswitch e SWE-chat. O pipeline de construção envolve três estágios:

• Filtragem de Elegibilidade Determinística: As sessões brutas são filtradas para reter aquelas com interações genuínas de múltiplos turnos, edições de código concretas e contextos de repositório recuperáveis. Sessões onde o usuário humano escreveu a alteração final são excluídas para garantir que o agente realizou um trabalho substantivo.
• Triagem de Viabilidade: Um juiz baseado em LLM analisa os candidatos para garantir que o trabalho de codificação possa ser reconstruído como uma tarefa autossuficiente e executável localmente. Sessões que dependem de estado externo (ex: implementações de serviços ao vivo, credenciais privadas) são rejeitadas.
• Construção da Tarefa: Um orquestrador de sandbox converte as sessões viáveis em pacotes de benchmark executáveis. Isso inclui a restauração do repositório em um commit fixado, a definição de artefatos de verificador determinísticos e a geração de prompts de simulação de usuário específicos para a tarefa.

2. Simulador de Usuário Ancorado e Condicional ao Estado

Para reproduzir interações com novos agentes, os autores desenvolvem um simulador de usuário reativo baseado em LLM. Diferente das reproduções estáticas, este simulador:

• Condiciona-se à Trajetória: Ele observa o último turno do agente avaliado, as mudanças no repositório e o tempo decorrido.
• Ancora-se na Intenção Original: Utiliza uma análise pré-computada da sessão original (objetivos, restrições e condições de intervenção) para garantir que a simulação permaneça fiel aos objetivos do usuário original.
• Política de Decisão Condicional ao Estado: O simulador decide se intervém (envia uma mensagem) ou permanece em silêncio (no-op) com base em se a trajetória atual do agente justifica feedback de acordo com a lógica da sessão original. Isso evita intervenções prematuras ou irrelevantes.

3. Protocolo de Avaliação Conjunta

A avaliação mede duas dimensões distintas:

• Corretude da Tarefa: O estado final do repositório é pontuado contra uma rubrica de implementação agnóstica congelada. Esta rubrica é derivada na Fase 1 (offline) da sessão original e do patch de referência, sendo aplicada na Fase 2 aos repositórios candidatos. A pontuação combina verificações executáveis determinísticas com um juiz de rubrica agêntico para avaliar a completude comportamental em vez da similaridade de código.
• Diagnósticos de Interação:
  • Correção do Usuário: Quantifica o direcionamento corretivo estimulado pelo agente. Conta correções explícitas e "empurrões" (nudges) ponderados (feedback mais suave) fornecidos pelo simulador.
  • Cobertura de Intenção: Uma métrica diagnóstica que mede o quão fielmente o simulador preserva as intenções e o escopo do usuário original através de diferentes execuções do agente.

Principais Contribuições

1. Benchmark SWE-Together: Um benchmark de 109 tarefas reconstruído de sessões reais de múltiplos turnos usuário-agente, apresentando um pipeline que converte sessões registradas em tarefas verificáveis e em sandbox.
2. Simulador de Usuário Condicional ao Estado: Um simulador de LLM ancorado que preserva as intenções originais do usuário e a ordem das intervenções, adaptando o tempo do feedback à trajetória específica de cada agente avaliado.
3. Protocolo de Avaliação Conjunta: Um framework que pontua a corretude final do repositório contra rubricas fixas enquanto caracteriza trajetórias de interação via Correção do Usuário e Cobertura de Intenção, indo além de simples métricas de pass/fail.

Resultados

Os autores avaliaram sete modelos de codificação de fronteira no benchmark de 109 tarefas usando o harness opencode com duas réplicas por tarefa.

• Ranking de Desempenho: O Claude Opus 4.8 alcançou o maior desempenho em todas as métricas (pass@1: 63%, Taxa de Resolução Estável: 59%, Pontuação Média do Juiz: 0.801). O GPT-5.5 ficou em segundo lugar (Juiz Médio: 0.763), seguido pelo Claude Opus 4.6. Os modelos mais fracos foram o DeepSeek-V4-Pro e o MiniMax-2.7.
• Capacidade vs. Intervenção: Foi observada uma forte correlação negativa entre a capacidade do modelo e a Correção do Usuário (correlação de Pearson de -0.92 com pass@1). Modelos mais fortes exigiram significativamente menos intervenções corretivas para atingir níveis de desempenho comparáveis (ex: Claude Opus 4.8 exigiu 1.38 correções em média, enquanto o MiniMax-2.7 exigiu 2.17).
• Eficiência: O GPT-5.5 foi o mais eficiente, exigindo menos tokens (29.9k) e tempo de execução (10.7 min) por tarefa, mantendo alta capacidade.
• Fidelidade do Simulador: A Cobertura de Intenção permaneceu estável em todos os coortes de modelos (pontuações entre 0.70–0.72), indicando que o simulador preservou consistentemente as intenções originais, independentemente do comportamento do agente.
• Indistinguibilidade Humana: Em um teste estilo Turing, anotadores humanos não conseguiram distinguir estatisticamente entre trajetórias de usuários simulados e reais (taxa de sucesso de 46%, IC incluindo 50%).

Significância e Alegações

O artigo afirma que o SWE-Together reformula a avaliação de agentes de codificação de tarefas de turno único para sessões reproduzíveis de múltiplos turnos, oferecendo uma avaliação mais realista da experiência do usuário.

• Além da Corretude Final: Os resultados sugerem que avaliar agentes apenas pelo código final é insuficiente; a quantidade de direcionamento corretivo exigido é um indicador crítico de capacidade e experiência do usuário.
• Interação Realista: Ao derivar tarefas de sessões reais e usar um simulador condicional ao estado, o benchmark captura a natureza dinâmica da engenharia de software, onde os requisitos evoluem.
• Comparação Confiável: A estabilidade da Cobertura de Intenção e a indistinguibilidade das trajetórias simuladas em relação às reais validam a capacidade do benchmark de fornecer avaliações justas e comparáveis entre diferentes coortes de modelos.

Os autores concluem que o SWE-Together demonstra a importância de avaliar agentes de codificação não apenas pelo fato de eles completarem uma tarefa, mas por quanto guia humano eles exigem para fazê-lo, alinhando assim as métricas do benchmark mais de perto com os fluxos de trabalho reais dos usuários.