Um novo benchmark publicado ontem isola um modo de falha que avaliações padrão de agentes de código vêm ocultando à vista: a brecha entre o que um LLM gera e o que o shell realmente executa. QuoteBench, de pesquisadores da LMU Munich e Universidade de Zhejiang, testa 56 tarefas Bash de uma única tentativa em 14 famílias derivadas de incidentes em oito configurações de harness. Um parser intencionalmente não-escapado entre geração e execução reduz o sucesso da tarefa em 55,4 a 73,2 pontos percentuais dependendo da configuração.

O artigo distingue três componentes: o contrato de geração (o que o modelo emite), o transporte de execução (como o harness serializa, encapsula e reanálisa essa saída) e o validador de estado final (se a avaliação verifica o estado real do sistema de arquivos ou apenas strings correspondentes). Benchmarks atuais colapsam todos os três. Uma "pontuação correspondente" informa se o comando parecia correto; não informa se o mesmo comando sobrevive a um caminho de execução real. QuoteBench introduz um parser não-escapado representando as camadas de serialização comuns em frameworks de agentes — encapsulamento JSON, manipulação de strings de subprocess, transporte MCP — e mede o que acontece com cada tarefa quando a mesma resposta do modelo passa por ele.

Os resultados expõem dois fenômenos separados. Primeiro, dano: o parser não-escapado por si só representa 55,4 a 73,2 pontos percentuais de perda de sucesso de tarefas sem alterar um único caractere da geração do modelo. Segundo, compensação: quando os modelos são informados sobre o limite de execução, eles adaptam seu estilo de geração e recuperam 30,4 a 60,7 pontos percentuais em seis das oito configurações — mas zero ou ligeiramente negativo nas outras duas. Algumas combinações harness-modelo não conseguem se adaptar, nem mesmo com divulgação explícita de prompt.

GPT-5.6-sol expõe essa estrutura oculta. Sua brecha correspondente — o número de manchete que um benchmark convencional relataria — é −3,6 pontos percentuais. A contabilidade QuoteBench subjacente: −64,3 pontos de dano do parser e +60,7 pontos de compensação da mudança de geração do modelo. A pontuação correspondente é aritmeticamente correta e operacionalmente sem sentido. Um time que escolheu GPT-5.6-sol porque parecia quase igual ao resto do campo em um leaderboard de pontuação correspondente está executando um modelo que depende de 60,7 pontos percentuais de auto-correção apenas para permanecer competitivo nessa configuração.

A instabilidade de ranking importa para a seleção de modelos. Em 26 pares de modelos comparáveis, a configuração de deployment produz uma reversão de modelo inequívoca e quatro mais que ficam nas margens de tarefa única. Se você escolheu um modelo de um leaderboard de pontuação correspondente e depois o implantou através de um harness com semântica de serialização diferente, você pode estar executando um modelo subótimo para sua stack — e você não saberia disso pelo número do benchmark.

A implicação de CI/CD em produção é direta. Times executando agentes de código em pipelines autônomos — o modo --auto-exec que pesquisadores de segurança documentaram como o padrão de deployment do mundo real dominante — não têm mecanismo de divulgação. O modelo não recebe informações sobre o transporte de execução, fica na zona de compensação do pior caso, e o validador de estado final na maioria das avaliações nunca verifica se o sistema de arquivos terminou no estado correto.

O artigo QuoteBench recomenda um requisito de divulgação, não um ranking de modelos: qualquer avaliação de agente de código deve relatar configuração do modelo, contrato de geração, caminho de execução, ponto de operação e um validador de estado final. Uma única pontuação correspondente não é uma propriedade intrínseca do modelo. É uma propriedade de um par modelo-harness específico, e o harness é metade do sistema que está sendo entregue para seus runners CI.