Benchmark Real-SWE expõe a lacuna entre pontuações de IA para programação e o trabalho empresarial

A Specific Labs lançou o benchmark Real-SWE com 640 execuções de agentes, e a configuração mais bem classificada resolveu apenas 38,8% do trabalho atribuído.

Esse resultado cria um contraste desconfortável com os rankings públicos de programação. Os agentes parecem cada vez mais capazes de lidar com problemas em nível de repositório, mas a maioria das tentativas no Real-SWE falhou em sistemas privados de produção.

A diferença não se deve simplesmente ao fato de o Real-SWE conter desafios de programação mais difíceis. Suas tarefas exigem que os agentes reconstruam regras de negócio, naveguem por arquiteturas desconhecidas e coordenem mudanças entre código e serviços conectados.

Essa distinção importa porque as empresas não contratam engenheiros de software para resolver exercícios isolados e sem contexto. Elas precisam de engenheiros que preservem o comportamento existente ao modificar sistemas que já processam dados de clientes, permissões, cobrança e infraestrutura.

O Real-SWE, portanto, desafia a promessa implícita em altas pontuações de benchmarks públicos. Ele pergunta se um agente consegue entrar em uma base de código empresarial desconhecida e concluir trabalho economicamente útil sem depender de artefatos públicos familiares.

A resposta inicial é sóbria. O benchmark oferece evidências de que modelos de programação podem produzir patches plausíveis, mas não sustenta uma implantação sem supervisão em fluxos de trabalho empresariais relevantes.

O que o benchmark Real-SWE realmente mudou

O Real-SWE desloca o alvo da avaliação de problemas em repositórios públicos para sistemas privados com regras específicas de cada empresa e dependências operacionais.

A Specific Labs anunciou o benchmark em 12 de setembro de 2026. A empresa o descreve como uma avaliação de modelos de fronteira em bases de código privadas de produção licenciadas por empresas em operação.

A versão inicial abrange dez tarefas e oito configurações de modelos e harnesses. Cada configuração recebe oito tentativas independentes por tarefa, produzindo 640 execuções avaliadas.

Esse desenho com execuções repetidas importa. Um único patch bem-sucedido pode esconder uma inconsistência substancial, enquanto oito tentativas mostram se um agente resolve a mesma classe de problema de forma confiável.

O ranking publicado informa pass@1, isto é, a probabilidade de que uma tentativa resolva a tarefa. A Specific Labs calcula a média desse resultado entre as oito execuções atribuídas a cada tarefa.

Fable 5.1 com Claude Code liderou o ranking inicial com 38,8%. GPT-6 Astra com Codex CLI veio em seguida, com 33,8%, enquanto Gemini 3.8 Flash com Gemini CLI atingiu 31,2%.

GLM 5.3 com Claude Code registrou 28,8%. Grok 4.6 e Muse Spark 1.3 atingiram 23,8% cada um com seus respectivos sistemas de agentes.

Kimi K3 com Kimi Code alcançou 18,8%. GPT-5.6 Sol com Codex CLI terminou com 16,2% nesta avaliação específica.

Esses resultados avaliam combinações, não modelos de linguagem isolados. Um harness fornece ferramentas, controla o ciclo de interação e molda a forma como um modelo explora e edita um repositório.

A Specific Labs afirma explicitamente que utilizou harnesses nativos destinados a refletir os fluxos de trabalho atuais de engenharia. Essa escolha melhora a relevância prática, mas complica comparações diretas entre modelos.

Uma pontuação mais alta pode refletir o raciocínio do modelo, o comportamento do harness, a confiabilidade das ferramentas ou a interação entre os três. O ranking não consegue isolar esses efeitos de forma clara.

A mudança mais profunda do benchmark diz respeito à exposição dos dados. Testes públicos de programação normalmente usam repositórios open source, problemas públicos e históricos de soluções visíveis.

Repositórios privados reduzem a chance de que um modelo tenha encontrado o patch relevante durante o treinamento. Eles também impedem que um agente encontre uma resposta por meio de buscas públicas.

De acordo com os resultados publicados do Real-SWE, cada tarefa se originou de trabalho associado a uma base de código privada real. Algumas instruções teriam sido extraídas diretamente de trabalhos reais de engenharia.

Esse desenho torna a avaliação menos parecida com uma prova criada para modelos. Ele a aproxima mais de colocar um novo contratado dentro de uma organização de software desconhecida.

A distinção também muda o significado da falha. Um patch malsucedido pode refletir programação fraca, mas também pode revelar uma descoberta deficiente de requisitos ou uma compreensão incompleta do sistema.

Esse é precisamente o território em que implantações empresariais se tornam arriscadas. Um patch pode compilar, passar em testes óbvios e ainda violar uma regra incorporada em outra parte do negócio.

Por que o código empresarial privado cria um teste diferente

O desafio central não é gerar mais código. É descobrir de qual comportamento a empresa já depende e preservá-lo em vários sistemas.

Um exemplo do Real-SWE pede que um agente corrija a tributação de faturas. A descrição curta oculta diversas condições envolvendo configuração empresarial, isenções de clientes, regras geográficas e serviços externos de impostos.

O agente precisa determinar quando usar uma alíquota armazenada e quando calcular o imposto com base no destino do comprador. Também precisa reconhecer contas que não cobram imposto.

Também deve preservar isenções, registrar corretamente os totais da fatura e informar endereços rejeitados sem interromper a fatura. Transações liquidadas precisam ser retornadas à autoridade tributária.

Transações europeias acrescentam outro requisito relacionado a registros de VAT. Concluir o trabalho pode envolver um serviço TypeScript, ambientes TaxJar e um livro-razão InfluxDB.

Nenhuma dessas operações individuais representa um algoritmo exótico. A dificuldade vem de coordená-las sem ignorar uma condição ou prejudicar o comportamento existente.

Esse padrão aparece em todo o software empresarial. Uma solicitação que parece local frequentemente atravessa APIs, bancos de dados, trabalhos em segundo plano, configuração, testes e ferramentas operacionais.

Os ambientes Real-SWE podem expor serviços e ferramentas como Docker, Kubernetes, GitHub, PostgreSQL, MySQL, Redis, Slack, e-mail e sistemas de suporte ao cliente.

Cada tarefa recebe apenas os serviços de que seu fluxo de trabalho precisa. Ainda assim, um agente precisa decidir quais sistemas contêm evidências relevantes e quais são distrações.

O benchmark informa uma extensão mediana de instruções de 1.742 caracteres. Isso é mais curto que uma especificação detalhada de implementação, deixando os agentes inferirem a estrutura a partir do código e do contexto disponíveis.

As soluções de referência alteraram uma mediana de 11 arquivos. Os dados comparativos do benchmark situam isso acima das medianas de seis arquivos registradas para FrontierCode e DeepSWE.

Essa lacuna ajuda a explicar por que a navegação pelo repositório importa. Um modelo que encontra um ponto óbvio de implementação ainda pode deixar de considerar validação, persistência, configuração ou consumidores posteriores.

A Specific Labs afirma que seis das dez tarefas tiveram taxas de resolução inferiores a 15%. Nenhuma configuração testada resolveu todas as tarefas.

A análise de falhas identifica requisitos ignorados como a categoria mais comum. Outras falhas observadas incluíram suposições não verificadas, erros de integração, regressões e edições no arquivo errado.

Essas categorias se assemelham mais a comentários comuns de revisão de engenharia do que a erros de sintaxe. Elas sugerem que os agentes frequentemente produzem mudanças locais plausíveis sem construir um modelo completo do sistema.

O tempo, por si só, não separou os vencedores das falhas. O benchmark afirma que 70 de 98 execuções com duração inferior a dez minutos falharam, uma taxa de falha de 71,4%.

Entre as execuções mais longas, 398 de 542 falharam, representando 73,4%. Portanto, mais tempo de execução não corrigiu automaticamente uma exploração fraca ou suposições equivocadas.

A comparação entre execuções curtas e longas não deve ser tratada como prova de que raciocínio adicional nunca ajuda. Tarefas mais difíceis provavelmente geram tentativas mais longas, criando um importante fator de confusão.

Ainda assim, o resultado enfraquece uma explicação conveniente. Esses agentes não falharam apenas porque todas as execuções terminaram antes que o modelo pudesse concluir a digitação de uma solução.

O mecanismo mais plausível é a formação incompleta de contexto. Um agente precisa identificar requisitos, localizar sua implementação, rastrear dependências e verificar toda a mudança.

Esse fluxo de trabalho se beneficia de conhecimento duradouro sobre o repositório. As equipes de engenharia já mantêm notas de arquitetura, histórico de incidentes, decisões e documentos técnicos pelo mesmo motivo.

Uma base de conhecimento de engenharia pesquisável pode reduzir o trabalho repetido de descoberta para humanos. Sistemas de agentes precisam cada vez mais de uma camada de contexto equivalente.

O Real-SWE não estabelece que uma memória persistente resolveria essas tarefas. Ele mostra por que a geração de código sem estado é um modelo incompleto para a engenharia empresarial.

Pontuações públicas de programação encontram a realidade do código privado

A principal disputa ocorre entre uma capacidade de programação visível em benchmarks e um desempenho confiável dentro de sistemas que os modelos nunca encontraram.

O SWE-bench transformou a avaliação de programação ao pedir que modelos resolvessem problemas reais do GitHub em snapshots de repositórios. Isso foi um grande avanço em relação a testes isolados de geração de funções.

O benchmark original conectou descrições de problemas, estado do repositório e avaliação baseada em execução. Ele ajudou a conduzir o campo em direção a agentes que exploram, editam e testam software.

No entanto, esses repositórios e históricos de problemas são públicos. À medida que os modelos melhoram e os dados de avaliação circulam, a contaminação se torna mais difícil de excluir.

A contaminação ocorre quando os dados de treinamento de um modelo contêm tarefas de benchmark, patches relevantes ou cópias próximas. Uma pontuação alta pode então misturar generalização com reconhecimento ou memorização.

O SWE-bench Verified tentou melhorar a qualidade das tarefas por meio de revisão humana. Seu conjunto de dados verificado reteve 500 amostras após avaliar descrições de problemas e testes.

A própria revisão demonstrou como é difícil construir avaliações de programação. A OpenAI informou que 68,3% das amostras avaliadas foram removidas devido a problemas de especificação, testes ou questões relacionadas.

O benchmark filtrado continuou útil, mas não eliminou a exposição pública. Desenvolvedores de modelos ainda podiam estudar os repositórios, as tarefas, o comportamento da avaliação e os padrões comuns de falha.

Auditorias mais recentes aumentaram a pressão por novos desenhos de avaliação. A auditoria de benchmarks de 2026 da OpenAI relatou preocupações de desenho e contaminação em avaliações de programação amplamente usadas.

A auditoria também estimou que cerca de 30% das tarefas do SWE-Bench Pro estavam com problemas. Os problemas relatados incluíam testes excessivamente rígidos, requisitos ausentes, cobertura fraca e prompts enganosos.

O Real-SWE aborda uma parte desse problema ao manter privados os repositórios e as soluções subjacentes. Os modelos não podem recuperar um patch público exato se esse patch nunca foi publicado.

No entanto, dados privados introduzem uma troca diferente. Pesquisadores externos não podem inspecionar livremente todos os repositórios, reproduzir todas as tarefas ou auditar testes ocultos.

Isso reduz a transparência justamente quando um benchmark faz alegações comercialmente significativas. Os leitores precisam confiar no licenciamento, na anonimização, na construção de tarefas e no processo de pontuação do operador do benchmark.

O Real-SWE fornece exemplos de tarefas, resultados agregados, intervalos de confiança e uma taxonomia de falhas. Essas divulgações ajudam, mas não equivalem a uma avaliação abertamente reproduzível.

O tamanho de dez tarefas apresenta outra limitação. Execuções repetidas medem a consistência entre tentativas, mas a repetição não cria uma cobertura mais ampla de tarefas.

Um benchmark com dez tarefas pode ser sensível à seleção delas. Uma única arquitetura, combinação de linguagens ou domínio de negócio pode influenciar materialmente os rankings.

O emparelhamento entre modelo e harness acrescenta mais incerteza. Claude Code aparece com mais de um modelo, enquanto o Codex CLI também aparece com vários modelos.

Essa variação fornece informações úteis sobre implantação. Ela não produz uma comparação controlada em que cada modelo recebe uma estrutura e uma política de ferramentas idênticas.

Portanto, a interpretação correta é mais restrita do que um ranking universal de modelos. Essas pontuações mostram como configurações nomeadas se saíram nesta versão do Real-SWE sob sua configuração documentada.

Elas não provam que o modelo líder é o melhor para todas as empresas. Também não estabelecem que a configuração com pior classificação não possui capacidades úteis de programação.

Em vez disso, o benchmark oferece um alerta contra a transferência direta de pontuações públicas para expectativas de implantação privada. Esse alerta está alinhado à reavaliação mais ampla do campo de avaliação.

A METR faz uma distinção relacionada em sua metodologia de tarefas. Suas tarefas autocontidas fornecem intencionalmente aos modelos critérios claros de sucesso e dependência limitada do histórico organizacional.

A METR observa que o trabalho real frequentemente depende de conversas anteriores, conhecimento tácito e familiaridade com uma base de código existente. Sua metodologia compara os agentes mais de perto com contratados que têm pouco contexto.

O Real-SWE avança ainda mais nesse problema de baixo contexto. Ele mantém a avaliação executável enquanto introduz convenções específicas de empresas e relações operacionais.

Essa é a reversão mais importante do benchmark. Um bom desempenho em issues públicas deixa de servir como evidência suficiente de autonomia empresarial confiável.

O Leaderboard Pressiona Compradores Tanto Quanto Fornecedores de Modelos

O Real-SWE pressiona as equipes de avaliação corporativa porque as pontuações dos fornecedores não podem substituir testes no próprio ambiente do comprador.

Uma empresa que avalia agentes de programação geralmente enfrenta uma assimetria de informação. Os fornecedores conhecem seus modelos, enquanto os compradores conhecem seus repositórios, fluxos de trabalho e tolerância a riscos.

Leaderboards públicos dão às duas partes uma referência comum. Eles simplificam a comparação, mas essa simplicidade se torna perigosa quando o ambiente de implantação difere do benchmark.

O Real-SWE torna a incompatibilidade visível. Mesmo sua configuração mais forte falhou em mais de seis a cada dez tentativas no conjunto de tarefas avaliado.

Um comprador não deve traduzir esse número diretamente em uma taxa esperada de falhas em produção. Dez tarefas de benchmark não podem representar todos os repositórios ou organizações de engenharia.

Ainda assim, o número muda a conversa de compras. As equipes precisam de evidências sobre confiabilidade em seu próprio código, não apenas de desempenho em históricos públicos de issues.

Isso significa criar avaliações internas a partir de trabalhos representativos já concluídos. Tarefas adequadas podem incluir correções de bugs, migrações, alterações de permissões e trabalho de integração com resultados conhecidos.

A solução de referência não deve se tornar a única implementação aceitável. Os revisores precisam distinguir a correção funcional da semelhança superficial com o patch original de um engenheiro.

Os testes ocultos também exigem escrutínio. Um benchmark pode punir uma alternativa válida se seu verificador codificar detalhes de implementação não declarados.

As auditorias de benchmark da OpenAI mostram a frequência com que isso acontece. A qualidade da avaliação exige que engenheiros experientes comparem instruções, testes, alterações de referência e rastros dos agentes.

As organizações também devem testar configurações completas. A decisão do Real-SWE de pontuar pares de modelo e harness reflete como os agentes de programação operam na prática.

Busca no repositório, acesso ao shell, execução de testes, gerenciamento de contexto e políticas de nova tentativa podem alterar materialmente o desempenho. Medir apenas o modelo subjacente ignora essas dependências.

A segurança pertence à mesma avaliação. O acesso ao código-fonte privado levanta questões sobre retenção, controles do fornecedor, exposição de segredos, registros e permissões.

Um agente que resolve mais tarefas ainda pode ser inadequado se receber acesso mais amplo do que a organização pode conceder com segurança. Capacidade e risco de implantação devem ser avaliados em conjunto.

A carga de revisão fornece outra medida crítica. Um patch que acaba funcionando pode exigir tanta investigação humana que oferece pouco benefício de produtividade.

As equipes devem registrar com que frequência um agente deixa requisitos de lado, cria regressões ou precisa de prompts corretivos. Essas medidas correspondem de perto às categorias de falha do Real-SWE.

Elas também devem acompanhar a variância. Uma demonstração bem-sucedida diz pouco sobre se o agente consegue repetir o resultado na próxima tentativa.

A discussão sobre o benchmark no Hacker News capturou os dois lados dessa questão. Alguns participantes receberam bem os testes repetidos de pass@1 porque eles revelam consistência.

Outros argumentaram que as ferramentas atuais ainda funcionam melhor por meio de estreita colaboração humana. Nessa visão, o operador qualificado continua fazendo parte do sistema avaliado.

Esse modelo de “centauro” une um humano a um agente de IA. O humano fornece julgamento, contexto e revisão, enquanto o agente cuida de exploração, elaboração e mudanças mecânicas.

O Real-SWE não compara agentes autônomos com equipes de especialistas e agentes. Portanto, seus resultados não devem ser interpretados como evidência de que assistentes de programação não têm valor prático.

Eles indicam algo mais específico. As configurações testadas não substituem de forma confiável o trabalho de contextualização e verificação realizado por engenheiros experientes.

Essa diferença importa para alegações de implantação. Auxiliar um engenheiro e assumir de forma autônoma uma mudança empresarial são patamares distintos de capacidade.

Os compradores devem exigir que os fornecedores indiquem qual patamar suas evidências sustentam. Uma pontuação pública, por si só, não pode responder a essa pergunta.

O Que os Números do Real-SWE Não Provam

O benchmark fornece um alerta significativo, mas sua pequena amostra privada não pode sustentar conclusões abrangentes sobre todos os modelos ou bases de código empresariais.

Primeiro, as tarefas do Real-SWE vêm de empresas selecionadas pela Specific Labs. Os exemplos publicados incluem um aplicativo de consumo, uma plataforma fintech e software empresarial de vendas.

A Specific Labs afirma que um dos aplicativos representados atende mais de 200.000 usuários. Outra plataforma processaria mais de 100.000 extratos bancários.

Esses detalhes estabelecem relevância comercial, mas as empresas permanecem anônimas. Os leitores não podem avaliar de forma independente sua qualidade de engenharia, arquitetura ou complexidade de domínio.

Segundo, a privacidade do benchmark impede a replicação pública completa. Essa privacidade protege código licenciado e reduz a contaminação direta, mas concentra a autoridade de validação.

Avaliadores independentes precisam de acesso controlado para confirmar a procedência das tarefas, a qualidade dos verificadores, a paridade de ambiente e a pontuação. Sem essa revisão, alguma incerteza continua inevitável.

Terceiro, o leaderboard combina modelos diferentes com harnesses nativos diferentes. Isso se assemelha ao uso real de produtos, mas enfraquece conclusões sobre a inteligência subjacente dos modelos.

Uma configuração pode perder porque sua estratégia de busca falha, suas chamadas de ferramentas quebram ou seu gerenciamento de contexto descarta evidências relevantes. Essas são falhas de produto, mas não falhas idênticas.

Quarto, o benchmark usa resolução automatizada como seu resultado principal. Passar em um verificador é necessário, embora a aceitabilidade empresarial possa exigir mais.

A revisão em produção pode considerar manutenibilidade, observabilidade, segurança, segurança de migração, estilo e carga operacional futura. Uma aprovação binária não consegue capturar plenamente essas dimensões.

Por outro lado, um patch válido pode falhar em um verificador imperfeito. O histórico de auditorias do SWE-bench mostra que testes ocultos podem rejeitar soluções razoáveis ou deixar passar soluções incompletas.

O Real-SWE afirma que o comportamento exigido deve ser declarado ou razoavelmente descobrível. Esse padrão é sensato, mas “razoavelmente descobrível” ainda exige julgamento.

Quinto, tarefas empresariais anônimas podem favorecer modelos ou harnesses cujos padrões de exploração coincidem com o benchmark. Uma estrutura de repositório diferente poderia inverter algumas classificações.

Os intervalos de confiança de 95% exibidos no leaderboard reconhecem a variação de amostragem entre execuções. Eles não eliminam a incerteza decorrente da seleção de apenas dez tarefas.

Sexto, a página de lançamento faz uma afirmação ampla de que a maioria dos tokens empresariais permanece oculta para modelos de fronteira. Essa declaração apoia a motivação do benchmark, mas não apresenta detalhes públicos de medição.

Ela deve ser tratada como o enquadramento da empresa, e não como uma estatística estabelecida de forma independente. A conclusão mais segura é que uma parte substancial do contexto empresarial permanece privada.

Por fim, uma baixa taxa de resolução autônoma não equivale a baixo impacto na produtividade. Um agente pode economizar tempo por meio de investigação, geração de testes, documentação ou patches preliminares sem concluir de forma independente.

O oposto também é verdadeiro. Um patch concluído pode criar custos de revisão ou riscos sutis que compensam sua aparente velocidade.

Essas limitações não tornam o Real-SWE irrelevante. Elas definem as condições sob as quais suas conclusões são úteis.

O benchmark é mais forte como evidência de uma lacuna de implantação. É mais fraco como ranking definitivo de modelos ou previsão do emprego em engenharia.

A Specific Labs também é uma participante comercial no mercado de dados e avaliação empresariais. Seu perfil da empresa descreve um negócio construído em torno de ambientes e conjuntos de dados empresariais realistas.

Isso não invalida o trabalho. Torna a replicação independente e a metodologia transparente mais importantes.

Um ecossistema de benchmarks confiável precisa de múltiplos operadores, tarefas privadas rotativas e auditorias de terceiros. Nenhum leaderboard isolado deve se tornar a autoridade final.

Três Sinais Que Determinarão se o Real-SWE Importa

O Real-SWE se tornará relevante apenas se seu sinal de código privado resistir à expansão, à revisão independente e a lançamentos repetidos de modelos.

O primeiro sinal é o crescimento do conjunto de tarefas. Dez tarefas podem revelar modos de falha, mas uma coleção maior precisa abranger mais linguagens, arquiteturas e domínios de negócios.

A expansão deve preservar a procedência privada enquanto publica metadados suficientes para que os leitores entendam a diversidade das tarefas. Ela também deve separar amostras baseadas em repositórios de outros formatos de tarefa.

Se as classificações permanecerem semelhantes em um conjunto de testes mais amplo, a alegação de uma lacuna empresarial persistente se fortalecerá. Grandes mudanças de posição mostrariam que a seleção moldou os resultados do lançamento.

O segundo sinal é a avaliação independente. Pesquisadores externos ou fornecedores de modelos precisam de acesso controlado para auditar tarefas, verificadores e ambientes de execução.

Uma auditoria útil examinaria se os prompts contêm informações suficientes, se os testes ocultos aceitam implementações alternativas e se as soluções de referência representam trabalho genuíno de produção.

A concordância de revisores independentes reforçaria a confiança nas taxas de resolução reportadas. Falhas de teste descobertas restringiriam ou revisariam as conclusões do benchmark.

O terceiro sinal é o progresso em lançamentos repetidos. Benchmarks privados perdem valor se as tarefas vazam, tornam-se alvos de treinamento ou permanecem estáticas enquanto os sistemas de agentes se adaptam.

A Specific Labs precisará de novas tarefas reservadas e versionamento claro. Os resultados devem distinguir melhorias provenientes de modelos, harnesses, novas tentativas e exposição às tarefas.

Uma rápida elevação das pontuações em novas tarefas privadas indicaria melhor generalização. Ganhos limitados a tarefas antigas sugeririam otimização em torno do próprio benchmark.

As empresas devem observar a composição das falhas junto da taxa principal de aprovação. Menos requisitos ignorados e menos suposições não verificadas importariam mais do que patches gerados mais bonitos.

A consistência também deve melhorar. Um modelo que ocasionalmente resolve uma tarefa continua difícil de confiar quando o mesmo prompt frequentemente produz uma regressão.

Comparações entre humanos e agentes adicionariam outra camada útil. Medir o tempo de revisão e o tempo total de conclusão poderia mostrar onde os agentes já criam valor sem autonomia total.

Real-SWE colocou a pergunta certa diante de desenvolvedores e compradores de modelos. Um agente consegue alterar com segurança um software cuja história, convenções e lógica de negócio nunca foram públicas?

Seus primeiros resultados indicam que os sistemas atuais frequentemente não conseguem. A melhor configuração resolveu menos de quatro tentativas em cada dez, enquanto requisitos não atendidos dominaram as falhas observadas.

Essa conclusão deve estimular avaliações melhores, não uma rejeição generalizada. Agentes de programação podem continuar valiosos quando engenheiros controlam o escopo, fornecem contexto e verificam as consequências.

O próximo passo prático é testar trabalhos internos representativos antes de ampliar permissões. As equipes devem comparar configurações, repetir cada tarefa e estudar por que correções aparentemente razoáveis falham.

O benchmark Real-SWE importa se mudar o comportamento de compra, de confiar em pontuações públicas para exigir evidências privadas. Seu próximo teste de agente de programação medirá código gerado ou trabalho concluído que sua empresa possa aceitar com segurança?