Rails Foundation lança benchmark para medir agentes de IA em código Rails

A Rails Foundation anunciou o Agents on Rails, uma iniciativa contínua para medir, com dados e não com achismo, quão bem os agentes de codificação atuais se saem em bases de código 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 projeto foi encomendado à consultoria Evil Martians e será liberado em estágios ao longo das próximas semanas. A primeira leva de resultados, o leaderboard e o relatório inicial já estão publicados no blog oficial do Rails.

O ponto de partida é uma dor concreta que qualquer time de engenharia reconhece em 2026: praticamente todo dev usa IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → para escrever código, mas as opções são muitas e um modelo novo aparece quase toda semana. Junte a isso o custo de rodar agentes, o gasto de tokens que a maioria das empresas nem tinha no orçamento até pouco tempo atrás, e a pergunta fica óbvia: qual modelo escolher para produção, e a que custo?

O que a fundação queria responder

A comunidade Rails vinha repetindo um discurso: Rails e IA combinam bem. A tese é que a filosofia de Convention over Configuration deixa a base previsível o suficiente para o modelo acertar mais, que Rails é eficiente em tokens e que os LLMs tendem a escrever código idiomático de Rails com naturalidade. O board da própria fundação confirmou essa impressão pela experiência dos seus times.

O problema, como a própria fundação admite, é que tudo isso era evidência anedótica. Daí a decisão de encomendar um benchmark que rodasse agentes populares em tarefas reais de Rails, dentro de aplicações Rails reais, e transformasse os números em orientação prática. As perguntas que guiam o projeto são bem diretas: quais modelos produzem bom código Rails, quantos tokens cada um consome em comparação, e se os modelos frontier são de fato melhores que os open-weight, ou se há trade-offs que justificam escolher um em vez do outro.

Como funciona o Estágio 1: tarefas atômicas

O benchmark é construído por etapas, e a que foi ao ar agora é a Stage 1: Atomic tasks. São tarefas pequenas e autocontidas, cada uma isolando uma capacidade específica. Se a tarefa toca uma API, ela toca apenas aquela. A escolha por tarefas atômicas é metodologicamente importante: ao isolar uma habilidade por vez, fica possível atribuir um acerto ou erro a algo concreto, em vez de tentar interpretar o resultado de uma cadeia longa de decisões onde qualquer elo pode ter falhado.

A avaliação cobre 8 modelos diferentes, misturando frontier e open-weight, e mede quatro eixos:

• Acurácia (o código resolve a tarefa corretamente?)
• Velocidade
• Gasto de tokens
• Custo

Há ainda um quinto critério que merece atenção de quem mantém app em produção: se o modelo usa as APIs atuais do Rails ou se recorre a formas antigas e depreciadas. Esse detalhe é decisivo na prática. Um modelo que resolve a tarefa mas escreve com padrões de duas versões atrás gera dívida técnica silenciosa, o tipo de coisa que só aparece no code review, ou pior, quando a API sai de circulação. A metodologia completa está publicada, e o benchmark será re-executado sempre que modelos promissores forem lançados, para que o leaderboard não vire uma foto congelada e desatualizada em poucos meses.

O que vem no Estágio 2

O Stage 2 promete o que realmente importa para quem trabalha em produção: trabalho realista e complexo. Em vez de tarefas isoladas, a etapa vai testar como os agentes se comportam em fluxos longos e multi-step, adicionando features e construindo uma aplicação do zero. É aqui que o benchmark se aproxima do dia a dia de verdade, porque agente que acerta uma tarefa atômica não necessariamente sustenta coerência ao longo de dezenas de passos, mantendo convenções e sem se perder no próprio contexto.

Vale ler os dois estágios como camadas complementares. O Stage 1 diz qual modelo domina os fundamentos e a que custo por token; o Stage 2 vai dizer qual aguenta o tranco de uma tarefa de verdade. Escolher modelo só pelo primeiro pode enganar, porque custo por token em tarefa curta não escala linearmente quando o agente precisa reler contexto grande a cada passo.

Tudo aberto, e uma harness chamada lemans

Um ponto que interessa a quem gosta de auditar antes de confiar: o projeto está sendo aberto por completo. As tarefas e a metodologia já estão disponíveis, as execuções brutas (raw runs) seriam subidas ao repositório logo em seguida, e a lemans, a harness em Ruby que a Evil Martians construiu para rodar tudo, também será liberada como open source. Isso muda a natureza do benchmark: em vez de um número que a fundação pede para você acreditar, é uma bancada de testes que qualquer time pode rodar contra o próprio código, com as próprias tarefas e o próprio modelo interno, se quiser.

O que isso muda para o dev brasileiro

Para times brasileiros, o valor prático está em dois pontos. Primeiro, custo em dólar pesa. A pergunta "frontier ou open-weight?" não é ideológica aqui, é orçamentária. Se um modelo open-weight entrega acurácia próxima de um frontier em tarefas Rails, mas a uma fração do gasto de tokens, essa diferença pode ser o que viabiliza (ou não) botar um agente para rodar de forma recorrente em CI ou em automação de tarefas repetitivas.

Segundo, o critério de APIs atuais é um filtro de qualidade que raramente aparece em benchmarks genéricos de código. Benchmark de LLM que só mede "o teste passou" ignora que código idiomático e atualizado é o que sustenta uma base a longo prazo. Para quem mantém monolito Rails com anos de estrada, saber que um modelo tende a escrever no estilo antigo é uma informação que economiza review.

O ceticismo saudável continua valendo. Benchmark é sempre uma simplificação: tarefas atômicas não capturam o caos de uma base real com gambiarras herdadas, gems desatualizadas e regras de negócio implícitas. É exatamente por isso que o Stage 2 existe, e é por isso que a abertura da lemans importa mais que o leaderboard em si. O número serve de bússola inicial; a decisão final continua sendo medir no seu próprio contexto, com seu próprio código, porque contexto é rei. Times com opinião sobre o que testar a seguir foram convidados a escrever para foundation@rubyonrails.org.

Fonte: Ruby on Rails Blog