Resumo Técnico: SWE-INTERACT

Declaração do Problema

Os atuais benchmarks de engenharia de software (SWE) de fronteira avaliam majoritariamente agentes de codificação em tarefas de implementação autônomas de turno único. Nestes cenários, os agentes recebem requisitos completos e bem especificados de antemão e são avaliados por sua capacidade de executar uma solução de forma independente. No entanto, estudos de larga escala de interações reais entre desenvolvedores e agentes (ex: SWE-chat) revelam um contraste gritante: fluxos de trabalho reais raramente são de etapa única (one-shot). Em vez disso, envolvem loops iterativos de múltiplos turnos, onde usuários fornecem instruções iniciais vagas ou incompletas, inspecionam o espaço de trabalho do agente e revelam progressivamente os requisitos por meio de feedback direcionado e revisões.

Benchmarks existentes que tentam simular interações com o usuário no loop frequentemente simplificam o problema ao iniciar com um prompt razoavelmente detalhado ou ao utilizar "usuários" estáticos e não agênticos que não conseguem inspecionar código ou executar comandos. Isso cria uma lacuna entre o desempenho do benchmark e a realidade da descoberta interativa de objetivos, onde os agentes devem inferir a intenção, adaptar-se a restrições em evolução e refinar seu próprio trabalho prévio sem uma especificação completa no início.

Metodologia: SWE-INTERACT

Os autores introduzem o SWE-INTERACT, um novo ambiente de teste projetado para reformular os benchmarks de SWE como sessões de codificação de longo horizonte impulsionadas pelo usuário. A metodologia envolve três componentes principais:

1. Adaptação de Tarefas

Os autores adaptaram 75 tarefas de três benchmarks de fronteira existentes (SWE-bench Pro, SWE Atlas e DeepSWE). Estas eram originalmente tarefas de turno único com especificações completas. Elas foram convertidas em tarefas de múltiplos turnos ao remover do prompt inicial os detalhes dos requisitos, deixando apenas uma descrição de alto nível e vaga.

2. O Simulador de Usuário

Uma inovação crítica é o simulador de usuário condicionado por persona, fundamentado em dados de sessões de codificação reais (SWE-chat).

• Persona: Modelada após a persona "Expert Nitpicker" (Especialista Detalhista), caracterizada por comunicação curta, direta e iterativa. Este usuário não escreve código, mas critica implementações, solicita detalhes específicos de API e revela requisitos um a um.
• Capacidades Agênticas: Diferente de simuladores estáticos anteriores, este agente de usuário possui acesso ao shell do espaço de trabalho do agente. Ele pode executar comandos (ex: git, grep, sed) para inspecionar diffs, pesquisar na base de código e verificar o trabalho do agente antes de fornecer feedback.
• Fluxo de Interação: O fluxo de trabalho segue um loop de DESCOBERTA DE OBJETIVO → PLANO → APROVAÇÃO → IMPLEMENTAÇÃO → REVISÃO → ENVIO. O usuário inicia com uma solicitação vaga, revisa o plano do agente, inspeciona o espaço de trabalho e evidencia progressivamente requisitos latentes até que a tarefa completa seja entregue.

3. Estrutura de Avaliação

As tarefas são executadas no framework Harbor utilizando sandboxes conteinerizadas.

• Verificação: O sucesso é determinado pelo verificador de tarefa original (testes unitários e rubricas) dos benchmarks de origem, não pela aprovação do simulador de usuário. Isso isola a dificuldade da interação da dificuldade da implementação.
• Métricas: O estudo monitora taxas de resolução, etapas de interação, uso de tokens, custo e modos específicos de falha (ex: requisitos esquecidos, bugs técnicos).

Principais Contribuições

1. Um Novo Ambiente de Teste: Um conjunto de 75 tarefas de múltiplos turnos com um sistema que converte benchmarks estáticos em fluxos de trabalho dinâmicos e impulsionados pelo usuário.
2. Simulador de Usuário Agêntico: Um framework para criar agentes de usuário realistas que emulam comportamentos reais de desenvolvedores, incluindo inspeção de espaço de trabalho e crítica iterativa, indo além de chamadas de API estáticas.
3. Análise Abrangente: Uma decomposição detalhada das capacidades dos agentes em configurações de múltiplos turnos, incluindo análise de trajetória, pontuação de descoberta de objetivo e categorização de modos de falha.

Resultados Experimentais

Os autores avaliaram diversos modelos de fronteira (GPT 5.5, Opus 4.8, Kimi K2.6, Gemini 3.5 Flash, Sonnet 4.6) tanto em baselines de turno único quanto nas novas tarefas de múltiplos turnos do SWE-INTERACT.

Lacuna de Desempenho

• Taxas de Resolução: O forte desempenho em turno único não se transfere de forma confiável para os cenários de múltiplos turnos. Embora os melhores modelos tenham alcançado aproximadamente 50% de taxas de resolução em baselines de turno único, esse valor caiu para cerca de 25–27% no cenário de múltiplos turnos.
• Consumo de Recursos: Tarefas de múltiplos turnos exigiram significativamente mais recursos. Os agentes realizaram de 3 a 4 vezes mais etapas, utilizaram de 2 a 4 vezes mais tokens e incorreram em custos de 2 a 3,5 vezes maiores por tentativa em comparação com as baselines de turno único.
• Variância de Modelo:
  • Melhores Desempenhos: GPT 5.5 e Opus 4.8 começaram fortes mesmo com instruções vagas, perseveraram através da ambiguidade e integraram bem os requisitos, embora ainda tenham sofrido com bugs técnicos e requisitos esquecidos.
  • Modelos Mais Fracos: Modelos como Kimi K2.6 e Sonnet 4.6 tiveram dificuldades significativas sob ambiguidade, muitas vezes desistindo precocemente, ignorando instruções ou falhando em refinar o código de forma eficaz.

Descoberta de Objetivo vs. Implementação

• Planejamento: Modelos fortes (ex: GPT 5.5) frequentemente identificaram uma alta porcentagem (>80%) de objetivos latentes durante a fase inicial de planejamento.
• Queda na Implementação: Houve uma queda significativa na cobertura de objetivos ao passar do plano para o primeiro checkpoint de implementação, frequentemente devido a erros técnicos ou especificações perdidas.
• Recuperação: A maioria dos modelos recuperou a cobertura de objetivos ao longo dos turnos subsequentes, à medida que o usuário revelava requisitos omitidos, mas a implementação final ainda frequentemente falhava no verificador devido a bugs técnicos ou regressões.

Modos de Falha

Uma auditoria de 287 trajetórias de falha revelou as causas primárias:

• Bugs de Implementação Técnica (~34%): O agente entendeu o requisito, mas introduziu erros de código.
• Requisitos Esquecidos (~34%): O agente falhou em implementar um requisito introduzido em um turno anterior.
• Má Interpretação/Premissas Erradas (~14%): O agente interpretou mal o requisito ou fez suposições incorretas sem esclarecer.
• Requisitos de Usuário Ausentes (~12%): Casos onde o simulador falhou em apresentar um requisito necessário (falsos negativos do benchmark).

Estudos de Ablação

• Impacto da Persona: O uso da persona "Expert Nitpicker" (vs. uma baseline neutra) tornou as tarefas mais difíceis e longas, aumentando as etapas de interação em 30–50% e diminuindo as taxas de resolução para a maioria dos modelos, destacando a lacuna entre interações idealizadas e realistas.
• Modelo do Simulador: A escolha do modelo do simulador de usuário (GPT 5.5 vs. Opus 4.7) afetou significativamente o realismo. O GPT 5.5 atuou como um crítico mais rigoroso, revelando requisitos ao longo de mais turnos e inspecionando o espaço de trabalho de forma mais profunda, o que levou a um melhor desempenho final do agente, porém com trajetórias mais longas.

Significância e Alegações

O artigo afirma que o SWE-INTERACT mede um eixo de capacidade ortogonal para o desenvolvimento de modelos de fronteira: descoberta interativa de objetivos e refinamento iterativo com um usuário no loop.

Os autores argumentar que trabalhar efetivamente com um usuário não é meramente uma versão estendida da codificação autônoma, mas um conjunto de habilidades distinto. Os resultados sugerem que, embora os modelos de fronteira consigam perseverar sob ambiguidade e recuperar a maioria dos objetivos pretendidos através de revisão, eles ainda lutam para manter implementações corretas conforme o feedback se acumula. O artigo posiciona o SWE-INTERACT como um instrumento mais aguçado para estudar essa capacidade específica, visando guiar o desenvolvimento de agentes de codificação que possam colaborar de forma mais confiável em fluxos de trabalho reais de engenharia de software.