Código Humano de 2020 Supera Agentes Codificados por Vibração em Testes de Agência

O ChatGPT e outras ferramentas de codificação por vibração foram testados em quase 40.000 partidas – e perderam para o código escrito por um estudante de pós-graduação antes da invenção dos Grandes Modelos de Linguagem.

Em um novo estudo do Reino Unido, os pesquisadores colocaram agentes codificados por humanos contra agentes codificados por vibração desenvolvidos com os últimos Grandes Modelos de Linguagem (LLMs), como ChatGPT-5 e Claude, e descobriram que os agentes criados sem a ajuda da IA superaram facilmente as versões facilitadas pela IA.

Os dois conjuntos de agentes foram criados por diferentes gerações de estudantes do Laboratório de Inteligência Artificial do Instituto Federal de Tecnologia da Suíça. Os agentes não IA foram desenvolvidos como parte de um curso em 2020, dois anos antes do início do ChatGPT e do início da revolução dos LLMs, enquanto os novos agentes foram criados por estudantes atuais, auxiliados pelos LLMs mais recentes e melhores disponíveis.

Even com um jogo manipulado, as soluções codificadas por vibração não puderam vencer, e os cinco primeiros lugares foram consistentemente ocupados por ‘agentes brutos’, com a maioria dos agentes LLM (33 de 40) sendo facilmente derrotados por ‘agentes básicos muito simples’, em 38.304 desafios em um torneio, em uma ampla variedade de variáveis e circunstâncias.

O artigo afirma:

‘Nosso trabalho demonstra que, embora os LLMs de ponta possam gerar código que execute (ou seja, livre de erros de sintaxe), a solução gerada não é competitiva com as soluções projetadas por humanos em dimensões como planejamento estratégico, otimização ou competição multiagente.

‘Portanto, este trabalho traz à tona esta nova fronteira na geração de código e visa facilitar o desenvolvimento de benchmarks, conjuntos de dados e linhas de base de código aberto que enfatizam a síntese de código impulsionada por raciocínio.’

O desafio projetado foi para participar criativamente de leilões, em uma variedade de estratégias, e organizar a logística de entrega de itens vencidos para os vencedores.

Os autores observam que vários vantagens foram dadas aos LLMs, como intervenir em seu código para melhorar seu desempenho – um benefício não permitido ao código de 2020; No entanto, mesmo quando fornecido com código corretivo que definitivamente melhoraria seus resultados, os LLMs não puderam aceitá-lo ou usá-lo:

‘[Em] nosso benchmark, mesmo quando expomos uma boa solução no contexto, o LLM ainda não consegue utilizá-la.

‘Este resultado também levanta questões de pesquisa interessantes sobre os limites do aprendizado no contexto e da resolução de problemas aumentada em cenários complexos.’

Os LLMs usados no teste foram GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1, e DeepSeek R1*.

O novo artigo é intitulado Os Códigos de Vibração Podem Superar os Estudantes de Pós-Graduação em Ciência da Computação? Um Torneio de LLM vs. Código Humano em Planejamento Estratégico Orientado por Mercado, e vem de um autor da Universidade de Southampton e outro da Universidade de Oxford e do Instituto Alan Turing. O benchmark, os autores afirmam, será lançado em breve.

Método

Os autores observam que os testes tradicionais nessa esfera se concentram em desafios com soluções binárias claramente definidas (correto ou incorreto), verificados por meio de testes unitários. Alegando que isso não é o ideal para explorar as limitações do código auxiliado por LLM, os autores projetaram um cenário de desafio mais complexo, com múltiplos benchmarks internos e marcos, no qual a vitória é possível, mas longe de simples:

Comparação de abordagens baseadas em testes unitários padrão (acima) e o cenário de desafio mais aberto projetado pelos autores (em azul, abaixo). Fonte

O Problema de Leilão, Coleta e Entrega (APDP) usado para o estudo dos autores foi parcialmente auto-selecionado, devido à disponibilidade de um corpus de trabalho de estudantes de 2020 da universidade suíça; trabalho que buscava criar agentes automatizados para a tarefa APDP, antes de qualquer capacidade de fortalecer o desenvolvimento por meio da IA. Portanto, foi relativamente fácil atribuir a tarefa moderna aos estudantes com o mesmo briefing, mas disponibilizar-lhes as ferramentas atuais.

Os autores buscaram evitar quadros de teste populares, como HumanEval, BigCodeBench e WebDev Arena (entre muitos outros), pois essa classe de procedimentos de teste tende a sofrer de contaminação de dados (ou seja, instâncias em que o sistema pode ter treinado em dados de teste em vez de respeitar uma divisão).

O APDP é um problema logístico de duas etapas baseado em leilões reversos e rota de veículo. Na primeira etapa, os agentes competem para ganhar tarefas de entrega, submetendo lances para quanto devem ser pagos para completar cada uma delas. Lances muito altos significam perder a tarefa; lances muito baixos podem significar perder dinheiro.

Na segunda etapa, cada agente deve criar um plano eficiente para cumprir apenas as tarefas que ganharam, atribuindo-as a veículos com diferentes capacidades e custos, sob restrições de tempo e recursos:

No APDP, as empresas licitam em leilões reversos para tarefas de entrega, então otimizam as rotas de veículo para cumprir apenas as tarefas que ganharam, visando maximizar o lucro.

O objetivo não é simplesmente concluir as tarefas, mas maximizar o lucro geral, antecipando quais conjuntos de tarefas funcionarão melhor juntos e prevendo as estratégias dos concorrentes que estão tentando fazer o mesmo.

O benchmark APDP aumenta a dificuldade das tarefas de geração de código, introduzindo planejamento estratégico em uma sequência de leilões interdependentes, com cada lance redefinindo o cenário de escolhas futuras; e, portanto, exige que os agentes raciocinem não apenas sobre custos imediatos, mas sobre posicionamento, tempo e consequências de longo prazo.

O problema de entrega central é NP-difícil, ou seja, nenhum algoritmo pode encontrar a melhor solução em tempo razoável à medida que o número de tarefas cresce. Isso torna a força bruta uma abordagem inviável e força os agentes a trocar precisão por velocidade.

A Corrida Está On

A avaliação dos autores comparou 40 agentes codificados por LLM contra 17 agentes codificados por humanos em uma série de torneios de confronto direto. Cada um dos 12 torneios usou uma combinação diferente de quatro topologias de rede de estrada e consistiu em todos contra todos emparelhamentos, com os agentes enfrentando cada oponente duas vezes: uma vez controlando cada uma das duas empresas, com especificações de veículo diferentes.

Esse cenário produziu 3.192 partidas por torneio, totalizando 38.304 partidas. Em cada partida, 50 tarefas de entrega foram leiloadas, definidas por seus pontos de coleta e entrega e peso, e sorteada aleatoriamente em layouts de estrada modelados na Suíça, França, Grã-Bretanha e Países Baixos:

Redes de estrada simplificadas usadas no torneio: Grã-Bretanha (topo esquerdo), Suíça (topo direito), Países Baixos (fundo esquerdo) e França (fundo direito). Quadrados azuis e vermelhos marcam tarefas de coleta e entrega. Triângulos coloridos mostram as posições atuais dos veículos dos agentes.

Os agentes estudantis foram retirados de um torneio de curso de 2020. Oito vieram dos principais desempenhos em uma final de eliminação única e quatro mais foram escolhidos por um desempenho forte contra os agentes de baseline em partidas de confronto direto.

Os agentes de baseline seguiram heurísticas. Naive calculou a distância total e licitou de acordo, usando apenas um veículo e ignorando o lote; ExpCostFixedBid simulou 10 tarefas aleatórias e licitou o custo marginal médio; Honest computou o custo marginal real de inserir a tarefa no cronograma; ModelOpponent fez o mesmo, mas adicionou uma estimativa do custo do oponente, licitando o máximo; e RiskSeeking combinou um prior decrescente com base no tempo com uma estimativa de custo ao vivo e modelagem do oponente – novamente licitando o mais alto dos dois.

A avaliação incluiu 40 agentes codificados por LLM construídos usando o (mencionado anteriormente) GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro e DeepSeek R1. Cada modelo foi solicitado com cinco estratégias distintas, aplicadas duas vezes por modelo.

Duas estratégias usaram prompts estáticos escritos por diferentes autores, enquanto uma terceira pediu ao modelo que se auto-refletisse e revisasse sua própria saída; outra envolveu crítica e revisão por um LLM separado. A estratégia final usou o GPT-4 para sintetizar um novo prompt revisando as quatro abordagens anteriores.

O prompt base refletia a tarefa original do estudante, descrevendo o ambiente de entrega e instruindo o modelo a licitar e planejar para maximizar o lucro, sem confiar em métodos de alta complexidade.

Todos os agentes LLM foram testados em ambientes de autojogo e torneio até que todos os bugs observáveis fossem corrigidos. A correção de bugs foi tratada autonomamente pelos LLMs, solicitados com as informações de erro.

Falhas comuns de LLM, o artigo observa, incluíam violações de limites de tempo, falha em coletar ou entregar tarefas atribuídas e violações de restrições de capacidade de veículo – erros que frequentemente surgiam do descumprimento de instruções explícitas ou de lógica de replanejamento defeituosa^†:

‘Outro problema comum que encontramos (principalmente com Gemini, Claude e DeepSeek, e não tanto com GPT) é que, quite frequentemente, o LLM consistentemente falhava em resolver um bug.

‘Por exemplo, um agente consistentemente expirava, apesar de múltiplos (por exemplo, 5 – 15) ciclos de solicitação do LLM com o erro e recebendo a versão atualizada do código.

‘A única solução que encontramos para tais situações (em que o LLM repetidamente falha em resolver o mesmo bug) é reiniciar do zero. No geral, observamos a necessidade de esforço manual significativo para alcançar o código livre de bugs. Tivemos que gerar substancialmente mais agentes para obter os 40 agentes livres de bugs que avaliamos.’

Os resultados mostrados abaixo resumem os resultados de 12 torneios de rodada dupla, abrangendo quatro topologias de rede e três torneios por topologia, produzindo quase 40.000 partidas:

Para contexto, cada agente jogou 112 partidas por torneio, então a média máxima possível para vitórias ou derrotas por agente é 112. Desvio padrão (SD) reflete variabilidade entre torneios. Agentes codificados por humanos aparecem em negrito. Agentes codificados por LLM são rotulados por modelo (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), seguido por um código de estratégia de dois letras e um dígito indicando se o agente é o primeiro ou segundo gerado com esse prompt. Fonte

Em relação aos resultados mostrados acima, os autores afirmam^†:

‘LLMs não geraram código esperado/competitivo, mesmo em variantes mais simples do problema APDP (apesar do código ser largamente livre de bugs de sintaxe). Isso destaca a importância de benchmarks de avaliação de código impulsionados por raciocínio que vão além do auto-completar e identificam novas fraquezas dos LLMs.’

‘Nossos resultados demonstram uma clara superioridade dos agentes codificados por humanos: (i) Os cinco primeiros lugares são consistentemente ocupados por agentes estudantis, e (ii) a maioria dos agentes LLM (33 de 40) é derrotada por agentes básicos muito simples (como o licitante de custo fixo esperado).

‘Importante notar que não depuramos o código do estudante (enquanto depuramos/testamos o código LLM, tanto em autojogo quanto em torneio [configurações]). Todas as vezes que um agente estudantil travou, automaticamente demos a vitória ao LLM. Um grande número desses travamentos seria fácil de consertar (por exemplo, agentes expiraram), então os agentes estudantis poderiam potencialmente classificar ainda mais alto.’

Como um experimento adicional, o GPT-5 Thinking foi solicitado a melhorar o código do agente de desempenho superior, Estudante 1; mas o agente agora modificado pelo LLM subsequentemente caiu para o décimo lugar, agora o pior de todos os escores humanos. Em vez de melhorar a solução, as alterações do LLM a degradaram em quase 20%.

Os autores concluem:

‘[Nossos] resultados destacam limitações importantes da geração de código LLM, mais notavelmente suas capacidades limitadas de raciocínio e planejamento ao gerar [código]. LLMs modernos podem fornecer código livre de bugs de sintaxe que executa, mas isso não é o benchmark que devemos usar para medir o progresso em direção à IA geral avançada.’

Conclusão

Os autores observam que a codificação por vibração permitiu que pessoas de todos os níveis técnicos criassem códigos, e caracterizam a prática de forma positiva, como uma força niveladora. No entanto, também implicam que, porque a codificação por vibração chegou recentemente, seus limites não são conhecidos e podem ser considerados realistas.

Eles concluem seu artigo chamando para uma mudança de objetivo ‘de código que compila para código que compete’.

Uma pergunta que o leitor casual deste artigo interessante pode ter é se os autores estão lutando acima ou abaixo, pois a tarefa agente em questão é consideravelmente mais complexa e envolvida do que criar scripts do PowerShell e outras formas de funcionalidade e reparos menores para os quais a codificação por vibração é bem adequada.

* Por favor, note que o artigo se refere continuamente a ‘DeepThink R1′, que parece ser inexistente, surgindo apenas um punhado de referências na internet (presumivelmente de outros autores que escreveram incorretamente ‘DeepSeek R1)’. Se este for meu erro, por favor, entre em contato comigo por meio dos meus detalhes de perfil e eu farei as alterações necessárias.

^† Ênfase dos autores, não minha.

Publicado pela primeira vez na quarta-feira, 26 de novembro de 2025. Alterado às 17h35 para formatação.