Qual é a melhor linguagem de programação para agentes de código?

O que se costuma afirmar sobre linguagens e agentes

Um post bastante citado, que aparece até em respostas de IA do Google, afirma que linguagens dinâmicas e mais concisas teriam custo de tokens muito menor para agentes de código - algo como metade ou um terço do custo de linguagens estáticas como Rust, Go e C++. O mesmo post aponta um intervalo de 2,6x entre C (menos eficiente) e Clojure (mais eficiente), e destaca J, com média de 70 tokens, como extremamente eficiente. Outro experimento circulante chega a conclusão semelhante.

Por que esses resultados não convencem

O autor argumenta que esses benchmarks usam problemas triviais, como tarefas do Rosetta Code resolvidas em poucas dezenas ou centenas de tokens. Segundo ele, resultados assim não generalizam: quando o problema exige trabalho real, as grandes vantagens tendem a desaparecer. Ele também aponta falhas metodológicas no segundo experimento, como testes que executavam o caminho errado, um symlink criado por um agente de Go que passou a valer para execuções posteriores e testes com branches que aprovavam independentemente do valor verificado. Isso invalidaria conclusões como a de que Rust teria falhado por ser uma linguagem “difícil” para IA.

Avaliações próprias: Zstd e Pandoc

Em vez de confiar nesses benchmarks, o autor rodou avaliações próprias com agentes, pré-registrando palpites antes de ver os resultados. No primeiro teste, os agentes recebiam o RFC do Zstd, com erratas, e precisavam implementar um decoder completo dentro de um container sem internet, sem acesso aos testes. No segundo, adaptou o ProgramBench do Pandoc, entregando materiais e testes aos agentes e avaliando depois com um conjunto oculto de testes.

Nos dois casos, não apareceu uma relação forte entre custo, acerto e o fato de a linguagem ser estática ou dinâmica. No Zstd, com esforço médio, linguagens dinâmicas pareciam melhores; com esforço alto, os resultados ficavam mistos, com algumas linguagens estáticas entre as melhores. Em Pandoc, o padrão foi parecido. Assembly foi mal, como esperado, e linguagens obscuras tenderam a ter desempenho ruim. Houve correlação fraca a moderada entre popularidade da linguagem e resultados melhores, mais corretos e mais baratos.

Conclusões principais

O autor considera correta sua aposta de alta confiança de que a alegação geral de “dinâmico é mais eficiente” não se sustenta. Também considera correta a aposta de que a suposta superioridade de linguagens “estranhas” e muito densas, como J, não se confirmaria. Já a hipótese de que linguagens estáticas seriam melhores em esforço extremo não recebeu suporte claro. Alegações como “PHP performa pior por ter muito código ruim”, “use Haskell porque reescrever ficou barato” ou “Ruby, Clojure, J e Elixir são especialmente adequados a LLMs” apareceram como falsas ou sem base nesses testes. A única ideia com algum suporte é usar linguagens populares, mas sem força para recomendações fortes.

Ele também destaca falhas idiossincráticas: em Clojure, boa parte dos erros no Zstd veio de conversões de bytes que lançam exceção para valores entre 128 e 255. Em Rust, houve loops de erro repetidos ao invocar cargo com argumentos errados. Esses custos existem em toda linguagem e dificultam conclusões gerais.

Apêndices: loop, contexto e especificações ambíguas

Em um apêndice, o autor comparou rodar o modelo “ultra” uma vez com repetir o modo “medium” em loop. Para aquele problema, rodar ultra uma vez foi mais custo-efetivo por custo e especialmente por tempo. Continuar com o contexto existente superou o estilo “Ralph loop”, que descarta o contexto e reinicia do prompt original; o agente pode ficar ancorado em uma solução ruim mesmo começando de novo.

Outro apêndice descreve uma tentativa de avaliar implementação de um jogo de tabuleiro, Guards of Atlantis 2, como tarefa mais próxima de “lógica de negócio” com especificações ambíguas, contraditórias e às vezes erradas. Mesmo com modelos mais novos, os agentes tiveram pontuação aproximada de zero. Para o autor, isso mostra que lidar com especificações humanas mal escritas é um desafio real para agentes, diferente de implementar specs bem definidas como o RFC do Zstd.