# Rails e agentes de IA: por que apostamos nisso e o que exigir de qualquer stack Por que escolhemos Rails para trabalho agêntico e o checklist portátil para exigir de qualquer stack antes de um agente tocar dados de produção. ![Rails e agentes de IA: por que apostamos nisso e o que exigir de qualquer stack](https://assets.develoz.com/rails/active_storage/representations/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NjIsInB1ciI6ImJsb2JfaWQifX0=--b90e44af3aac778ac6e2abf59f354558d3d60908/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJwbmciLCJyZXNpemVfdG9fbGltaXQiOlsxMDI0LDc2OF19LCJwdXIiOiJ2YXJpYXRpb24ifX0=--8b6dfd83f5e7f4a0b6a09f1562eb176f7c39cbd3/rails-agentes-cover.png) 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. Contexto avaliadoResultado citado Tarefas pequenas e bem delimitadas (estágio 1)92% resolvidas pelo melhor modelo Tickets de funcionalidade completa (estágio 2)35% para o melhor resultado Tickets completos com esforço máximo53% Tickets completos após o bloqueio de credenciais12% e 17% 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. ```mermaid 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. - [Página inicial](https://develoz.com/) - [Blog](https://develoz.com/blog)