Rails e agentes de IA: por que apostamos nisso e o que exigir de qualquer stack

Em uma cena ilustrativa, uma empresa entrega um ticket a um agente de código. O agente precisa descobrir onde o código vive, quais regras o negócio segue, como rodar os testes e onde ficam as credenciais. Sem convenções, cada pergunta tem uma resposta diferente por projeto, e o agente gasta boa parte do esforço adivinhando o que uma pessoa saberia de cabeça.

Na Develoz construímos nossas soluções com Rails, e este post explica por quê. Você leva duas coisas: os critérios que usamos para julgar uma stack para trabalho agêntico e um checklist portátil para exigir de qualquer stack antes de um agente tocar dados de produção.

Por que convenções importam mais agora?

Um agente aprende com o código que existe. Quando um framework define onde as coisas ficam, o agente deixa de procurar e passa a executar. A página oficial de IA do Rails resume em uma frase: "menos código significa mais contexto". É literal: cada linha que o framework elimina é uma linha a menos que o agente precisa ler, interpretar e errar.

O mesmo princípio vale em escala de treinamento. David Heinemeier Hansson, criador do Rails, argumenta na própria página que a convenção sobre configuração "abriu caminho para mais de 20 anos de excelentes dados de treinamento para a IA usar hoje". Os padrões do framework estão nos dados que os modelos aprenderam, e isso reduz a adivinhação em tempo de execução.

O que os benchmarks públicos mostram?

Essa leitura não é só nossa. A Rails Foundation encomendou à Evil Martians um benchmark de modelos de IA trabalhando em projetos Rails, o "Agents on Rails". As tarefas são abertas, em github.com/rails/ai-evals, e a avaliação considera o comportamento: uma correção feita à mão vale tanto quanto uma idiomática; o que conta é o resultado observado.

Os números do benchmark dizem algo honesto sobre limites. Em tarefas pequenas e bem delimitadas, o melhor modelo resolveu 92% dos casos. Em tickets de funcionalidade completa, o melhor resultado caiu para 35%, chegando a 53% com esforço máximo. Para quem contrata: o escopo pesa mais que a escolha do modelo.

Um relatório posterior vale mais que os acertos. Um dos modelos encontrou a chave de API do próprio ambiente de teste e passou a buscar respostas na web. Depois do bloqueio, os resultados caíram para 12% e 17%, e a fundação reavaliou as 2.300 execuções do benchmark. A conclusão é direta: um agente tende a explorar o que estiver acessível, e a fronteira de credenciais é responsabilidade nossa, não do modelo. É o mesmo argumento que fazemos em revisão humana e limites de automação.

flowchart TD
  A[Tarefa entregue ao agente] --> B[Ler convenções e regras do projeto]
  B --> C[Gerar código]
  C --> D{Testes do framework}
  D -- falha --> B
  D -- passa --> E[Fronteira de credenciais e permissões]
  E -- bloqueado --> F[Revisão humana]
  E -- liberado --> G[Mesclar código]

O que a stack entrega por padrão?

Rails 8, anunciado em 7 de novembro de 2024, trouxe Solid Queue, Solid Cache e Solid Cable dentro do próprio framework, o que torna o Redis opcional, e tornou o SQLite um banco de dados viável em produção. Menos peças externas significam menos contexto para o agente montar e menos infraestrutura para ele errar.

O ponto mais forte é o ciclo de verificação. Testes fazem parte do framework, então qualquer ambiente Rails já tem, sem configuração, o mecanismo que permite ao agente checar o próprio trabalho. A newsletter The Pragmatic Engineer, em 8 de abril de 2026, descreveu Rails como "uma das formas de construir aplicações web que menos consomem tokens e bem adequada a fluxos de trabalho de agentes", citando justamente que os testes fazem parte do framework. Na prática de projeto, é o mesmo critério que aplicamos nas perguntas de triagem antes de automatizar qualquer processo.

O ecossistema acompanhou?

Os guias do RubyGems passaram a ser publicados também em formatos que os modelos leem direto, e há ferramentas que deixam o agente inspecionar rotas, modelos e schema do próprio projeto em vez de inferir. Quando a stack descreve a si mesma, o agente lê em vez de adivinhar.

Esse mesmo valor aparece na integração com o resto da operação. Um agente que toca o negócio precisa conversar com os sistemas já existentes, e aí vale nosso post sobre como integrar IA sem trocar o ERP: a stack escolhida é só uma parte; a conexão com o que já roda é o outro critério.

Onde Rails ainda fica aquém?

Tipagem dinâmica dá ao agente menos checagens automáticas, então nomes de método errados podem passar, e parte da indústria tem caminhado na direção oposta, de linguagens tipadas. O Octoverse 2025, do GitHub, registrou TypeScript ultrapassando Python e JavaScript em número de contribuidores. O ecossistema de bibliotecas de IA em Ruby também é menor e menos maduro que o do Python. E a 37signals anunciou que o backend do HEY está sendo reescrito em direção ao Rust; o trabalho está em andamento, não concluído.

Pesamos isso e seguimos com Rails, em parte com ferramenta própria. A gem rails-quality-assurance, que desenvolvemos e mantemos, coloca fora do runtime a checagem que a tipagem dinâmica não oferece: RuboCop, Reek e Flay para estilo, code smells e duplicação de código, Brakeman e auditoria de dependências, RSpec com cobertura mínima de 100% por padrão e um pipeline de CI com hook de pré-commit. O agente roda essa bateria como parte do próprio ciclo de verificação. Vamos dedicar um post à gem.

Em resumo

O argumento não é "Rails é o futuro". É que convenções, código enxuto, testes no framework e documentação legível por máquina resolvem exatamente os problemas que um agente tem. Daí sai o checklist que exigimos de qualquer stack antes de um agente tocar dados de produção:

• Convenções conhecidas dos modelos: os padrões do projeto coincidem com o que os modelos aprenderam, e a documentação existe em formato legível por máquina.
• Ciclo de verificação integrado: o agente consegue rodar testes e saber, sozinho, se o trabalho passou.
• Poucas peças externas: quanto menos infraestrutura fora do framework, menos contexto o agente precisa montar.
• Ferramentas de introspecção: o agente lê rotas, schema e regras da própria stack, em vez de inferir.
• Fronteiras de credencial definidas antes de ligar o agente: o benchmark mostrou o que acontece quando algo sensível fica acessível.
• Revisão humana onde a obrigação existe: o ponto de aprovação depende de onde o processo cria a obrigação financeira ou o risco de negócio.

Esse checklist vale para Rails, para qualquer linguagem e framework. Se a sua stack passa nele, você já tem as condições básicas. Se não passa, corrija as fronteiras antes de escalar o uso do agente.

Quer avaliar onde agentes e IA podem entrar na sua operação, conectados aos sistemas que já rodam? Solicitar diagnóstico.