Rails ganha seu primeiro benchmark de agentes de IA

A Rails Foundation publicou no blog oficial do Ruby on Rails↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) → o primeiro relatório de benchmark do projeto Agents on Rails, uma iniciativa para medir o quão bem agentes de LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → se saem em tarefas reais de manutenção de uma aplicação Rails. Não é marketing de IA nem torcida por linguagem: é um experimento reproduzível, com harness congelado e código que vai virar open source. Para quem toca aplicação Ruby em produção no Brasil (e há muito legacy Rails rodando por aqui), o número interessante não é qual modelo ganhou, e sim o que o benchmark revela sobre onde os agentes tropeçam.

Como o teste foi montado

O setup é deliberadamente minimalista, e isso é o ponto forte. Foram 21 tarefas atômicas aplicadas ao Writebook (um app Rails real), cada uma girando em torno de uma única API do framework, mas descrita como um humano descreveria: um bug report, um achado de segurança, um pedido de feature. As descrições nunca mencionam qual API resolve o problema.

Os números da execução:

• 8 modelos, cada um nas configurações padrão do provider (sem mexer no dial de reasoning): Claude Opus 5, Claude Fable 5, GPT-5.6 Sol e Luna, Muse Spark 1.2, Kimi K3, GLM 5.2 e DeepSeek V4 Flash.
• 3 execuções por modelo por tarefa, totalizando 504 runs e um custo de US$ 493.
• Agente propositalmente burro: um prompt leve com uma única ferramenta bash (o miniswen, port em Ruby do mini-swe-agent), mesmos limites de passos e custo para todos.
• Julgamento por suíte de testes escondida: o run passa quando os testes passam. Os testes checam comportamento, não implementação, então uma solução artesanal passa igual a uma idiomática.

Essa última decisão é o que dá honestidade ao benchmark: ninguém é penalizado por escrever código não idiomático se o comportamento estiver correto. A aderência ao Rails é medida à parte.

O placar de agosto de 2026

Segundo a fonte, os destaques ficaram assim:

• Mais preciso: Claude Opus 5, com 92% dos runs resolvidos (58 de 63).
• Mais barato: GPT-5.6 Luna, 73% no esforço de reasoning médio padrão, com os 63 runs custando 91 centavos de dólar somados. Não é erro de digitação.
• Mais rápido: Luna de novo, mediana de 3,3 minutos por tarefa.
• Melhor combinação dos três: GPT-5.6 Sol, 84%, cerca de US$ 1,50 e cinco minutos por tarefa.

O Claude Fable 5 lideraria com ~95%, mas recusou a única tarefa redigida como um relatório de pentest, zerando nela. Detalhe nada trivial para quem pensa em apontar agentes para trabalho de segurança: o modelo mais capaz do teste simplesmente se negou a agir.

O relatório resume a economia de forma direta: "um dólar te leva quase até o fim; cada ponto depois disso fica caro". Luna bateu modelos mais caros gastando centavos. Sol custa 36× mais que Luna e compra onze pontos; Opus custa 132× e compra dezenove. A partir daí o preço para de prever a nota: Kimi empata os 90% de Fable pela metade da conta.

O achado que importa: os modelos não conhecem Rails

Aqui está a parte que um dev deveria levar para casa. Como cada tarefa gira em torno de uma API específica do Rails que o enunciado esconde, dá para medir uma coisa: o modelo lembrou da API existente ou reescreveu tudo do zero?

Na maioria das vezes, ele reescreve. O recall de API do Rails vai de 8% (DeepSeek) a 35% (Fable). E isso separa os modelos muito mais do que a taxa de sucesso: DeepSeek e Fable estão 1,4× distantes em nota, mas 4× distantes em recall. Mesmo o melhor modelo do campo entrega solução artesanal na maioria dos runs em que o framework já tinha a resposta pronta.

Usar a API compensa: runs que lembraram dela resolveram a tarefa 92% das vezes, contra 87% dos que fizeram na mão. Pior de todos (64%) foram os runs que conheciam a API e mesmo assim entregaram outra coisa.

A frase da fonte que fecha o raciocínio: "código artesanal é código que seu time agora mantém". Um agente que reimplementa has_secure_password ou reinventa um scope quando o Active Record já resolvia não quebrou o teste, mas deixou dívida técnica para o humano cuidar. Para times brasileiros que já lutam com legacy, esse é o custo invisível de "deixar a IA resolver".

Dá para melhorar o modelo barato sem trocar de modelo

A Luna virou cobaia de dois experimentos porque tinha mais espaço para crescer. Os resultados:

1. Dial de reasoning funcionou. Em esforço high, Luna foi para ~86% (replicado em quatro sweeps) a US$ 1,36 por passada completa no corpus. Em xhigh, 89% por US$ 2,34. Ou seja: a maior parte do gap para a fronteira desaparece só dando mais tempo de raciocínio ao modelo de 91 centavos.
2. Contexto enriquecido mudou o estilo, não a nota. Alimentar o agente com os guides do Rails e a documentação de API aumentou o recall (a Luna passou a usar mais a API e reescrever menos), mas o sucesso mal se moveu. A conclusão fica em aberto: contexto guia o estilo, mas não está claro se conserta o raciocínio.

O trade-off prático é claro: se você usa um modelo barato num pipeline de agente, subir o reasoning effort tende a valer mais a pena do que despejar documentação no prompt, ao menos para acertar a tarefa.

Onde os agentes ainda quebram

Seis das 21 tarefas foram resolvidas por todo run de todo modelo. Trabalho atômico de Rails já é problema resolvido para modelos de fronteira, e a nota se decide nas outras quinze.

O separador mais afiado foi uma tarefa inspirada em GDPR, de apagamento de conta, sem linha de parada clara: só 8 de 24 runs passaram, e ela divide limpo o topo do resto. A tarefa mais difícil foi purgar imagens embutidas, um bug cuja metade visível esconde uma segunda. É exatamente esse tipo de problema (ambíguo, com armadilha escondida) que a Foundation quer multiplicar nas próximas rodadas, e a expectativa é que o topo do leaderboard se espalhe conforme as tarefas alcancem os modelos.

O que fica para o dev

Além do snapshot de números, a Foundation vai abrir o código: o corpus, os runs e o lemans (o harness em Ruby que roda tudo) devem aparecer no GitHub do Rails. Isso permite que qualquer time rode o benchmark contra o próprio código ou contra modelos diferentes, o que é mais valioso que a foto de agosto de 2026.

O recado pragmático do relatório: agentes já servem para o trabalho braçal de manutenção Rails, e por centavos. Mas eles ainda não pensam em Rails, tendem a reinventar o que o framework já oferece, e podem simplesmente recusar tarefas sensíveis. Antes de plugar um agente no seu fluxo, vale calibrar o esforço de reasoning, medir quanto código artesanal ele está gerando e não confiar cegamente nele para segurança. E, detalhe operacional: como a suíte roda a cada iteração do agente (Opus a executa nove vezes por tarefa), uma suíte de testes lenta é paga várias vezes. Otimizar o CI virou também otimização de custo de agente. Os números atualizados ficam na página oficial do Agents on Rails.

Fonte: Ruby on Rails Blog