Linguagem para agentes: um benchmark com teto não escolhe sua stack

Fabio Akita publicou um experimento com agentes implementando a evolução de um motor de livro-razão em sete linguagens, com quatro configurações de modelo e 112 tentativas.[7] O contrato foi avaliado por 43 histórias, com 27 testes públicos em uma condição e 16 histórias ocultas.[7]

O resultado não sustenta uma linguagem universalmente melhor para programar com IA. O que ele oferece é um método mais interessante: comparar entregas sob um contrato comum e separar correção de consumo.

O que muda para quem desenvolve

Sol acertou suas 28 tentativas e Opus acertou as 25 elegíveis, com três interrupções de infraestrutura.[7] Esse teto impediu ordenar a correção desses modelos por linguagem naquela tarefa.[7] Se todas as soluções elegíveis passam, o teste deixou de separar candidatos nessa dimensão. Isso não transforma diferenças de tempo ou tokens em diferenças de confiabilidade.

Kimi e GLM produziram conjuntamente 24 artefatos corretos com testes públicos, contra 16 sem eles; Kimi passou em suas 14 tentativas com testes fornecidos.[7] É um resultado descritivo favorável aos testes, não uma demonstração causal abrangente sobre todas as tarefas.

As falhas semânticas auditadas envolveram invariantes entre operações e checkpoint, não erros de tipo.[7] Minha leitura é que o contrato de domínio merece mais atenção do que a promessa de uma sintaxe especialmente amigável ao modelo. Compilar e preservar regras do negócio são verificações diferentes.

O texto também descreve tentativas baratas de GLM em TypeScript que deixaram o código inicial inalterado após atingir o limite de saída.[7] Consumo baixo sem entrega não deve ganhar o concurso de eficiência.

Como aplicar

Antes de trocar a stack, escolha tarefas representativas do projeto: uma mudança de regra, um defeito com regressão e uma alteração envolvendo persistência. Mantenha o escopo equivalente e fixe toolchain, modelo, orçamento e critérios de parada.

Forneça testes suficientes para orientar a implementação, mas reserve verificações independentes para o aceite. Inclua invariantes que atravessam operações, como uma autorização que precisa continuar válida depois de recuperar estado. Não limite a avaliação a exemplos felizes isolados.

Registre artefatos aceitos, erros semânticos, consumo, tempo e intervenções humanas. Marque interrupções de provedor e problemas de ambiente separadamente de defeitos da solução. Preserve o código produzido mesmo quando o resultado falhar, para permitir auditoria.

O experimento útil não precisa reproduzir toda a matriz de Akita. Precisa ser capaz de refutar a hipótese de que uma troca de linguagem melhora suas tarefas, incluindo o custo de migrar e manter a nova base.

Cuidados e limites

O estudo usa uma única tarefa, duas repetições por combinação, cobertura parcial de tokens e instrumentação que mudou entre etapas; atrasos de provedor também contaminam o tempo de parede.[7] Esses limites impedem transformar as medianas em um ranking universal.

Na trilha separada de filas, o coletor compartilhado aparentemente limitou a vazão, e essa trilha não foi uma comparação controlada do esforço de programação por IA.[7] Empate sob um gargalo externo não demonstra teto equivalente das linguagens.

A decisão prudente é fortalecer contratos e regressões primeiro. Uma migração precisa de evidência do seu problema, não de uma guerra de linguagens embalada como otimização de tokens.

Fonte

[7] Fonte: AkitaOnRails