Senior SWE-Bench: benchmark open-source que avalia agentes como engenheiros seniores

Dificuldade do benchmark e comparação com humanos

  • A atual taxa de resolução no topo é de ~24% usando um modelo de fronteira; alguns se perguntam qual seria a pontuação de um engenheiro humano competente.
  • Vários observam que humanos podem se especializar em uma única base de código e usar LLMs como ferramentas, então comparações diretas de porcentagem são complicadas.
  • Há curiosidade sobre como configurações com human-in-the-loop (LLM pedindo ajuda a humanos) afetariam o desempenho.

Design do benchmark, objetividade e escopo

  • Muitos criticam o benchmark por ser subjetivo demais e estreito demais, especialmente em torno de soluções “de bom gosto” versus “inchadas”.
  • Alguns argumentam que benchmarks deveriam focar na qualidade do produto de ponta a ponta (funcionalidades, bugs, comportamento ao longo do tempo), em vez de diffs de código.
  • Outros enfatizam que o trabalho real de um “sênior” inclui planejamento, documentação, levantamento de requisitos e restrições organizacionais — difícil de codificar em uma única tarefa de programação.
  • Há um apelo por uma articulação mais clara de quais eixos estão sendo testados (planejamento, design, manutenibilidade, desempenho etc.).

LLMs como juízes e a noção de “taste”

  • Há ceticismo sobre usar LLMs para julgar qualidades subjetivas como “soluções de bom gosto”, especialmente se o modelo de codificação e o modelo julgador forem relacionados.
  • Preocupações com viés (modelos preferindo saídas da própria família) e com “prompt woo” do tipo “você é um revisor sênior, não cometa erros”.
  • Contra-argumento: alguns padrões (por exemplo, métricas de manutenibilidade, regras ao estilo ISO) podem, em parte, objetivar a qualidade do código, mas até isso é contestado.
  • Debate sobre se “taste” é só ego e vibração ou uma heurística do System 1 endurecida para manutenibilidade e robustez.

Comparações de modelos e efeitos do harness

  • Experiências mistas comparando Opus 4.8 e GPT 5.5: alguns veem o Opus como muito melhor em trabalho de alto nível e mal especificado; outros acham o GPT 5.5 claramente superior, exceto em domínios específicos.
  • Vários destacam que o “harness” (ferramentas, ambiente, prompting) importa tanto quanto o modelo base.

Requisitos mal especificados e o que significa “sênior”

  • A alegação do benchmark de que engenheiros seniores constroem funcionalidades a partir de requisitos mal especificados é contestada.
  • Múltiplos comentaristas dizem que seniores de verdade obtêm proativamente requisitos de usuários, métricas e stakeholders, em vez de inventá-los.
  • Outros observam que seniores também precisam resolver ambiguidades e intuir restrições ausentes, não apenas executar tarefas totalmente especificadas.

Longevidade, gaming e benchmarks alternativos

  • O fato de ser open-source e baseado em mudanças reais de OSS levanta preocupações sobre overfitting e sobre modelos memorizarem dados de treino.
  • Há dúvidas sobre como manter o benchmark comparável ao longo do tempo, conforme os modelos passam a treinar em suas tarefas.
  • Ideias mencionadas incluem geração adversarial de perguntas com pontuação estilo ELO, níveis de dificuldade ancorados em humanos e requisitos em evolução simulada com roleplay de LLMs.